Diseño y optimización de una infraestructura computacional basada en la nube

TESIS DE DOCTORADO DISE˜ NO Y OPTIMIZACI ´ ON DE UNA INFRAESTRUCTURA COMPUTACIONAL BASADA EN LA NUBE Jos´ e Isaac Zablah ´ Avila ESCUELA DE DOCTORADO INTERNACIONAL PROGRAMA DE DOCTORADO EN INVESTIGACI ´ ON EN TECNOLOG´ IAS DE LA INFORMACI ´ ON SANTIAGO DE COMPOSTELA 24 de Mayo del 2019 DECLARACI ´ ON DEL AUTOR DE LA TESIS Dise˜ no y optimizaci´ on de una infraestructura computacional basada en la nube Don Jos´ e Isaac Zablah ´ Avila Presento mi tesis, siguiendo el procedimiento adecuado al Reglamento, y declaro que: 1. La tesis abarca los resultados de la elaboraci´ on de mi trabajo. 2. En su caso, en la tesis se hace referencia a las colaboraciones que tuvo este trabajo. 3. La tesis es la versi´ on definitiva presentada para su defensa y coincide con la versi´ on enviada en formato electr´ onico. 4. Confirmo que la tesis no incurre en ning´ un tipo de plagio de otros autores ni de trabajos presentados por m´ ı para la obtenci´ on de otros t´ ıtulos. En Santiago de Compostela, 24 de Mayo del 2019 Fdo. Jos´ e Isaac Zablah ´ Avila AUTORIZACI ´ ON DEL DIRECTOR/TUTOR DE LA TESIS Dise˜ no y optimizaci´ on de una infraestructura computacional basada en la nube Don Antonio Garc´ ıa Loureiro, Profesor del Departamento de Electr´ onica y Computaci´ on de la Universidad Santiago de Compostela INFORMA: Que la presente tesis, corresponde con el trabajo realizado por Don Jos´ e Isaac Zablah ´ Avila bajo mi direcci´ on, y autorizo su presentaci´ on, considerando que re´ une los requisitos exigidos en el Reglamento de Estudios de Doctorado de la USC, y que como director de ´ esta no incurre en las causas de abstenci´ on establecidas en Ley 40/2015. En Santiago de Compostela, 24 de Mayo del 2019 Fdo. Antonio Garc´ ıa Loureiro Director/a tesis Jos´ e Antonio Loucel Monterroza, SDB Mentor, por inculcarme disciplina, valores y car´ acter para emprender mis diferentes etapas formativas. Oscar Antonio S´ anchez T´ ıo, por brindarme su gu´ ıa, apoyo y compromiso con las metas que he tenido a lo largo de mi vida adulta. Fernando G´ omez Folgar Amigo, que me brind´ o su apoyo en las diferentes etapas de mi formaci´ on doctoral. Antonio Garc´ ıa Loureiro Tutor, por haberme guiado, no s´ olo en la elaboraci´ on de esta tesis, sino a lo largo de mi doctorado, me brind´ o su apoyo incondicional para desarrollarme en mis actividades. El destino del Imperio est´ a en vuestras manos... Blas de Lezo y Olavarrieta (Sitio de Cartagena, 13 de marzo de 1741) JOS ´ EISAAC ZABLAH ´ AVILA relacionales, entre otras. Se pretende que la(s) infraestructura(s) aqu´ ı evaluadas sean consideradas como una tecnolog´ ıa catalizadora de soluciones a varios desaf´ ıos sociales; por ejemplo poder ser utilizadas para mejorar los indicadores de una baja productividad agr´ ıcola; mejorar las alertas tempranas antes y despu´ es de los desastres naturales; aumentar e implementar procesos de fiscalizaci´ on por medio de mejores aplicaciones que sirvan de freno a la corrupci´ on pol´ ıtica y evasi´ on fiscal, entre otros temas de importancia local. Las universidades, centros de investigaci´ on y otras instituciones son las entidades que mejor pueden manejar los procesos de transferencia de tecnolog´ ıa; pueden trasladar descubrimientos cient´ ıficos y t´ ecnicos de una organizaci´ on a otra, con el fin de promover su desarrollo y comercializaci´ on. En este sentido, diferentes regiones geogr´ aficas integran estas oportunidades desde diversas perspectivas; algunos est´ an m´ as centrados en la ciencia y otros en el emprendimiento de empresas. En un pa´ ıs como Honduras, el Estado puede guiar este proceso en beneficio de toda la sociedad por medio de los servicios p´ ublicos y gubernamentales. Objetivos Determinar las aplicaciones que actualmente est´ an siendo usadas por los acad´ emicos en mi pa´ ıs de origen (Honduras) para reducci´ on, procesamiento y modelado de datos. Medir el rendimiento de infraestructuras f´ ısicas en uso frente a una alternativa que emplee tecnolog´ ıa de virtualizaci´ on y el paradigma de la computaci´ on en la nube. Portar y evaluar las aplicaciones que requieren altos recursos computacionales, determinando la magnitud del cambio del rendimiento en diferentes plataformas. Desarrollar y poner en marcha una infraestructura de altas prestaciones, con el fin de poder contar con la capacidad computacional para apoyar las tareas de manejo de BigData, por sus necesidades en cuanto a capacidad de procesamiento. Implementar y conjugar diversas tecnolog´ ıas con el fin de tener una soluci´ on adaptable a las necesidades actuales y crecientes a futuro. Brindar a los usuarios la flexibilidad en cuanto al acceso y las prestaciones disponibles, de manera que se logren los resultados de las investigaciones hasta ahora inalcanzables en muchos casos, en otros en menos tiempo, acelerando la ciencia con todo ello. 2 Cap´ ıtulo 1. Introducci´ on Motivaciones La principal raz´ on de este trabajo es la carencia actual de capacidad de c´ alculo para el desarrollo de diversas tareas de procesado de datos y c´ alculo cient´ ıfico. Por lo tanto, se pretende reducir esta brecha a trav´ es de la planificaci´ on y puesta en marcha en mi pa´ ıs de una infraestructura de altas prestaciones como las aqu´ ı descritas, con el fin de impulsar el desarrollo de todas ´ areas del conocimiento, especialmente las que se listan a continuaci´ on: •Reducci´ on, an´ alisis y modelado de datos de origen m´ edico: Con el advenimiento de la medicina de precisi´ on, se genera la necesidad de realizar an´ alisis multiorigen (usando t´ ecnicas como datamining ydatawarehouse), ejemplo de ello son los datos extra´ ıdos de equipos de im´ agenes m´ edicas. Toda esta informaci´ on se considera como BigData, debido a su complejidad, volumen y heterogeneidad; requiriendo para su an´ alisis capacidad computacional elevada, el´ astica, ubicua y flexible; ya que la naturaleza de estos datos es de gran tama˜ no y cambiantes. El manejo oportuno de las im´ agenes m´ edicas en la investigaci´ on cient´ ıfica, son determinantes para la obtenci´ on de resultados para conocer mejor padecimientos y su forma de tratarlos; para ello las capacidades de computaci´ on de altas prestaciones aceleraran el proceso de obtenci´ on de resultados a trav´ es del procesamiento y modelado computacional. As´ ı mismo la combinaci´ on de conocimientos entre ´ areas m´ edicas y de ingenier´ ıa van ligadas a conocimientos que est´ an en incipiente desarrollo como son las ciencias biom´ edicas y la bioinform´ atica; de manera que requieren de una soluci´ on computacional escalable como una herramienta valiosa si se implementa bajo el paradigma de infraestructura como servicio. •Creaci´ on de contenido multimedia de alta definici´ on: Los recursos multimedia son el resultado de un proceso computacional intensivo que busca obtener medios de alta calidad a trav´ es de millones de c´ alculos, donde se tiene en cuenta variables relacionadas a las tonalidades, sombras, texturas, refracciones, iluminaci´ on, profundidad de campo, movimientos, ambiente, efectos especiales, entre otros elementos, que se mezclan en las t´ ecnicas de edici´ on y producci´ on de medios en entornos de alta definici´ on. El hecho de no contar con la capacidad computacional adecuada hacen ardua, lenta y muchas veces imposible esta tarea. Una infraestructura HPC reducir´ ıa el tiempo de obtenci´ on de contenido listo para difusi´ on, siendo actualmente el mayor cuello de botella en el flujo de trabajo de edici´ on y postproducci´ on en la televisora de mi universidad de origen. 3 JOS ´ EISAAC ZABLAH ´ AVILA •Modelado y animaci´ on en 2D y 3D: La tecnolog´ ıa de gr´ aficos en dos dimensiones (2D) y en tres dimensiones (3D) es aplicable en diversos campos. Dependiendo de la capacidad de los ordenadores empleados, la renderizaci´ on puede requerir desde algunas horas hasta varias semanas para finalizar con un prototipo. Contar con servicios computacionales que permita el aprovechamiento de esta tecnolog´ ıa, impulsar´ ıa actividades acad´ emicas a nivel de ingenier´ ıa y de investigaci´ on. En el caso de los sistemas de producci´ on televisiva, se requiere encarecidamente poder mejorar el tiempo de obtenci´ on de escenas para difusi´ on en alta definici´ on, las cuales s´ olo pueden ser obtenidas a trav´ es de infraestructuras de altas prestaciones, permitiendo poner a disposici´ on de los animadores y dise˜ nadores capacidad computacional que les permita poder dedicar m´ as tiempo al producto y no al proceso. Esto tambi´ en es aplicable a los campos de ingenier´ ıa en ´ areas mec´ anicas y civiles, arquitectura, f´ ısica entre otras ´ areas. •Ciberseguridad, ciberguerra y t´ ecnicas de protecci´ on de datos: El mundo enfrenta amenazas de una realidad distinta, invisibles y fuera de todo lo conocido de forma convencional. Por citar un evento, en 1989 un virus del tipo gusano llamado WANK creado por hackers australianos que se hac´ ıan identificar como Electron yPhoenix; atacaron sistemas DEC VMS en la red DECnet; que di´ o como resultado que las comunicaciones entre la NASA y el Departamento de Energ´ ıa de los EEUU se comprometieran lo suficiente como para interrumpir el lanzamiento programado del transbordador espacial que llevaba la sonda Galileo a ´ orbita. Por citar, situaciones m´ as recientes en el contexto hondure˜ no y de forma sostenida en los ´ ultimos a˜ nos los sistemas de Gobierno que tienen portales o acceso a Internet han sido objeto de m´ ultiples ataques, tanto de individuos de fuera como del interior de las mismas dependencias del estado, careciendo de todo tipo de recurso para analizar protocolos, bit´ acoras y otros elementos que pueden ser ´ utiles en una respuesta r´ apida a estas amenazas. La infraestructura de altas prestaciones puede proveer instancias computacionales bajo demanda que sirvan para ayudar a determinar el origen de los ataques y encontrar la v´ ıa m´ as eficiente para evitar sus da˜ nos. •Matem´ atica y f´ ısica computacional: El desarrollo de modelos num´ ericos en los cuales se estudian fen´ omenos como las ´ orbitas de planetas extrasolares y trayectorias de colisi´ on de asteroides, entre otros, son actualmente una l´ ınea de investigaci´ on en mi instituci´ on. Se requiere para ello el manejo de altos vol´ umenes de datos que necesitan ser analizados utilizando m´ ultiples modelos y t´ ecnicas, tambi´ en se incluyen en estos, el an´ alisis de datos provenientes de sensores espaciales y de bases de datos de m´ ultiples relaciones 4 Cap´ ıtulo 1. Introducci´ on orientadas a la obtenci´ on de modelos astrof´ ısicos. En el ´ area matem´ atica, esta infraestructura puede ser empleada para el c´ alculo en ´ algebra lineal, espec´ ıficamente para resolver sistemas de gran tama˜ no y problemas vectoriales. •Sistemas de informaci´ on geogr´ afica: Existe necesidad creciente del control territorial, tanto para conocer sus cambios como para hacer mejor uso de ´ el. Estas tareas han recibido un impulso debido al empleo de t´ ecnicas de automatizaci´ on y en especial de software orientado a la cartograf´ ıa. Lo anterior, se ha unido con bases de datos relacionales obteniendo una cantidad enorme de aplicaciones. El problema en estos sistemas, es contar con la capacidad que permita manejar datos espaciales (im´ agenes provenientes de sat´ elites, fotograf´ ıa a´ erea, etc.), combinar metadatos (informaci´ on concreta que le da valor a˜ nadido a los datos espaciales y de hecho los describen), hojas cartogr´ aficas y otros recursos. Los elementos mencionados al ser combinados a trav´ es del tiempo permiten realizar modelos para estimar el cambio en la superficie y de esa manera poder proponer caminos apropiados para su mejor uso. Para poder obtener un patr´ on, un mapa o un modelo, se requiere en gran medida poder utilizar varios procesos paralelos que necesitan de una infraestructura como las propuestas en este documento. •Predicci´ on meteorol´ ogica: El estudio del cambio clim´ atico y calentamiento global donde convergen varios factores como ser naturales y antropog´ enicos que han ocasionado cambios en el planeta, que requieren ser analizados hoy en d´ ıa para predecir las causas y futuro de este fen´ omeno. Tambi´ en, es de mucha importancia estudiar el papel de la atm´ osfera solar y los efectos que esta puede tener sobre su contra parte terrestre, siendo esta seg´ un los especialistas la otra vertiente del calentamiento planetario. Debido a que hay una serie de variables que requieren ser modeladas, la necesidad de una infraestructura optimizada puede brindar un entorno para estudiar diversas condiciones que afecten el clima, dichos modelos requieren por su complejidad una gran capacidad de procesamiento y actualmente es una l´ ınea de investigaci´ on en mi pa´ ıs. •Gobierno electr´ onico: Honduras necesita urgentemente que se le brinden soluciones basadas en sistemas inform´ aticos que permitan la reducci´ on de tiempos y costos en la gesti´ on p´ ublica sobre todo en el relacionado a la atenci´ on del contribuyente y procesos electr´ onicos gubernamentales, una infraestructura resistente a fallos ofrecer´ ıa los medios necesarios para poder desarrollar los sistemas ´ utiles en estos sentidos y propiciar su adecuada ejecuci´ on. 5 CAP´ ITULO 2 ESTADO DEL ARTE En esta secci´ on se hace una recensi´ on de los conceptos b´ asicos indispensables para el desarrollo de esta investigaci´ on, haciendo ´ enfasis en la evoluci´ on de los mismos y su estado actual de desarrollo. Tambi´ en se describen detalles de las retos actuales en los t´ opicos descritos y sus aplicaciones t´ ecnicas en la soluci´ on de problemas a diferentes niveles. 2.1. Computaci´ on de altas prestaciones La humanidad reconoce al ENIAC (Electronic Numerical Integrator and Computer), construida por P. Eckert y J. Mauchly, como el primer gran ordenador. El ENIAC estaba compuesto por m´ as de 19000 tubos de vac´ ıo, con un peso de 30 toneladas, ocupaba un espacio de 72 metros cuadrados y consum´ ıa al menos 140 KVA. Este primer ordenador dispon´ ıa tan s´ olo de una velocidad de reloj de 100 KHz, con la capacidad de hacer 330 multiplicaciones por segundo. Pero no fue hasta 1961, que se instala en el Alamos National Laboratory el que ha sido considerado como el primer superordenador, el Cray-1. Entre sus caracter´ ısticas estaban la potencia de c´ alculo y la capacidad de memoria, pod´ ıa realizar 160 millones de operaciones por segundo (160 megaflops), pose´ ıa 8 megabytes de RAM. En la d´ ecada de los setenta y ochenta vieron el desarrollo de diversas tendencias en superordenadores, espec´ ıficamente en procesamiento vectorial y paralelo. A mediados de la d´ ecada de los noventa, la forma de un ´ unico procesador dise˜ nado espec´ ıficamente desapareci´ o y fue reemplazada por el uso de varias unidades centrales de procesamiento, lo que permiti´ o el desarrollo m´ as acelerado y econ´ omico de la capacidad computacional. Al momento de redactar el presente documento, el superordenador m´ as potente del mundo es el llamado Summit, instalado en el Laboratorio Na- JOS ´ EISAAC ZABLAH ´ AVILA cional Oak Ridge en Estados Unidos de Am´ erica, cuenta con una capacidad de procesamiento de 200.795 petaflops, suministrada por 2,397,824 n´ ucleos [53]. La computaci´ on de altas prestaciones consiste en la utilizaci´ on de s´ upercomputadores, sistemas multiprocesador y redes de ordenadores en la resoluci´ on de problemas con una carga computacional elevada y que son dif´ ıcilmente abordables con otras plataformas. Es ampliamente utilizada en un gran abanico de campos de la ciencia, la ingenier´ ıa y la industria. ´ Areas como la nanotecnolog´ ıa, predicci´ on clim´ atica, ingenier´ ıa aeroespacial y del autom´ ovil, explotaci´ on del petr´ oleo, dise˜ no de f´ armacos, gen´ etica, predicci´ on y evoluci´ on de la contaminaci´ on, dise˜ no de dispositivos electr´ onicos, etc., todo ello necesita el apoyo de potentes ordenadores y el desarrollo de aplicaciones paralelas para seguir avanzando en su desarrollo. Adem´ as, existen diversas plataformas usadas en la computaci´ on de altas prestaciones, como las que usan procesadores con m´ ultiples n´ ucleos o (manycore) y otras que utilizan unidades gr´ aficas de procesamiento (GPU). Dependiendo de las aplicaciones a ejecutar se debe determinar que plataforma de hardware es la que brindar´ a el m´ aximo rendimiento y se adaptar´ a mejor al problema a resolver. El incremento de la capacidad computacional (al concentrar un mayor n´ umero de recursos f´ ısicos) es directamente proporcional al poder de c´ alculo y con ello ser´ a mayor el n´ umero de problemas que se pueden solventar, aumentando su precisi´ on y disminuyendo el tiempo de obtenci´ on de resultados. Las organizaciones que cuentan con altas capacidades poseen una ventaja competitiva que se convierte en un elemento diferenciador. Las l´ ıneas de investigaci´ on abiertas en el ´ ambito de la computaci´ on de altas prestaciones (High Performance Computing - (HPC)) cubren tres ´ areas. La primera es el hardware para integrar soluciones a nivel f´ ısico lo que incluye redes, memoria, placas, procesadores entre otros. La segunda es el software que se utiliza para poner a disposici´ on la capacidad de gestionar y monitorear la infraestructura en cuanto a su disponibilidad de recursos y su crecimiento. La tercera son las aplicaciones que requieren los usuarios finales, que van desde compiladores hasta simuladores los cuales deben estar adaptados para ejecutarse de forma optimizada, sacando el mayor provecho posible del entorno de alto rendimiento. Cuando se realizan c´ alculos, se pueden considerar tres enfoques b´ asicos para mejorar el rendimiento. El primero, es emplear un algoritmo m´ as eficiente, en el cual se debe considerar detalladamente lo que se desea calcular y la manera de analizar como se puede sacar el mayor provecho al hardware, con ello se debe reescribir el c´ odigo fuente a partir de una definici´ on mejorada de los problemas evitando operaciones innecesarias. El segundo enfoque es utilizar 8 Cap´ ıtulo 2. Estado del arte un equipo m´ as r´ apido, se puede obtener una mejora en el procesamiento al reemplazar el equipo (ordenadores) empleados para c´ alculos, pero el costo usualmente se incrementa de forma exponencial mientras que el desempe˜ no del mismo crece de forma lineal, de manera que es necesario encontrar el equilibrio en este aspecto para obtener un resultado apropiado. Y finalmente, el tercer enfoque es dividir el c´ alculo entre varios ordenadores, donde se puede considerar el empleo de otras t´ ecnicas como puede ser el paralelismo, en el que se busca la ejecuci´ on de varias instrucciones de forma simult´ anea. En HPC hay m´ ultiples formas de lograr esto, una de ellas es el soporte nativo de esta modalidad de operaci´ on en la arquitectura interna de los CPU usados o bien, otra forma de lograrlo es utilizar varias computadoras interconectadas entre s´ ı para distribuir las tareas a realizar entre ellas. 2.1.1. Arquitectura de ordenadores Usualmente las computadoras se clasifican en base a su tama˜ no y desempe˜ no, por decirlo as´ ı, existen las microcomputadoras, las estaciones de trabajo, las minicomputadoras, los llamados mainframes y las s´ upercomputadoras. Pero para los fines de este documento esa clasificaci´ on se queda muy corta, ya que el desarrollo tecnol´ ogico hace que f´ acilmente una microcomputadora supere en capacidades a un mainframe en poco tiempo; de modo que se necesita poder agrupar los sistemas de una manera m´ as apropiada, especialmente cuando se introducen conceptos como la computaci´ on paralela y las arquitecturas HPC. Para lograr una clasificaci´ on acorde a las actividades de altas prestaciones, es necesario traer a discusi´ on el paradigma b´ asico de la arquitectura moderna de computadoras, que ha sido atribuido al matem´ atico de origen h´ ungaro John Von Neumann. ´ El planteaba que la estructura b´ asica de cualquier ordenador se basaba en una CPU conectada a una memoria por medio de un canal de comunicaci´ on o BUS, de manera que las instrucciones y datos se almacenan en la memoria y se mueven a la CPU por medio de este. El rendimiento global del ordenador depende tanto de la velocidad de la CPU para ejecutar instrucciones asi como del traslado de datos hacia la memoria (llamado tambi´ en velocidad de BUS) conjugada con la capacidad de la memoria para realizar sus operaciones internas. A la fecha, se han desarrollado m´ ultiples tecnolog´ ıas para mejorar el rendimiento de las CPU, por ejemplo se encuentra la tecnolog´ ıa RISC (Instrucciones Reducidas de Computador) tiene como objetivo disminuir y uniformar las instrucciones internas de los procesadores, a trav´ es de la eliminaci´ on de ciclos de ciertas instrucciones, aumentando la velocidad del reloj de la CPU. Tambi´ en se han desarrollado las llamadas arquitecturas s´ uperescalares utilizando unas estructuras conocidas 9 JOS ´ EISAAC ZABLAH ´ AVILA como segmentaci´ on o tuber´ ıas (pipelining), de manera que se pueden ejecutar dos o m´ as instrucciones simult´ aneas por ciclo del reloj de la CPU, mejorando la velocidad de los mismos. Por otro lado, la memoria (espec´ ıficamente la RAM) ha aumentado en cuanto a su ancho de banda o bandwidth, que b´ asicamente se explica como el aumento de la cantidad de bits que se transfieren entre los chips de memoria hacia el BUS del sistema. De este modo, se reducen los cuellos de botella que predijo en su momento Von Neumann, ya que el mayor problema de los sistemas computacionales a nivel te´ orico es que una CPU quede con ciclos libres, debido a que no hay instrucciones a procesar porque la memoria es muy lenta como para mantener un flujo constante de datos en el BUS. Por lo tanto, los fabricantes se han esforzado a trav´ es del tiempo por mejorar esta situaci´ on. Inicialmente las s´ upercomputadoras contaban ´ unicamente con un s´ olo CPU s´ uperescalar o vectorial, dise˜ nadas espec´ ıficamente para ellas. Hoy en d´ ıa, es posible crear arquitecturas HPC con cientos o miles de CPUs, usando para ello sistemas multiprocesador y multicomputador. Los sistemas multiprocesador son clasificados en base a su arquitectura de manejo de memoria, existen de esta forma los sistemas llamados de memoria de acceso uniforme (UMA –Uniform Memory Access) y los de memoria de acceso no uniforme (NUMA – Nonuniform Memory Access). Las diferencias b´ asicas radican en que los sistemas UMA (tambi´ en llamados SMP por sus siglas en ingl´ es Symmetric MultiProcessors) s´ olo posee una ´ unica memoria que es compartida; de forma que s´ olo existe un mapa de direcciones (en las mismas ubicaciones de la memoria f´ ısica) sin tener en cuenta las CPU. Explicado de manera diferente, es que la memoria principal del sistema es igualmente accesible por todas las CPU que conforman el sistema, aclarando que cada CPU posee su propio cach´ e que facilita este modo de operaci´ on. Por otra parte, los sistemas con arquitectura NUMA se diferencian con los primeros porque cada CPU posee un espacio propio reservado de memoria f´ ısica, de forma que la memoria total se divide entre el n´ umero de procesadores del sistema. La arquitectura de los sistemas multiprocesador poseen dos dificultades principales de implementaci´ on. La primera es la sincronizaci´ on, lo cual corresponde a contar con los datos en los buses en el orden apropiado para su procesamiento individual (esta caracter´ ıstica es mejor implementada en los NUMA, porque se mantienen fijas las asignaciones de memoria) y la segunda es lograr coherencia, considerada como la operaci´ on que asegura que todos los procesadores en conjunto tienen el valor actualizado de una misma variable. Lo anterior es importante, ya que en estos sistemas es necesario que los c´ alculos puedan ser granulados (esto es que puedan ser divididos en secciones) y as´ ı emplear la mayor cantidad de procesadores de 10 Cap´ ıtulo 2. Estado del arte forma simult´ anea para lograr resultados en menos tiempo. Los multicomputadores, es una configuraci´ on que se integra al unir un conglomerado de ordenadores de forma que trabajen en conjunto. Estos sistemas cuentan con tres elementos b´ asicos, el primero son varios ordenadores. El segundo, es acceder a una red que los interconecte. El tercero, es el software que posibilita a todo el hardware para compartir el trabajo y llevarlo a cabo. Usualmente, estos sistemas pueden configurarse con equipos de tipo comercial (no especializado), de manera que el costo de construcci´ on frente a los sistemas de multiprocesadores es mucho menor. Los sistemas multicomputador, pueden ser dedicados exclusivamente a una tarea espec´ ıfica o a varias a la vez. Poseen la facilidad de que los ordenadores que lo conforman pueden ser agregados o retirados conforme a las necesidades (llamados tambi´ en nodos). Este tipo de sistemas se pueden clasificar conforme a la interconexi´ on y funciones que desempe˜ nen los nodos. 2.1.2. Distribuci´ on geogr´ afica de los centros de computaci´ on de alto rendimiento La introducci´ on del primer ordenador personal se realiz´ o a principios de la d´ ecada de los ochenta. Hoy en d´ ıa, el avance en todas las ´ areas de conocimiento requieren en sus diversos procesos contar con la interacci´ on de sistemas inform´ aticos y sus dispositivos asociados, es por ello que en la actualidad se le conoce como la era de la informaci´ on y del conocimiento. Las necesidades computacionales espec´ ıficas como ser la capacidad de c´ alculo, vol´ umen de almacenamiento, capacidad de memoria RAM y otros recursos, no eran suficientes hace tres d´ ecadas, en la actualidad las mismas necesidades persisten a pesar del desarrollo tecnol´ ogico alcanzado, aun as´ ı existe en el mundo un amplio n´ umero de infraestructuras dedicadas exclusivamente a la resoluci´ on de problemas tecnol´ ogicos que requieren cantidades altas de capacidad de c´ alculo y memoria. La mejor referencia para conocer la evoluci´ on tecnol´ ogica de las infraestructuras HPC se encuentra en la lista TOP500[53], esta se actualiza cada seis meses y muestra una relaci´ on de los quinientos s´ upercomputadores m´ as potentes del mundo. Si analizamos la ´ ultima publicaci´ on al momento de redactar este documento con fecha noviembre del 2018, se observan las tendencias en la computaci´ on de altas prestaciones. En cuanto a la arquitectura empleada, hay 442 sistemas utilizado clusters (multiordenadores) y s´ olo 58 est´ an basados en sistemas multiprocesador. Hay una variedad de tecnolog´ ıas de red usadas por estos sistemas, las cinco preferidas con 10G Ethernet (23.8%), 40G Ethernet (12.6%), Infiniband FDR (12.2%), 11 JOS ´ EISAAC ZABLAH ´ AVILA de una infraestructura como servicio (IaaS). OpenNebula organiza las tecnolog´ ıas de almacenamiento, red, virtualizaci´ on, monitoreo y seguridad para desplegar servicios con m´ ultiples niveles de gesti´ on y ejecuci´ on. Para ello hace uso de m´ aquinas virtuales en infraestructuras distribuidas basados en pol´ ıticas de asignaci´ on de recursos locales y remotos [66]. A grandes rasgos OpenNebula posee tres componentes principales [79] [70], el primero es la capa de controladores la cual se comunica directamente con el sistema operativo subyacente y encapsula la infraestructura como un servicio abstracto. Entre sus funcionalidades se encuentra la creaci´ on, inicio y cierre de m´ aquinas virtuales (MV), la asignaci´ on de almacenamiento para MV y la supervisi´ on del estado operativo de las m´ aquinas f´ ısicas y MV. La segunda es la capa principal, su funci´ on es la de administrar los ciclos de vida completos de las MV, incluyendo la configuraci´ on din´ amica de red y direcciones IP, la gesti´ on del almacenamiento y la asignaci´ on de recursos para los discos virtuales de las VM, entre otros. La tercera es la capa de herramientas, esta proporciona interfaces para la comunicaci´ on con OpenNebula, entre ellas est´ a la interfaz de l´ ınea de comandos (CLI), el navegador y la API libvirt; con esto los usuarios pueden administrar las MV. Existe la figura de un programador que administra las funcionalidad proporcionada por la capa principal. Con relaci´ on al almacenamiento, el repositorio de im´ agenes de MV se utiliza para almacenar y administrar aquellas que son registradas por los administradores y usuarios, permitiendo el despliegue r´ apido de MV y compartir la mismas. OpenNebula emplea un sistema de archivos de red siendo por omisi´ on el NFS. Entre los hipervisores soportados se encuentran Xen, KVM y VMWare. Los diversos componentes pueden observarse en la figura 2.4. 2.4.2. OpenStack Es una soluci´ on basada en software libre, es de c´ odigo abierto y se utiliza para desplegar plataformas de computaci´ on en la nube bajo la modalidad de infraestructura como servicio (IaaS). Consta de componentes interrelacionados que controlan diversas agrupaciones de hardware pudiendo ser estos de varios proveedores de procesamiento, almacenamiento y recursos de red a trav´ es de un centro de datos. Los usuarios lo administran por medio de un panel de control basado en web, o bien mediante herramientas de l´ ınea de comandos y adicionalmente se tiene soporte de forma nativa para su control mediante servicios web [89]. La arquitectura de OpenStack esta conformada por siete partes principales [70][79] , la primera es Nova la cual es un controlador de la infraestructura en la nube, posee seis componentes como ser Nova-API, Message-Queue, Nova-Compute, Nova-Network, Nova-Volume 18 Cap´ ıtulo 2. Estado del arte Figura 2.4: Diagrama que muestra los componentes de OpenNebula [66]. yNova-Scheduler. Este componente brinda la funcionalidad del ciclo de vida completo de las instancias gestionadas por OpenStack, mostr´ andose como una plataforma administradora de recursos computacionales y de red, permitiendo la autorizaci´ on junto con el escalado conforme a las necesidades de ejecuci´ on. Todos los componentes de la arquitectura siguen una pol´ ıtica de operaci´ on como ser la de no compartici´ on shared-nothing y la basada en la mensajer´ ıa (messaging-based); el t´ ermino shared-nothing hace referencia a que cada componente o cada grupo de componentes pueden ser instalados en cualquier anfitri´ on, ya sean todos en un mismo hardware o diferentes componentes en m´ ultiples ordenadores. En cambio el messaging-based se aplica cuando el controlador de la nube se comunica con los diferentes elementos, intercambian informaci´ on de operaci´ on y estado entre si; para ello existe otro componente llamado servidor de colas (Queue Server) el cual desarrolla esta pol´ ıtica respecto a los elementos como ser Nova-Volume, Nova-Network ySwift. La comunicaci´ on entre los componentes es as´ ıncrona, lo que ayuda a que las acciones de los usuarios no impactan por largos per´ ıodos la operaci´ on del gestor OpenStack. La segunda parte es Swift, la cual es una infraestructura de almacenamiento de objetos escalable que incluye un servidor proxy, un servidor de objetos, un servidor de cuentas, un servidor contenedor y el llamado anillo. Es 19 JOS ´ EISAAC ZABLAH ´ AVILA un sistema de almacenamiento a largo plazo para un tipo m´ as permanente de datos est´ aticos que se pueden recuperar, aprovechar y actualizar [7]. Las caracter´ ısticas y funcionalidades principales son el almacenamiento seguro de una gran cantidad de objetos de diferente tama˜ no, proporcionar redundancia de datos, capacidad de archivado y transmisi´ on de medios. La tercera parte es Glance, este componente ofrece las capacidades de gesti´ on de im´ agenes de MV, est´ a conformado por dos elementos Glance-Registry encargado de la creaci´ on y GlanceControl con la funci´ on de operaci´ on. La cuarta es Cinder que proporciona almacenamiento de bloques persistente para instancias de c´ alculo, este servicio es responsable de administrar el ciclo de vida de los dispositivos de bloques, desde la creaci´ on y el archivado de vol´ umenes, hasta la puesta en marcha de las instancias. Las consideraciones de seguridad para el almacenamiento en bloque son similares a las del almacenamiento de objetos. El quinto componente es Neutron el cual proporciona diversos servicios de red para usuarios de la nube, incluyendo la administraci´ on de direcciones IP, DNS, DHCP, balanceo de carga y grupos de seguridad (lo que incluye reglas de acceso a la red, como las pol´ ıticas del cortafuegos). Adicionalmente proporciona un marco para redes definidas por software (SDN) que permite la integraci´ on con varias soluciones de red. Los aspectos de seguridad incluyen el aislamiento, la disponibilidad, la integridad y la confidencialidad del tr´ afico de red. El sexto componente es Keystone el cual act´ ua como un servicio compartido que proporciona mecanismos de autenticaci´ on y autorizaci´ on en toda la infraestructura de la nube, tambi´ en tiene soporte conectable para m´ ultiples formas de autenticaci´ on. La elementos de seguridad con este componente incluyen la confianza en la autenticaci´ on, la administraci´ on de tokens de autorizaci´ on y la comunicaci´ on segura. Finalmente, el s´ eptimo componente es Dashboard el cual proporciona una interfaz basada en web para los administradores y usuarios de la nube. Al usar esta interfaz se puede aprovisionar, administrar y monitorear los recursos de la nube. En este panel se implementan de forma com´ un y p´ ublica todos los aspectos de seguridad habituales de los portales web p´ ublicos. Los diversos componentes pueden observarse en la figura 2.5. 2.4.3. Apache CloudStack Apache CloudStack es un software de c´ odigo abierto dise˜ nado para desplegar y administrar grandes redes de m´ aquinas virtuales bajo la modalidad de infraestructura como servicio (IaaS) del paradigma de la computaci´ on en la nube. Se caracteriza por ser altamente escalable, por ello es utilizado por proveedores de servicios para ofrecer nubes p´ ublicas, privadas e h´ ıbridas [84]. La arquitectura de este gestor est´ a compuesta por dos tipos elementos como ser 20 Cap´ ıtulo 2. Estado del arte Figura 2.5: Diagrama que muestran los componentes de OpenStack [89]. el servidor de gesti´ on y la infraestructura. El servidor de gesti´ on administra por completo la nube y realiza la asignaci´ on de MV a los anfitriones (hosts). Una de las caracter´ ısticas notables en Apache CloudStack es la interfaz web que proporciona una administraci´ on completa de la nube de forma gr´ afica e intuitiva. Tambi´ en ofrece opciones muy interesantes, como la capacidad de definir m´ aquinas virtuales altamente disponibles que Apache CloudStack mantiene operativas sin la intervenci´ on del usuario o del administrador y la instalaci´ on de un sistema operativo que utiliza una imagen ISO est´ andar. Su instalaci´ on puede realizarse a trav´ es de la interfaz web sin la necesidad de utilizar herramientas adicionales. La infraestructura est´ a conformada por todo el hardware que es necesario para dar soporte a la nube. Apache Cloudstack est´ a compuesto en su operaci´ on interna por siete elementos, como ser: el servidor de administraci´ on de Apache CloudStack, la zona de disponibilidad, los pods, los cl´ usters, los nodos de c´ alculo (tambi´ en llamados nodos computacionales o CN) y los sistemas de almacenamiento primario secundario. El servidor de administraci´ on de Apache CloudStack controla la nube y la asignaci´ on de m´ aquinas virtuales. Una zona de disponibilidad se puede ver como un s´ olo centro de datos compuesto por varios pods y al menos un sistema de almacenamiento secundario. Un cl´ uster es una colecci´ on de CN que comparte el mismo hipervisor y el mismo sistema de almacenamiento primario. Los cl´ usteres representan el segundo nivel de escalado. Un pod es una colecci´ on de cl´ usteres y es una plataforma de hardware equivalente que incluye conmutadores (switches) de capa dos y representa el tercer nivel de escala f´ ısica en la plataforma. Tanto los cl´ usteres como los pods no son visibles para los usuarios finales. Los nodos de computaci´ on son sistemas habilitados por el hipervisor incluidos en la gesti´ on de Apache CloudStack. El almacenamiento primario est´ a asociado con el cl´ uster y almacena el sistema de archivos ra´ ız de m´ aquinas virtuales invitadas. El sistema de almacenamiento 21 JOS ´ EISAAC ZABLAH ´ AVILA secundario est´ a asociado con la zona de disponibilidad y almacena plantillas de MV, im´ agenes ISO e instant´ aneas de vol´ umenes del disco; convirti´ endose en el cuarto nivel de escalado f´ ısico. Gr´ aficamente la operaci´ on de Apache CloudStack se puede apreciar en la figura 2.6. Adicionalmente se puede decir sobre los nodos de computaci´ on (CN) que los mismos son en s´ ı anfitriones habilitados para ser gestionados por el hipervisor posterior a la instalaci´ on y configuraci´ on del agente de Apache CloudStack. Estos anfitriones representan el bloque f´ ısico b´ asico que nos permite escalar la plataforma de la nube. Se pueden agregar anfitriones adicionales en cualquier momento para aumentar la capacidad proporcionada para el despliegue y ejecuci´ on de m´ aquinas virtuales (MV) invitadas. Los anfitriones no son visibles para los usuarios finales, por lo tanto estos no pueden determinar los anfitriones que se les han asignado para ejecutar sus m´ aquinas virtuales invitadas. Apache CloudStack admite tres roles de usuario: administrador ra´ ız, administrador de dominio y usuarios sin privilegios. El administrador ra´ ız, puede gestionar toda la nube sin restricci´ on y es capaz de limitar a los dem´ as usuarios. Los administradores de dominio pueden realizar las operaciones de gesti´ on requeridas para que los usuarios que pertenecen a ese dominio puedan operar sin tener visibilidad de los CN f´ ısicos. El ´ ultimo, los usuarios no privilegiados, pueden administrar sus propias m´ aquinas virtuales y desplegarlas a voluntad. 2.5. Aplicaciones La mayor fortaleza de las tecnolog´ ıas y paradigmas que han sido implementados a gran escala radica en la disminuci´ on de costos, velocidad para obtener resultados, integraci´ on y actualizaci´ on entre otras. Las aplicaciones en la vida cotidiana toman ventaja de lo anterior para lograr nuevos productos y servicios de forma masiva que aprovechan la econom´ ıa de escala para llegar a precios m´ as competitivos al consumidor final. Las aplicaciones en la actualidad est´ an en m´ ultiples ´ areas, al punto que muchos sistema antiguos y que no eran migrados debido a su fiabilidad, hoy en d´ ıa han sido portados a la nube. En los apartados siguientes se detalla el papel de la nube en diferentes contextos. 2.5.1. Negocios La computaci´ on en la nube es reconocida como una tecnolog´ ıa que evoluciona cualquier proceso o actividad que se ejecuta sobre ella, a pesar de esto la idea de poseer negocios que operen completamente en la nube no es nueva y en la actualidad su potencial para condu22 Cap´ ıtulo 2. Estado del arte Figura 2.6: Diagrama de operaci´ on del gestor Apache CloudStack. 23 JOS ´ EISAAC ZABLAH ´ AVILA cirlos e innovarlos sigue aumentando. La nube ofrece la capacidad de cambiar los esquemas competitivos al ofrecer una plataforma para crear valor en los negocios. Se necesita que se dise˜ nen varios modelos de negocios que aprovechen y mejoren las cadenas de valor entre el consumidor final y la industria junto con los proveedores de servicios; de manera que se promuevan ventajas competitivas de forma sostenible [31] [46]. En este aspecto los elementos a considerar son: •Flexibilidad en los costos de operaci´ on: La nube ayuda a las organizaciones a reducir costos fijos por servicios inform´ aticos al prescindir del despliegue en el sitio de todos los recursos necesarios para operar, sino que solamente se contrata lo que se necesita en el momento justo. •Escalabilidad de la operaci´ on de negocio: Es la capacidad que permite a una organizaci´ on escalar f´ acilmente sus operaciones comerciales a trav´ es de una r´ apida expansi´ on de los recursos inform´ aticas sin inversi´ on exhaustiva de capital, benefici´ andose de las econom´ ıas a escala que definen al sector tecnol´ ogico. •Adaptabilidad al mercado: En el contexto actual las empresas definen su futuro en el mercado conforme se adapten a las necesidades cambiantes de los clientes, volvi´ endose este un factor de diferenciaci´ on frente a la competencia. La nube ofrece las herramientas tecnol´ ogicas necesarias para ayudar en este sentido a trav´ es de procesos de prototipado, innovaci´ on y acelerando el tiempo de comercializaci´ on. •Complejidad enmascarada: La nube ofrece a las empresas la capacidad de ocultar la complejidad de sus productos y servicios, de forma que el consumidor no se da cuenta y obtiene lo que busca de una forma sencilla y transparente. Al incrementarse la complejidad con el tiempo, se pueden realizar tareas de mantenimiento y actualizaci´ on sin que el usuario note que esto ocurre, evolucionando constantemente. •Variabilidad basada en contexto: Los servicios en la nube permiten la capacidad de almacenar informaci´ on sobre las preferencias del consumidor, permitiendo personalizar productos o servicios a las necesidades del cliente. Las experiencias que se adaptan al cambio sutil del usuario y las necesidades fragmentadas de ellos resultan un factor diferenciador en los negocios. •Interconexi´ on del ecosistema: Es la facilidad de la colaboraci´ on externa con socios y clientes, lo que conducen a mejoras en la productividad y el aumento de la innova24 Cap´ ıtulo 2. Estado del arte ci´ on. Las plataformas basadas en la nube pueden reunir grupos dispares de personas que pueden colaborar y compartir recursos, informaci´ on y procesos; logrando entre ellas productos y servicios de un nivel diferente. En los pr´ oximos a˜ nos se observar´ a el desarrollo y evoluci´ on de la manufactura basada en la nube, que es considerado como un modelo de fabricaci´ on centrado en el cliente que explora el acceso bajo demanda a una colecci´ on compartida de recursos de producci´ on diversificados y distribuidos para formar l´ ıneas reconfigurables. Lo anterior, incluye l´ ıneas temporales que mejoran la eficiencia, disminuyan los costos del ciclo de vida del producto; permitiendo emplear los recursos ´ optimos en respuesta a la demanda variable de las tareas generadas por el cliente [97]. La manufactura en la nube aprovecha el modelo de implementaci´ on de software como servicio a diferentes niveles de la cadena de producci´ on [98]. En la etapa de dise˜ no e ingenier´ ıa brinda recursos computacionales accesibles, mejora la eficiencia y el acceso a par´ ametros de dise˜ no desde diferentes grupos colaboradores en m´ ultiples regiones. Para el proceso de manufactura la nube ofrece las bondades de reducir costos, r´ apido prototipado y una mejora en la compartimento de recursos a trav´ es de una producci´ on distribuida y en cadenas de suministros justo a tiempo. Para la etapa final de comercializaci´ on la nube ofrece mejorar la interacci´ on con el cliente a trav´ es de evacuar las necesidades de este, porque impulsa la calidad y reduce el tiempo para que un producto o servicio sea comercializado. La nube ofrece atractivamente la oportunidad de evitar los costos de capital e incurrir en gastos previsibles de forma escalable conforme se modifican las necesidades de una empresa, siendo los m´ as beneficiados los negocios con uso ocasional de recursos o que consumen en r´ afagas, ya que s´ olo pagan por los recursos cuando los est´ an usando. Los negocios con patrones de uso estables tambi´ en se benefician debido al menor costo al comprar servicios en la nube que desarrollarlos, implementarlos y mantenerlos. Lo anterior representa el mayor aporte a cualquier modelo de negocio que requiera de recursos de las tecnolog´ ıas de la informaci´ on [59]. 2.5.2. Gobierno electr´ onico En la actualidad el ciudadano se beneficia del menor costo de los ordenadores y dispositivos m´ oviles, adem´ as cada d´ ıa estos se vuelven m´ as potentes en sus capacidades. Los gobiernos pueden interactuar mejor con los ciudadanos utilizando los medios digitales, ellos desarrollan 25 JOS ´ EISAAC ZABLAH ´ AVILA individualmente habilidades en lo relacionado al uso y acceso a tecnolog´ ıa simplificando el proceso de implementaci´ on de soluciones gubernamentales. La computaci´ on en la nube y espec´ ıficamente la arquitectura orientada a servicios (SOA) representan las tecnolog´ ıas puente hacia los ciudadanos en la actualidad, ya que estas permiten cubrir todo un pa´ ıs con soluciones de software accesibles en tiempo real. Se debe destacar que adem´ as en este caso las actividades de gobierno electr´ onico no se ven afectadas si las dependencias gubernamentales cuentan o no con los recursos y la preparaci´ on necesaria para este tipo de procesos. La disminuci´ on de los costos, el tiempo para tr´ amites y la disminuci´ on de los obst´ aculos burocr´ aticos junto con la simplificaci´ on de los procesos en las instituciones estatales representan indicadores medibles que son altamente valorados por parte de los contribuyentes. Los servicios al ciudadano que pueden ser ofrecidos mediante las tecnolog´ ıas mencionadas se conocen como servicios integrados que de forma t´ ıpica son brindados por las diferentes unidades de la administraci´ on p´ ublica que reemplazan a aquellos ofrecidos en ventanillas y requiriendo al interesado estar de forma presencial; por otro lado se encuentran los servicios de valor agregado que es la serie de negocios electr´ onicos (e-bussiness) que se pueden ofrecer e integrar tomando como base todos las capacidades del gobierno electr´ onico y finalmente se identifican los servicios varios que se caracterizan por reunir todos los servicios brindados por unidades administrativas y de negocios del gobierno en conjunto, permitiendo de ser requerido interactuar con terceros para ofrecer una alternativa conjunta al usuario [12]. La computaci´ on en la nube proporciona acceso a recursos inform´ aticos escalables que se encuentran remotos de una manera muy eficiente y r´ apida, este potencial ofrece cambiar dr´ asticamente la forma como las personas interact´ uan con el gobierno y sus servicios. Esta es una oportunidad que permitir´ ıa a pa´ ıses en donde se carece de los medios econ´ omicos para el despliegue de soluciones basadas en tecnolog´ ıas de la informaci´ on, utilizar de forma m´ as econ´ omica los recursos inform´ aticos compartidos y accesibles bajo demanda en otros sitios geogr´ aficos con una mejor relaci´ on de costos comparado a si estos se ofreciesen de forma local. Lo anterior al unirse con las tecnolog´ ıas m´ oviles de la actualidad, hace posible brindar servicios de forma ubicua sin importar la hora o el sitio donde se encuentre el usuario final [31]. Lo que hace potente a la computaci´ on en la nube para los servicios de gobierno electr´ onico es la capacidad que tiene este paradigma de dividir los problemas y replicar soluciones a gran escala, haci´ endolos accesibles mediante redes de ´ area amplia como el Internet. La nube cambiar´ a como los gobiernos toman decisiones, interact´ uan y responden a las necesidades 26 Cap´ ıtulo 2. Estado del arte de los ciudadanos en ´ areas como salud, seguridad, saneamiento, servicios administrativos, procesos democr´ aticos y en una finalidad casi infinita de servicios. 2.5.3. Televisi´ on Con el advenimiento de la nube, los sistemas dedicados para distribuci´ on de contenido televisivo est´ an evolucionando a utilizar infraestructuras basadas en Internet, lo que implica un cambio en tanto la forma en que vemos la televisi´ on, c´ omo se distribuye y llega a nosotros. La entrega y la producci´ on del contenido actual est´ a en la c´ uspide de la innovaci´ on y evoluci´ on; de forma que est´ an haciendo cambiar desde sus bases a todo el sector. La entrega v´ ıa aire, cable y sat´ elite gradualmente se ve reemplazada por Internet. Los responsables de entregar el contenido como ser los programadores (estaciones de TV) y los distribuidores de contenidos (productoras) est´ an evolucionando sus operaciones y modelos de negocio a un entorno m´ as ´ agil y flexible que ofrece la nube. Lo anterior significa tomar muchas de las funciones actualmente atendidas por hardware dedicado y software localizado, para moverlos a entornos de almacenamiento y computaci´ on distribuidos. En los ´ ultimos a˜ nos no se han visto cambios a gran escala en el servicio de televisi´ on semejantes a los que se est´ an dando en la actualidad, esto es semejante a lo que signific´ o para esta industria el reemplaz´ o de las ruedas mec´ anicas, el advenimiento del color, el uso de los transistores y la televisi´ on digital en alta definici´ on. La nube est´ a ocasionando una r´ apida transformaci´ on, siendo una de las m´ as destacadas el ahorro en los costos para los programadores y distribuidores; ya que desaparecen los medios f´ ısicos (discos compactos y cintas) reemplazados por medios digitales de menor costo, debido a que emplean el Internet para transporte, almacenamiento y diseminaci´ on de los contenido. El paradigma de la nube ofrece tambi´ en eficiencia, capacidad para optimizar las operaciones y facilidad de escalabilidad, mejor monetizaci´ on por reproducci´ on y audiencia, entre otros. Todo ello ha hecho evolucionar la producci´ on y distribuci´ on tradicionales de los flujos de trabajo (por ejemplo, desaparece la necesidad de codificaci´ on y transcodificaci´ on, la conversi´ on de archivos entre formatos y el empaquetado de secuencias donde se prepara el contenido para la entrega multipantalla) ahora todas esas actividades pasan a la nube sin la necesidad de distribuidores, programadores, radiodifusores o grupos de estaciones locales para acceder hardware localizado, hasta el punto de la personalizaci´ on del contenido para el usuario final. En resumen, la migraci´ on de la televisi´ on a la nube no s´ olo ofrece a los programadores ahorro y eficiencia de los distribuidores, pero tambi´ en innovaci´ on que podr´ ıa cambiar la te27 JOS ´ EISAAC ZABLAH ´ AVILA paralelismo, incluyendo el uso de algoritmos apropiados para obtener el m´ aximo rendimiento y reducir el tiempo de simulaci´ on [73]. Esta prueba de referencia simula de forma paralela un dispositivo 3D usando el modelo deriva-difusi´ on (D-D), desarrollado para estudiar las fluctuaciones intr´ ınsecas de los par´ ametros en semiconductores basados en heteroestructuras como transistores de alta movilidad de electrones (HEMT) o heteroestructuras libre de implantes (MOSFET)[80] [82]. Las ecuaciones D-D se discretizan utilizando el m´ etodo de elementos finitos (FEM)[49] en una malla tetra´ edrica no estructurada. El conjunto de ecuaciones obtenido se resuelve en paralelo en un n´ umero de procesadores utilizando la biblioteca est´ andar de la interfaz de paso de mensajes (MPI) [60]. El esquema de soluci´ on se basa en el desacoplamiento y la linearizaci´ on de las ecuaciones D-D usando iteraciones de Gummel. Finalmente, los m´ etodos de descomposici´ on de dominio, implementados por la biblioteca PSPARSLIB [74], se han empleado para resolver la fracci´ on local de los sistemas lineales asignados a cada procesador. 3.2. Evaluaci´ on de hipervisores En este apartado se describen los pasos seguidos para evaluar la infraestructura f´ ısica en conjunto con los hipervisores, empleando herramientas dise˜ nadas para medir las variables de referencias de los diferentes componentes de hardware, obteniendo de esta forma valores comparables con otros entornos [101][105]. 3.2.1. Metodolog´ıa Esta se enfoc´ o en la ejecuci´ on de las pruebas de referencia y la comparaci´ on de sus resultados sobre la m´ aquina f´ ısica y posterior una m´ aquina virtual gestionada por cada hipervisor, se ejecut´ o en las mismas condiciones para evitar la influencia de factores espurios que alteraran las mediciones obtenidas. Las consideraciones con IOZone, fue utilizar una partici´ on con una capacidad de 20 GB ubicada al final del disco duro. En ella se han grabado los datos temporales durante la ejecuci´ on, evitando de esta forma que los mismos se dispersen por diversas partes del disco e introduzcan condiciones de variabilidad y que vuelvan irreales los resultados. Respecto a Linpack se utiliz´ o la versi´ on 10.3.3 que es parte de las herramientas Math Kernel de Intel. Las m´ aquinas virtuales y los sistemas anfitriones reun´ ıan las caracter´ ısticas de ejecuci´ on siguientes: En todos ellos se desactiv´ o la memoria de intercambio (SWAP). 34 Cap´ ıtulo 3. Evaluaci´ on de los hipervisores Se emple´ o el sistema de archivos a nivel de partici´ on EXT2. Se utiliz´ o la misma cantidad de memoria RAM para la ejecuci´ on de pruebas en todos los sistemas (1 GB). Se desactiv´ o la funcionalidad de hyperthreading del microprocesador y adem´ as s´ olo se ha utilizado un n´ ucleo f´ ısico de procesador en todas las pruebas. En el caso espec´ ıfico del IOZone, se utiliz´ o una partici´ on al final del disco, ejecut´ andose bajo las mismas condiciones y en la misma regi´ on. Se desactiv´ o la utilidad CPUSpeed, que viene integrada en varias distribuciones de Linux. En KVM se emple´ o la utilidad virt-manager para gestionar las m´ aquinas virtuales y adem´ as en ellas se emplearon los controladores VirtIO [41]. Los sistemas estaban siendo usados de forma exclusiva para las pruebas de rendimiento, no contaban con protector de pantalla ni otro tipo de aplicaciones. 3.2.2. Infraestructura empleada Se utiliz´ o el hipervisor Xen 4.0.2-rc3 con Linux kernel 2.6.32.37 sobre CentOS Linux 5.6 (Xen4), Xen 3.1.2-238.9.1.el5 con Linux kernel 2.6.18-238.9.1.el5xen sobre CentOS 5.5 (Xen3) y KVM sobre Ubuntu 10.04.2 LTS con Linux kernel 2.6.32-31-server en combinaci´ on con la versi´ on de qemu-kvm 0.12.3(KVM). Todo este software es de c´ odigo abierto y se encuentran entre los m´ as ampliamente usados en la computaci´ on de alto rendimiento. En cuanto a los recursos de hardware se emple´ o un ordenador del fabricante Toshiba modelo Qosmio X500 con un procesador Intel Core i7 Q720 @ 1.60 GHz, con 4 GB de RAM y disco r´ ıgido de 500 GB de 7200 RPM interfaz SATAII para las pruebas del hipervisor KVM. Para Xen, se utiliz´ o un ordenador de escritorio con procesador Intel Xeon E5520 @ 2.27 GHz, con 16 GB de RAM y disco r´ ıgido de 500 GB de 7200 RPM; a este conjunto de equipos las llamaremos ”Equipamento 1”. Por otro lado, se utiliz´ o otra plataforma basada en hardware b´ asico (commodity hardware), que consist´ ıa en un ordenador con un procesador Intel Core 2 Duo E7500 @ 2.93 GHz, con 4 GB de RAM y disco duro de 500 GB tambi´ en con una velocidad de rotaci´ on de 7200 35 JOS ´ EISAAC ZABLAH ´ AVILA Equipamento 1 Equipamento 2 Sistema GFlops Tiempo(s) GFlops Tiempo (s) M´ aquina f´ ısica 8.36 59.49 10.31 49.15 Anfitri´ on KVM 8.61 57.30 10.31 49.25 MV KVM 5.54 85.07 5.24 88.26 Anfitri´ on Xen3 8.44 59.59 10.27 49.07 MV Xen3 6.76 74.47 9.93 51.38 Anfitri´ on Xen4 8.16 60.95 9.02 55.38 MV Xen4 8.12 61.13 8.73 62.01 Tabla 3.1: Resultados con Linpack, detalla capacidad de c ´ alculo y tiempo requerido de ejecuci´ on. RPM y conectado mediante una interfaz SATAII. Lo anterior es con el fin de conocer el comportamiento en este tipo de equipos, ya que es la configuraci´ on m´ as com´ un en los laboratorios de mi universidad de origen al momento de realizar las pruebas aqu´ ı descritas, este conjunto lo denominaremos ”Equipamento 2”. Se utilizaron las mismas versiones del sistema operativo y de los hipervisores que en el Equipamento 1, se han seguido los mismo criterios como los usados con la primera infraestructura tal como est´ a descrito anteriormente en este apartado. 3.2.3. Resultados Las diversas pruebas de referencia realizadas de tipo sint´ eticas y de aplicaci´ on se describen en los apartados siguientes e incluyen los resultados obtenidos: 3.2.4. Linpack Se utiliz´ o un tama˜ no de problema con un valor de 5000 en lo referente a la dimensi´ on y con valores de alineaci´ on de 4 KBytes. El resultado es dado en unidades de GigaFLOPS (GFlops) y se pueden observar en la tabla 3.1: Para el Equipamento 1, espec´ ıficamente la m´ aquina virtual (MV) en KVM tiene una disminuci´ on en la capacidad de c´ alculo de 3.07 GFlops respecto al anfitri´ on; requiriendo la MV de 27.77 segundos adicionales para completar la prueba. En Xen3, la MV report´ o una medici´ on inferior que el sistema anfitri´ on, perdiendo 1.68 GFlops y requiriendo 14.88 segundos adicionales para completar la prueba. En Xen4, los resultados fueron muy parecidos entre la MV y el anfitri´ on, donde se present´ o una m´ ınima p´ erdida de 0.04 GFlops en el sistema invitado y un tiempo similar. Es importante mencionar que el anfitri´ on Xen3 obtuvo resultados m´ as 36 Cap´ ıtulo 3. Evaluaci´ on de los hipervisores altos en esta prueba de rendimientos que en el anfitri´ on sin el kernel modificado del hipervisor, superando a ´ este por 0.08 GFlops, en cambio el anfitri´ on Xen4 report´ o valores inferiores al ser comparado con el sistema con kernel original perdiendo 0.20 GFlops. Para el Equipamento 2, tomando como referencia la m´ aquina f´ ısica comparada con el anfitri´ on KVM se obtuvo una medici´ on igual pero complet´ o la evaluaci´ on un d´ ecimo de segundo m´ as tarde. Por otro lado la MV KVM perdi´ o 5.07 GFlops y necesit´ o 39.01 segundos m´ as que el anfitri´ on KVM. El anfitri´ on Xen3 redujo su medida en capacidad c´ alculo en 0.04 GFlops al ser comparado con el ordenador f´ ısico y frente a la MV Xen3 esta ´ ultima perdi´ o 0.34 GFlops y utiliz´ o adicionalmente 2.31 segundos. El anfitri´ on Xen4, perdi´ o 1.29 GFlops frente al computador f´ ısico y al compararlo con la MV Xen4, esta rest´ o 0.29 GFlops necesitando 6.63 segundos adicionales para completar la prueba. Las diferencias entre las mediciones obtenidas con los anfitriones KVM y sus MV en ambos equipamentos pudo ser ocasionado por un mal mapeo de las instrucciones SSE3 del microprocesador hacia los anfitriones. Los mejores resultados mostrados en las pruebas del Equipamento 2 se debe a que el CPU usado tiene una frecuencia mayor que la del Equipamento 1. La MV KVM del Equipamento 2 fue la que requiri´ o m´ as tiempo para completar la prueba de todos los sistemas invitados, pero en cambio su anfitri´ on fue el m´ as eficiente de todos. 3.2.5. IOZone En esta prueba, se evalu´ o la tasa de transferencia para completar un proceso de escritura de un archivo de 4 GB. En la tabla 3.2, se muestran los resultados por cada uno de los sistemas y entornos evaluados: En el conjunto llamado Equipamento 1, los mejores resultados se obtuvieron en la tasa de escritura al emplear el sistema con el kernel sin modificar, en la tasa de re-escritura el mejor resultado fue el del anfitri´ on con Xen4. En KVM, la MV obtuvo en la tasa de escritura una transferencia 1779 Kbytes/s inferior al ser comparada con su anfitri´ on. En la tasa de reescritura ocurri´ o lo mismo pero con una diferencia de 3510 Kbytes/s. En el caso de Xen3, la MV present´ o una diferencia de 45718 Kbytes/s en la tasa de escritura y de 34806 Kbytes/s en la tasa de re-escritura, siendo esta inferior a la del anfitri´ on. En Xen4, los valores obtenidos de la MV fueron inferiores con una diferencia de 37030 Kbytes/s en tasa de escritura y de 33907 Kbytes/s en la tasa de re-escritura frente al sistema anfitri´ on. En estas pruebas, todos 37 JOS ´ EISAAC ZABLAH ´ AVILA Equipamento 1 Equipamento 2 Sistema Tasa Escritura Tasa Re-Escritura Tasa Escritura Tasa Re-Escritura M´ aquina f´ ısica 95605 67530 93775 94236 Anfitri´ on KVM 47273 50416 93845 95551 MV KVM 45494 46906 84753 77308 Anfitri´ on Xen3 95744 66445 95638 95465 MV Xen3 47026 31639 63383 66749 Anfitri´ on Xen4 86836 95387 93277 91259 MV Xen4 49797 61480 64526 68255 Tabla 3.2: Tasas de transferencia en Kbytes/s de escritura y re-escritura en IOZone. los anfitriones reportaron valores inferiores que la m´ aquina f´ ısica con el kernel sin modificar que trae por defecto la distribuci´ on del sistema operativo usado. Con el Equipamento 2, las pruebas realizadas en cuanto a escritura, el anfitri´ on Xen3 con una tasa de 95638 Kbytes/s tuvo el mejor resultado y la mejor tasa de re-escritura fue del anfitri´ on KVM con una medida de 95551 Kbytes/s. En KVM, la MV report´ o una tasa de escritura de 9092 Kbytes/s inferior al anfitri´ on y en la tasa de re-escritura se mantuvo la tendencia con una diferencia de 18243 Kbytes/s. En el caso de Xen3, la MV present´ o una diferencia en los resultados de 32255 Kbytes/s en tasa de escritura y de 28716 Kbytes/s en la tasa de re-escritura, siendo ambas inferiores al anfitri´ on. En Xen4 los valores reportados de la MV fueron inferiores con una diferencia de 33907 Kbytes/s en tasa de escritura y de 23004 Kbytes/s en la tasa de re-escritura frente al sistema anfitri´ on. Se mantiene un comportamiento de los anfitriones superando a sus sistemas invitados. Entre ambos conjuntos de hardware, las pruebas utilizaron los controladores VirtIO sobre KVM que emplean por defecto cach´ e para la gesti´ on del almacenamiento, en modo WriteThrough y ello repercute en los resultados obtenidos. Xen3 present´ o mejores valores en sus anfitriones, pero Xen4 fue m´ as eficiente a nivel de sistemas hu´ esped. 3.2.6. Simulaci´ on de nanodispositivos El resultado de la ejecuci´ on de simulaci´ on es dada en unidades de segundos y representa la medici´ on del tiempo requerido para completarse. Los mejores resultados son los que cuentan con cifras de menor valor, los mismos se pueden comparar en la tabla 3.3. En el conjunto del Equipamento 1, al comparar las MV con sus respectivos anfitriones, 38 Cap´ ıtulo 3. Evaluaci´ on de los hipervisores Equipamento 1 Sistema Tiempo (s) M´ aquina F´ ısica 4406.59 Anfitri´ on KVM 3600.89 MV KVM 4477.36 Anfitri´ on Xen3 4901.35 MV Xen3 5341.71 Anfitri´ on Xen4 4486.63 MV Xen4 4859.74 Tabla 3.3: Resultados de la simulaci´ on de nanodispositivos, valores en segundos. encontramos que la MV en KVM requiri´ o 876.47 segundos adicionales para completar la simulaci´ on. En el caso de la MV en Xen3, necesit´ o de 440.35 segundos m´ as para completar la prueba y en la MV en Xen4 requiri´ o de 373.11 segundos m´ as que el anfitri´ on. La MV y anfitri´ on m´ as eficientees fueron los de KVM, llegando a superarse a la misma m´ aquina f´ ısica con el kernel original y sin modificar del sistema operativo empleado, esto denota que el kernel con KVM posee mejoras en el manejo del almacenamiento en disco. S´ olo se ha evaluado el Equipamento 1, debido a que es el hardware con prestaciones semejantes a la de los servidores y estaciones de trabajo, siendo esta la configuraci´ on requerida para la ejecuci´ on de la prueba de referencia de nanodispositivos; el Equipamento 2 no re´ une las condiciones m´ ınimas de capacidad y por eso no se consider´ o. 3.3. Conclusiones Para el Equipamento 1, la MV que se ejecut´ o con el hipervisor Xen4 present´ o los mejores resultados en Linpack; ya que la diferencia con el anfitri´ on fue menor del 1%. En la prueba de IOZone se evalu´ o la tasa de transferencia en modo de escritura en la cual la MV bajo KVM present´ o la menor p´ erdida respecto al anfitri´ on, siendo un 3.76%. En cambio, los resultados obtenidos con la MV en Xen3 y Xen4 en la misma prueba, mostraban una p´ erdida mucho m´ as pronunciada. Cuando se evalu´ o la tasa de transferencia en modo re-escritura, la MV en KVM s´ olo perdi´ o un 6.96% frente al anfitri´ on, siendo mucho m´ as eficiente que la MV en Xen3 y Xen4. En la prueba de c´ alculo cient´ ıfico, present´ o una mayor eficiencia la MV en Xen4 (con poca diferencia con el Xen3), ya que requiri´ o´ unicamente un 8% m´ as tiempo que el anfitri´ on 39 JOS ´ EISAAC ZABLAH ´ AVILA para completar la simulaci´ on; lo cual representa mejores resultados que la MV en KVM. Se puede concluir que las MV que se ejecutan con el hipervisor Xen requirieron menos tiempo para completar las tareas evaluadas que estaban relacionadas con el c´ alculo y procesamiento intensivo. En cambio, la situaci´ on es distinta en cuanto a la tasa de transferencia de escritura en disco, en la cual la MV sobre KVM mostr´ o un mejor desempe˜ no que la MV de Xen. En los resultados obtenidos se observa una diferencia considerable entre las capacidades de las MV dependiendo del uso que se haga del disco o del procesador, consideramos que los controladores VirtIO pueden ser los causantes de las diferencias entre los hipervisores evaluados. En el caso del Equipamento 2, las pruebas realizadas con Linpack los anfitriones de KVM y Xen3 no mostraron cambios significativos en los resultados cuando son comparados con la m´ aquina f´ ısica, pero el anfitri´ on Xen4 perdi´ o un 12.51% en la misma operaci´ on. Las MV presentaron resultados heterog´ eneos, de forma que la MV KVM obtuvo la p´ erdida menos pronunciada comparada con su anfitri´ on con una proporci´ on de 9.88%, pero la m´ as penalizada fue la MV Xen4 con una ca´ ıda del 72.90%. La MV Xen3 y la MV Xen4 s´ olo perdieron un 3% de eficiencia frente a sus anfitriones, pero la KVM MV perdi´ o un 49.18%. En IOZone, la tasa de escritura del anfitri´ on Xen3 fue 2% superior que la de sus contrapartes; pero en general no hubo diferencias significativas frente al ordenador base. En la tasa de re-escritura los anfitriones mantuvieron un comportamiento muy similar al ordenador anfitri´ on, las diferencias m´ as pronunciadas fueron la del anfitri´ on KVM que obtuvo un rendimiento mayor en 1.4% mientras que el anfitri´ on Xen4 fue menos eficiente por un 2.87%. En cuanto a los sistemas invitados, la MV KVM obtuvo los mejores resultados en la tasa de escritura y en la tasa de re-escritura, perdiendo un 9.69% y 19.09% respectivamente frente al anfitri´ on. La MV Xen3 perdi´ o 33.73% en la tasa de escritura y un 30.8% en la de re-escritura. De los resultados obtenidos se deduce que el hipervisor KVM maneja a nivel de anfitriones un rendimiento muy similar con el ordenador f´ ısico pero sus MV pierden capacidad de c´ alculo lo que las convierte en una mala opci´ on para aplicaciones que requieran virtualizar aplicaciones de procesamiento, pero para las que requieran acceso al sistema de archivos, su rendimiento ser´ a el mejor. Por otro lado, Xen tiene mejores capacidades si se requiere procesamiento, pero presenta un desempe˜ no reducido en el acceso al sistema de archivos, perdiendo hasta un terci´ o de la capacidad f´ ısica en sus MV. 40 CAP´ ITULO 4 CASOS DE USO La inform´ atica cient´ ıfica implica el dise˜ no de modelos matem´ aticos generalmente caracterizados por requerir alta capacidad computacional para abordar los nuevos desaf´ ıos [93]. Debido a que la complejidad de los c´ alculos y modelos crece con el tiempo, las aplicaciones usadas generalmente requieren recursos inform´ aticos con mayor capacidad. Las infraestructuras de altas prestaciones proporcionan a los usuarios la potencia inform´ atica necesaria para abordar estos problemas, pero su costo, complejidad y el mantenimiento dificulta su uso. Por otra parte, en los ´ ultimos a˜ nos surgi´ o una nueva alternativa conocida como computaci´ on en la nube [95]. La principal ventaja de la nube es la posibilidad de escalar seg´ un la demanda y la potencia inform´ atica requerida, generalmente en forma de m´ aquinas virtuales (VM) que ejecutan el software del usuario, sobre una cierta infraestructura f´ ısica. En este apartado se detallan las aplicaciones analizadas y evaluadas, que se encuentran en uso por los investigadores de mi universidad al momento de la redacci´ on del presente documento. Se han agrupado de acuerdo a las ´ areas de estudio que mayor trabajo cient´ ıfico y t´ ecnico realizan. 4.1. Astronom´ıa y astrof´ısica La astronom´ ıa se define como la ciencia del universo, estudia el movimiento, estructura, origen y desarrollo de los cuerpos celestes asi como de los sistemas que estos conforman [72]. Lo anterior lo hace por medio de tres tareas fundamentales: la primera, es el estudio de las posiciones, movimientos reales y aparentes de las estrellas. La segunda, es el estudio de la estructura f´ ısica y de la materia que compone los cuerpos celestes. La tercera, es el JOS ´ EISAAC ZABLAH ´ AVILA desarrollo y resoluci´ on de los problemas de la posible evoluci´ on y destino de los cuerpos celestes, incluyendo los sistemas que estos conforman. Dado lo anterior, esta ciencia se divide en astrometr´ ıa o astronom´ ıa posicional, astrodin´ amica o mec´ anica celeste y astrof´ ısica [6]. Este ´ ultimo campo, est´ a dividido en cosmolog´ ıa, astrof´ ısica, radioastronom´ ıa, astronom´ ıa de rayos X, rayos gamma, infrarrojos, ultravioleta y estad´ ısticas estelares. Siendo m´ as espec´ ıfico, la radioastronom´ ıa estudia las estrellas y estructuras que emiten radiaciones en la longitud de onda que corresponde al segmento de radio del espectro electromagn´ etico. 4.1.1. GADGET2 GADGET2 es un conjunto de programas que su c´ odigo fuente est´ a libremente disponible para la realizaci´ on de simulaciones cosmol´ ogicas de N-cuerpos considerando la hidrodin´ amica de part´ ıculas suavizadas (SPH - Smoothed-particle hydrodynamics) [8][54] para usarse en infraestructuras paralelas de memoria distribuida. GADGET2 utiliza un modelo de comunicaci´ on implementado con la interfaz MPI estandarizada [88]. El c´ odigo fuente se puede ejecutar en pr´ acticamente todos los sistemas de s´ uper ordenadores en uso actualmente, incluyendo cl´ usteres conformados por estaciones de trabajo y ordenadores personales individuales. GADGET2 realiza los c´ alculos de las fuerzas gravitacionales usando un algoritmo de ´ arbol jer´ arquico (opcionalmente puede utilizar de manera combinada con un esquema de malla de part´ ıculas para considerar las fuerzas gravitacionales de largo alcance) y permite representar los flu´ ıdos por medio de hidrodin´ amica de part´ ıculas suavizadas (SPH). El c´ odigo puede utilizarse para estudios de sistemas aislados o para simulaciones que incluyan la expansi´ on cosmol´ ogica del espacio, con o sin condiciones de frontera peri´ odicas. En todos estos tipos de simulaciones, GADGET2 sigue la evoluci´ on de un sistema de N-cuerpos auto-gravitante sin colisi´ on y permite opcionalmente incluir la din´ amica de gases estelares. Tanto el c´ alculo de la fuerza como el paso del tiempo de GADGET2 son totalmente adaptativos, con un rango din´ amico que en principio es ilimitado [104]. Esta herramienta de software se puede utilizar para abordar una amplia gama de problemas astrof´ ısicamente interesantes, que van desde la colisi´ on y la fusi´ on de galaxias hasta la formaci´ on de una estructura a gran escala en el Universo. Con la inclusi´ on de procesos f´ ısicos adicionales como el enfriamiento y calentamiento radiativo, GADGET2 tambi´ en puede usarse para estudiar la din´ amica del medio intergal´ actico gaseoso o bien para abordar la formaci´ on estelar y su regulaci´ on mediante procesos de retroalimentaci´ on [83]. 42 Cap´ ıtulo 4. Casos de uso Infraestructura GADGET2 fue ejecutado sobre tres infraestructuras como ser una m´ aquina virtual, un cl´ uster virtual y en un ordenador f´ ısico anfitri´ on que los conten´ ıa. El objetivo es determinar cu´ al de estas plataformas resultaba m´ as eficiente al momento de tomar ventaja de la tecnolog´ ıa de virtualizaci´ on. Se ha considerado el efecto de la sobre demanda en la ejecuci´ on, de manera que se midi´ o el tiempo de c´ alculo con el hyperthreading habilitado y deshabilitado. Estas plataformas se detallan a continuaci´ on: •Anfitri´ on f´ ısico: El anfitri´ on f´ ısico cuenta con un microprocesador Intel Core i7-2600 con una velocidad de reloj de 3.40 GHz, con 8 GB de memoria RAM y conexi´ on de ´ area local tipo Gigabit Ethernet ejecutando el sistema operativo (SO) CentOS Linux 6.2 x86 de 64 bit. Las pruebas se realizaron empleando 1, 2, 4, 6 y 8 hilos de proceso. •M´ aquina virtual: Se ha desplegado sobre el anfitri´ on f´ ısico, se compone de una ´ unica MV gestionada por el hipervisor KVM, contando con 1 GB de RAM, con un n´ umero de cores variable, que se ha ido incrementando de 1 a 8, seg´ un las necesidades de procesamiento de GADGET2. De esta forma se puede evaluar el overhead que introduce la infraestructura virtualizada con KVM sobre el desempe˜ no de la aplicaci´ on. El sistema operativo de la MV es CentOS 6.2 x86 de 64 bit, de forma id´ entica al ordenador f´ ısico. •Cl´ uster virtual: Esta infraestructura tambi´ en fue desplegada sobre el anfitri´ on f´ ısico descrito, este cl´ uster est´ a conformado por ocho MV, que se inician de manera progresiva en funci´ on de las necesidades de ejecuci´ on. Cada una de estas MV se le asign´ o 1 GB de RAM y un n´ ucleo f´ ısico para poder operar. El cl´ uster utiliza una MV para hacer la funci´ on de Head y el resto hacen el papel de Nodes. Se diferencian entre s´ ı, porque las segundas carecen de las herramientas capaces de compilar aplicaciones, de manera que s´ olo se configuran como nodos de procesamiento. Es importante mencionar que los Nodes se despliegan de forma paulatina en funci´ on de los requerimientos computacionales, de esta manera podemos evaluar el rendimiento de GADGET2 empleando MPI [60] para comunicarse con los diferentes procesos que ahora estar´ an distribuidos en m´ ultiples MV usando el cl´ uster. 43 JOS ´ EISAAC ZABLAH ´ AVILA Infraestructura La infraestructura en la nube de tipo privada que fue empleada estaba gestionada con Apache CloudStack 4.0 y se utiliz´ o KVM como el hipervisor, todo ello administrado en los nodos computacions (CN). Los CN utilizan un procesador Intel Core [email protected] GHz con 8 GB de RAM y corriendo el sistema operativo CentOS 6.3 de 64 bits. El procesador Intel Core i7-2600 tiene cuatro n´ ucleos y ocho subprocesos, un cach´ e L2 de 4x256 Kbytes, un cach´ e compartido L3 de 8 MB, hyperthreading, tecnolog´ ıa de virtualizaci´ on Intel (VT-x) y virtualizaci´ on para entrada - salida (E/S) dirigida. La red de interconexi´ on es de tipo Gigabit Ethernet. Resultados Para satisfacer nuestros prop´ ositos, se implementaron dos tipos de m´ aquinas virtuales (MV): CASA MV y Linpack MV. Las caracter´ ısticas de CASA MV son las siguientes: emplea 1 CPU virtual, 1 GB de RAM y 20 GB de disco duro. Su sistema operativo es Ubuntu 12.04 64 bits. Esta MV proporciona el software CASA y tambi´ en los experimentos NGC4826, 3C129, NGC2403 y Linpack. Las caracter´ ısticas de Linpack MV son las siguientes: emplea 1 CPU virtual, 1 GB de RAM y 5 GB de disco duro con CentOS 5.5 de 64 bit. Para evaluar el impacto de la cantidad de MV implementadas por el sistema anfitri´ on en el rendimiento de las simulaciones CASA, consideramos n MV, donde n = 1, 2, 4, 6 y 8. La primera m´ aquina virtual ejecuta el software CASA y mide el tiempo de simulaci´ on. Las m´ aquinas virtuales n-1 restantes ejecutan Linpack en un modo de bucle infinito. NGC4826 Los resultados se muestran en la figura 4.3, al compararse las simulaciones para este cuerpo celeste se requiri´ o de mayor tiempo cuando se aument´ o el n´ umero de MV por anfitri´ on. Si el hyperthreading est´ a desactivado, la cantidad de tiempo requerido es mayor. En este caso, cuando se escala el n´ umero de MV hasta usar cuatro de ellas, el tiempo de simulaci´ on se incrementa en un 13% a que si s´ olo se emplease una de manera exclusiva. Para un mayor n´ umero de MV por anfitri´ on, se presenta un deterioro importante en el tiempo requerido, se observ´ o que al utilizar 6 u 8 MV los tiempos de simulaci´ on se incrementan en un 68% y 90% respectivamente, compar´ andolos a los resultados obtenidos con una sola MV. Al habilitar el soporte del hyperthreading y compararlo a las mediciones sin este, se encontr´ o que el tiempo 50 Cap´ ıtulo 4. Casos de uso Figura 4.3: Tiempo requerido por las m ´ aquina virtual (MV) para completar la simulaci´ on de la evoluci´ on de NGC4826, se muestra el efecto del soporte del hyperthreading. requerido para completar la simulaci´ on disminuy´ o un m´ aximo de un 7% al utilizarse cuatro o menos MV. En cambio la eficiencia aumenta alcanzando un 31% y un 51% para 6 y 8 MV respectivamente, aportando mejores tiempos en la simulaci´ on al presentarse sobre demanda de recursos lo que difiere sino se emplease el hyperthreading. 3C129 Los resultados se pueden observar en la figura 4.4. Se mantiene la tendencia del incremento en el tiempo de simulaci´ on cuando se aumenta el n´ umero de MV por anfitri´ on. Sin embargo, si el hyperthreading est´ a desactivado el aumento del tiempo requerido es un poco m´ as notable. En este caso, cuando se implementan cuatro o menos m´ aquinas virtuales, el aumento en el lapso de simulaci´ on es inferior al 4%. Para un n´ umero mayor de MV por anfitri´ on, hay un aumento en el tiempo, requiriendo un 14% m´ as al usarse 6 MV y un 24% m´ as si se emplean 8 MV; si estos resultados son comparados con los obtenidos con una MV. 51 JOS ´ EISAAC ZABLAH ´ AVILA Figura 4.4: Tiempo requerido por las m ´ aquinas virtuales (MV) para completar la simulaci´ on de la evoluci´ on de 3C129, se muestra el efecto del soporte del hyperthreading. NGC2403 Los resultados se muestran en la figura 4.5. En esta prueba de ejecuci´ on, se mantiene la tendencia como en los casos previos donde existe un aumento en el tiempo de simulaci´ on cuando se incrementa el n´ umero de MV por ordenador. Si el hyperthreading est´ a deshabilitado, la cantidad de tiempo requerido es m´ as notable cuando se ejecutan m´ as de cuatro m´ aquinas virtuales. En este caso, cuando se implementan cuatro o menos MV, el aumento en el tiempo de simulaci´ on es inferior al 4%. Para un mayor n´ umero de MV por ordenador, hay un deterioro importante en el lapso de ejecuci´ on, observ´ andose que con 6 y 8 m´ aquinas virtuales los tiempos de simulaci´ on se incrementan en torno a un 22% y un 30% respectivamente, comparado con los obtenidos con una MV. Linpack Se ha realizado un estudio similar a las simulaciones, con el fin de conocer la carga que tiene sobre un mismo anfitri´ on el incremento de MV hasta el m´ aximo de n´ ucleos l´ ogicos 52 Cap´ ıtulo 4. Casos de uso Figura 4.5: Tiempo requerido por las m ´ aquinas virtuales (MV) para completar la simulaci´ on de la evoluci´ on de NGC2403, se muestra el efecto del soporte del hyperthreading. disponibles, pero en este caso utilizando la prueba de rendimiento Intel Linpack, los resultados se muestran en la figura 4.6. Para ello, hemos utilizado un tama˜ no de problema de 5000, con valores de alineaci´ on de 4 KB. Intel Linpack proporciona el rendimiento promedio en GFlops. Se mantiene la tendencia de la disminuci´ on en los GFlops cuando se aumenta el n´ umero de MV por anfitri´ on. Al habilitar el hyperthreading, se puede apreciar un incremento en las operaciones de coma flotante hasta que el n´ umero de MV no superen los n´ ucleos f´ ısicos del sistema, reportando resultados con una magnitud de hasta un 1 GFlop superiores respecto cuando este soporte est´ a desactivado. En este caso, cuando se implementan seis u ocho MV se presenta una ca´ ıda de alrededor de 6 GFlops en las operaciones al contar con el hyperthreading activado. Sin embargo, si el hyperthreading est´ a deshabilitado y el n´ umero de MV supera a los n´ ucleos f´ ısicos, se obtienen mejores resultados en la prueba de Linpack. Conclusiones Se evaluaron simulaciones astron´ omicas sobre Apache CloudStack, empleando KVM como el hipervisor que administra m´ ultiples MV, todas ellas con un alto nivel de exigencia de 53 JOS ´ EISAAC ZABLAH ´ AVILA Figura 4.6: La gr ´ afica muestra la capacidad de procesamiento en GFlops obtenido por las m´ aquinas virtuales (MV) y el efecto del soporte del hyperthreading en esas mediciones. CPU. Para ello se ejecutan de forma concurrente en un mismo nodo de computaci´ on, tareas de simulaci´ on de computaci´ on intensiva, creando las condiciones del peor caso posible de implementaci´ on de MV en una infraestructura en la nube, es decir con sobre demanda de recursos de procesamiento. Los resultados obtenidos al simular la evoluci´ on estelar de los cuerpos celestes conocidos como NGC4826, 3C129 y NGC2403 mostraron un comportamiento similar con la degradaci´ on en el rendimiento cuando el hyperthreading estaba deshabilitado, esta condici´ on aumenta al utilizar m´ as de cuatro MV en un mismo anfitri´ on, ya que el procesador del nodo f´ ısico cuenta con cuatro n´ ucleos. En caso de habilitar el hyperthreading la disminuci´ on del tiempo requerido se mantuvo al utilizar m´ as de cuatro MV, pero en una proporci´ on menor que sin esta caracter´ ıstica habilitada. Para el caso de referencia en el que se us´ o Linpack, se determin´ o que no hay un efecto notable en las operaciones de coma flotante cuando el hyperthreading est´ a habilitado. Con los datos obtenidos se concluye que la realizaci´ on de simulaciones astron´ omicas en 54 Cap´ ıtulo 4. Casos de uso la nube es adecuada, ya que en todas las simulaciones realizadas se not´ o una reducci´ on del tiempo requerido. En cambio para simulaciones num´ ericas como las que realiza Linpack el hyperthreading no aport´ o beneficios de ejecuci´ on notables. 4.2. Multimedia En los ´ ultimos a˜ nos se incorporaron tecnolog´ ıas [56] como el correo electr´ onico, el chat, las teleconferencias y actividades en l´ ınea, para respaldar los procesos de ense˜ nanza y aprendizaje. Hoy vivimos la mayor revoluci´ on en inform´ atica, multimedia y la televisi´ on, desde la invenci´ on de la emisi´ on en color a principios de la d´ ecada de los cincuenta [2]. Actualmente los profesores y los estudiantes pueden ver v´ ıdeos en una variedad de medios, desde tel´ efonos m´ oviles, computadoras y hasta en pantallas de alta definici´ on. Estos cambios van de la mano con la evoluci´ on constante de la tecnolog´ ıa inform´ atica y de las herramientas computacionales que evolucionan constantemente para crear v´ ıdeos de calidad superior y de alta complejidad desde diferentes fuentes de contenido. Renderizaci´ on es el proceso de conformar medios animados y escenas. Esta es una actividad que consume mucho tiempo y altos recursos computacionales. Por lo general, las empresas y los centros de capacitaci´ on utilizan recursos costosos para reducir el tiempo necesario de edici´ on para preparar v´ ıdeos. Con el fin de aprovechar estas tecnolog´ ıas dentro de entornos docentes y de investigaci´ on, y con ello poder crear contenido audiovisual de alta calidad, pero con la condici´ on de no incurrir en la adquisici´ on de licencias costosas ni requerir recursos de hardware dedicados, esta secci´ on tiene como objetivo mostrar un m´ etodo para reutilizar el hardware existente en escuelas, facultades, laboratorios y otras instituciones. Todo ello con el fin de integrar v´ ıdeos en alta definici´ on mediante la implementaci´ on de tecnolog´ ıa en la nube y virtualizaci´ on de forma local [9]. 4.2.1. Handbrake HandBrake es un transcodificador de v´ ıdeo de c´ odigo abierto disponible para Linux, Mac y Windows. Esta aplicaci´ on toma los v´ ıdeos en diferentes formatos y codificaciones. Posteriormente a trav´ es de un proceso de conversi´ on los adecua para ser vistos en m´ ultiples dispositivos que van desde tel´ efonos m´ oviles, tabletas, ordenadores, hasta dispositivos profesionales de difusi´ on, permitiendo as´ ı poder utilizar cualquier v´ ıdeo en casi todo dispositivo que admita formatos modernos, posteriormente al ser procesados por esta aplicaci´ on [86]. 55 JOS ´ EISAAC ZABLAH ´ AVILA HandBrake funciona con archivos y formatos de v´ ıdeo m´ as comunes, la mayor´ ıa de ellos creados o capturados por c´ amaras profesionales y para consumidor, dispositivos m´ oviles como ser tel´ efonos y tabletas, grabaciones originadas en juegos y pantallas de computadora y tambi´ en soporta v´ ıdeos desde discos DVD y Blu-ray, entre otros. HandBrake aprovecha herramientas como ser Libav,x264 yx265 disponibles de c´ odigo abierto para crear nuevos archivos transcodificados a MP4 o MKV [23, 50], dependiendo de lo que seleccione el usuario como preferencia. Esta aplicaci´ on en cuanto al manejo de v´ ıdeos permite multiples operaciones como ser la de recortar y cambiar el tama˜ no, restaurar fuentes antiguas y de baja calidad, retirar los efectos causados por entrelazado y telecine, asi mismo poder manejar ciertos tipos de audio sin necesidad de conversi´ on. Ofrece la capacidad de mezclar el sonido envolvente discreto con el sonido envolvente matricial o est´ ereo, hacer ajustes a los niveles de volumen de audio y el manejo del rango din´ amico para ciertos tipos de audio, permite conservar los subt´ ıtulos existentes o bien puede agregar o quitar subt´ ıtulos suaves (estos son los que se almacenan como texto). HandBrake tambi´ en puede crear v´ ıdeos que sean m´ as peque˜ nos (ocupando menos espacio de almacenamiento en su dispositivo) que los originales; ya que los convierte a los est´ andares MP4 y MKV. Dentro de las ventajas complementarias que ofrece HandBrake es la de respetar la protecci´ on de copia. No funciona con archivos de v´ ıdeo que emplean gesti´ on de derechos digitales (DRM). Esto incluye, pero no se limita a contenido protegido contra copia en iTunes, Amazon Video, Netflix u otros proveedores en l´ ınea as´ ı como muchos discos comerciales de DVD y Blu-ray [4, 3, 47, 62]. Los profesionales de la multimedia en sus actividades diarias transcodifican formatos, generalmente desde fuentes crudas hacia archivos de formatos comprimidos, durante este proceso aprovechan las herramientas de software y de edici´ on no lineal, pueden hasta cierto punto agregar efectos, recortar fuentes, colocar traducciones, subt´ ıtulos, etc. El resultado puede ser ingestado en sistemas de automatizaci´ on televisiva o de otra ´ ındole de difusi´ on; estos sistemas requieren par´ ametros de v´ ıdeo bien definidos y estandarizados. Es por ello, que se requiere del proceso de transcodificaci´ on con el fin de unificar a un formato est´ andar. Lastimosamente este proceso toma mucho tiempo y requiere equipo que est´ e dedicado y no siempre es desatendido. En este caso de uso se propone una soluci´ on que pueda ejecutarse en segundo plano y sin la intervenci´ on ni supervisi´ on del usuario, requiriendo ´ unicamente interacci´ on al momento del env´ ıo del archivo. 56 Cap´ ıtulo 4. Casos de uso Infraestructura Al momento de realizar las pruebas no hab´ ıa en los repositorios oficiales para el sistema operativo usado ning´ un paquete precompilado disponible de HandBrake, ya que pretendemos utilizar el mismo que en los otros casos de uso realizados hasta el momento y descrito en los diferentes cap´ ıtulos. Por lo tanto s´ olo se ten´ ıan dos opciones: la primera era descargar las archivos de c´ odigo fuente desde del sitio web del desarrollador para posteriormente compilarlo e instalarlo utilizando la consola del sistema, o bien una segunda opci´ on es la de agregar manualmente un repositorio de terceros. Para nuestro caso particular utilizaremos el repositorio, para as´ ı evitar la necesidad de instalar paquetes adicionales y herramientas de desarrollo en el sistema donde realizar´ ıamos las mediciones, ya que no podremos identificar el efecto de ellas en el rendimiento general. T´ ıpicamente, el proceso de transcodificaci´ on es dedicado y se pretende lograr cumplir con normas de operaci´ on con los archivos resultantes, ya que en nuestro caso de uso se probar´ a en el flujo de trabajo de una estaci´ on de televisi´ on. Por lo tanto, la infraestructura descrita en esta secci´ on presenta una soluci´ on desatendida y de ejecuci´ on en segundo plano. Gr´ aficamente se muestra en la figura 4.7. El planificador de tareas recibe las peticiones de procesamiento por medio de un script que de forma peri´ odica verifica por nuevos archivos de medios en la carpeta compartida de red en el sistema de archivos NFS. Al ser detectado es movido a una carpeta particular que s´ olo es accesible por el planificador y las m´ aquinas virtuales que realizan la transcodificaci´ on, estas se est´ an ejecutando de forma distribuida en la intranet en diferentes anfitriones; cada MV recibe un archivo completo para transcodaje a la vez y al finalizar el producto de este proceso se almacena en otra carpeta donde el planificador copia a una tercera carpeta de salida en el sistema de almacenamiento de red para uso y manipulaci´ on por parte de los usuarios, los cuales si se desea pueden ser enviados de manera autom´ atica al sistema de automatizaci´ on de difusi´ on para su uso a trav´ es de la plataforma de distribuci´ on de contenidos preferida, en caso de ser necesario. Se aclara que no se hace una divisi´ on en fragmentos de los archivos fuente de v´ ıdeo para ser transcodificado de forma concurrente por m´ ultiples MV. Lo anterior no se lleva a cabo a pesar que existen utilidades que se podr´ ıan emplear para ello, como ser ffmpeg, videosplit o mencoder; pero es aqu´ ı que surge un problema t´ ecnico complejo como es la de identificar la ubicaci´ on precisa de los fotogramas clave al momento de ensamblar un s´ olo archivo de salida, debido a esta falencia se genera un error que es apreciable al momento de visualizar el archivo 57 JOS ´ EISAAC ZABLAH ´ AVILA Figura 4.7: Flujo de trabajo del transcodaje. Handbrake se encuentra virtualizado y su uso es transparente al usuario. transcodificado y que no fue posible encontrarle una soluci´ on pr´ actica. Por la raz´ on descrita se decidi´ o enviar un archivo por nodo de forma secuencial. Es importante aclarar que para las mediciones realizadas por la t´ ecnica descrita, fue requerido sincronizar el reloj de todos los nodos virtuales y anfitriones por medio del servicio basado en el protocolo de tiempo de red (NTP). As´ ı mismo se ha usado el hipervisor Oracle VirtualBox 4.1.14 [94]. Este fue ejecutado sobre ordenadores equipados con un microprocesador Intel i5-3570 el cual cuenta con cuatro n´ ucleos con una frecuencia b´ asica de 3.4 GHz y usando el soporte para el llamado modo turbo, con el cual este CPU puede entregar hasta 3.8 GHz de velocidad, el mismo cuenta con soporte para extensiones VT-x, vPro y con una arquitectura de 64 bits y no posee soporte para hyperthreading. Para las mediciones se utiliz´ o un ordenador anfitri´ on f´ ısico que cuenta con 16 GB de memoria RAM del cual se tomaron 4 GB para las MV. El sistema operativo usado ha sido Ubuntu Linux 13.01 64 bits. Las pruebas realizadas eval´ uan el uso de diferente n´ umero de n´ ucleos combinados con el soporte turbo activo o inactivo, ya que nos interesa conocer si esta funcionalidad aporta beneficios en la ejecuci´ on. Se han realizado una serie de diez ejecucio58 Cap´ ıtulo 4. Casos de uso nes sucesivas donde se ha medido el tiempo requerido para transcodificar un archivo origen en formato MTS con una duraci´ on de treinta minutos exactos y con una resoluci´ on de alta definici´ on completa en 1080i. El formato resultante es MPEG4 con la misma resoluci´ on y duraci´ on. En cuanto a la adecuaci´ on de la disponibilidad de la RAM en los diferentes sistemas al momento de completar las medidas sucesivas fue necesario hacer ajustes manuales a los bancos de memoria f´ ısica instalados. En el caso del anfitri´ on se dejaron ´ unicamente 4 GB de RAM al momento de las pruebas, con ello se evit´ o afectar las mediciones por las diferencias en RAM al ser comparadas a la capacidades que tienen las m´ aquinas virtuales. En el gestor de las MV, se configur´ o el uso de 4 GB de RAM por sistema invitado, pero el anfitri´ on se le colocaron 16 GB de RAM f´ ısicos. Con ello se pretende evitar situaciones de inanici´ on y sobre demanda de recursos, minimizando sus efectos nocivos en el desempe˜ no. Resultados En el anfitri´ on los resultados fueron mejorando conforme se incrementaban los n´ ucleos disponibles para transcodificar de forma concurrente y esto disminu´ ıa el tiempo requerido directamente. Al habilitar el soporte del turbo en el microprocesador fue beneficioso, porque ayudaba a disminuir el tiempo requerido para completar las tareas. Tomando el promedio de las m´ ultiples ejecuciones llevadas a cabo, se obtuvo con cuatro n´ ucleos y con el soporte turbo habilitado, los mejores resultados, los cuales requirieron un total de 969.91 segundos para completar las tareas, mientras tanto que si se deshabilitaba el soporte del turbo el per´ ıodo de ejecuci´ on necesitaba a 1021.83 segundos, siendo el segundo mejor resultado; de la misma manera al emplear un s´ olo n´ ucleo se requiri´ o de 3842.68 segundos para completar la transcodificaci´ on, siendo el peor resultado de toda la serie. Los resultados generales se muestran en la tabla 4.1. En la m´ aquina virtual, los resultados mejoraron conforme se aumentaban los n´ ucleos disponibles para transcodificar de forma concurrente como se observa en la tabla 4.2, pero al contar con el soporte del turbo en el microprocesador anfitri´ on el tiempo requerido aument´ o. Tomando el promedio de las m´ ultiples ejecuciones llevadas a cabo, se obtuvo con cuatro n´ ucleos y sin el soporte turbo habilitado, el menor tiempo de ejecuci´ on, donde se requiri´ o un total de 1112.02 segundos para completar la tarea ejecutada, mientras que si se contaba con el soporte turbo el tiempo requerido aumenta a 1213.97 segundos, este ´ ultimo valor representa el segundo mejor resultado. De la misma forma, al emplear un s´ olo n´ ucleo se requiri´ o 59 JOS ´ EISAAC ZABLAH ´ AVILA Figura 4.9: Flujo de trabajo en un centro de capacitaci´ on, n´ otese que los estudiantes no saben donde se encuentran realmente los nodos f´ ısicos, pueden los mismos estar distribuidos en m´ ultiples sitios siempre que est´ en conectados a trav´ es de una red. audio/v´ ıdeo, se utiliz´ o el c´ odec MPEG4 [23]. Actualmente este ha sido el est´ andar preferido a nivel mundial para la edici´ on de v´ ıdeo desde la d´ ecada de los noventa. Para evaluar si la infraestructura propuesta en la nube podr´ ıa considerarse como una buena opci´ on para el procesamiento, preparamos una serie de pruebas usando archivos fuentes definidos como recursos de un proyecto de edici´ on. La primera fue con un v´ ıdeo de salida de 40 segundos de duraci´ on con una resoluci´ on de 1080/60p. La segunda emple´ o un v´ ıdeo de 30 minutos a 720p. La tercera prueba us´ o un v´ ıdeo de 30 minutos a 720p, compuesto por treinta fragmentos de un minuto sin transiciones ni efectos. Ejecutamos las pruebas de renderizado inicialmente s´ olo en el nodo maestro utilizando dos n´ ucleos, luego se ejecut´ o con uno y posteriormente con dos nodos virtuales, empleando dos n´ ucleos cada uno. El objetivo de las pruebas es saber cu´ anto tiempo se necesita en cada configuraci´ on y c´ omo el proceso de renderizado puede ser beneficiado o penalizado con el uso de hyperthreading. Las primeras dos pruebas se llevaron a cabo en la infraestructura de la televisora y la ´ ultima en el centro de entrenamiento. Cuando se utilizan varios nodos, se configur´ o la opci´ on en Cinelerra que permite dividir 66 Cap´ ıtulo 4. Casos de uso Figura 4.10: Desempe˜ no con 40 segundos de v´ ıdeo a una resoluci´ on de 1080/60p. Barras m´ as cortas indican mejores resultados, ya que necesitan menos tiempo para completarse. autom´ aticamente el trabajo en varias partes. Cinelerra en s´ ı mismo divide los trabajos tratando de dar el mismo n´ umero de partes a todas las m´ aquinas participantes (inclu´ ıdo el nodo maestro). De esta forma, el n´ umero de archivos generados escalar´ a con la cantidad de nodos empleados (siendo uno cuando s´ olo se realiza el renderizado en el nodo maestro, dos, cuatro, seis, ocho hasta diecis´ eis al contar con m´ ultiples nodos). Este m´ etodo evita que existan nodos sin trabajo en las diferentes pruebas realizadas. En la primera prueba se realiz´ o con el v´ ıdeo de 40 segundos a 1080/60p. El peor resultado fue obtenido cuando usamos el nodo maestro en combinaci´ on con un nodo virtual y especificando una salida de diecis´ eis archivos que requirieron en total 287 segundos, donde el nodo maestro necesit´ o 233 segundos para completar la tarea. El mejor tiempo se obtuvo empleando el nodo maestro y dos nodos virtuales especificando ocho archivos, la prueba se complet´ o en 125 segundos. Empleando la misma combinaci´ on con cuatro archivos, el tiempo requerido fue 134 segundos. Usando el nodo maestro y un nodo virtual, se obtuvo los mejores resultados con dos y cuatro archivos de salida; utilizando ´ unicamente 153 segundos en cada uno, esto es 28 segundos m´ as que el mejor tiempo de toda la presente prueba. Los resultados pueden observarse en la figura 4.10. 67 JOS ´ EISAAC ZABLAH ´ AVILA Figura 4.11: Desempe˜ no con 30 minutos de v´ ıdeo a una resoluci´ on de 720p. Barras m´ as cortas indican mejores resultados, ya que necesitan menos tiempo para completarse La segunda prueba es un proyecto que se requiere renderizar en un archivo de 30 minutos con una resoluci´ on de 720p, se pueden ver los resultados en la figura 4.11. En este caso se combinaron varias fuentes de v´ ıdeo y se agregaron transiciones para integrarlos y se agregaron efectos b´ asicos al conjunto. El tiempo de renderizado para el nodo maestro fue de 6487 segundos, siendo el peor resultado. Al agregar un nodo virtual y permitir fraccionar el proceso en seis archivos se obtuvo la mayor eficiencia posible en esta configuraci´ on utilizando s´ olo 3605 segundos. Al agregar un segundo nodo virtual se logr´ o el mejor resultado con el presente proyecto, requiriendo 3072 segundos, permitiendo el uso de ocho fragmentos. Debido a que el proyecto esta formado por fuentes de v´ ıdeo heterog´ eneo combinada con efectos y transiciones que hacen que el conjunto difiera en complejidad en diferentes secciones, siendo unas partes la renderizaci´ on mas sencilla que otras. Es por ellos que se realiz´ o una tercera prueba con or´ ıgenes de v´ ıdeo homog´ enea, permitiendo a cada nodo realizar actividades computacionales similares. La tercera prueba se prepar´ o con la ingesta de 30 archivos de v´ ıdeo de duraci´ on de 60 segundos cada uno, vale aclarar que es un archivo que se le realiz´ o m´ ultiples copias de s´ ı mismo, los resultados se pueden apreciar en la figura 4.12. La resoluci´ on es de 1080i y no se 68 Cap´ ıtulo 4. Casos de uso Figura 4.12: Desempe˜ no con 30 minutos de v´ ıdeo a una resoluci´ on de 1080/60i. Barras m´ as cortas indican mejores resultados, ya que necesitan menos tiempo para completarse utilizaron transiciones ni efectos. El mejor tiempo obtenido fue de 1226 segundos usando el nodo maestro y dos nodos virtuales y especificando diecis´ eis archivos de salida, un resultado similar se obtuvo con la misma configuraci´ on pero con ocho archivos. Empleando ´ unicamente el nodo maestro se necesit´ o de 2614 segundos, este es el peor resultado de la presente prueba. El menor tiempo usando el nodo maestro y un nodo virtual fue de 1477 segundos con diecis´ eis archivos de salida. Se obtuvo resultados similares con esta configuraci´ on al especificar ocho archivos de salida, utilizando s´ olo 24 segundos adicionales. Conclusiones El uso de las tecnolog´ ıas de la computaci´ on en la nube para integrar v´ ıdeos para entornos educativos y de difusi´ on es factible sin la necesidad de incurrir en costos de licenciamiento ni de equipo especializado o dedicado. Se analiz´ o una infraestructura en la nube para Cinelerra, demostrando su viabilidad para entornos acad´ emicos y televisivos, se logr´ o demostrar que de esta forma se puede ampliar el n´ umero de usuarios desarrollando de forma concurrente diferentes proyectos y renderizar de manera eficiente; empleando recursos disponibles de forma 69 JOS ´ EISAAC ZABLAH ´ AVILA t´ ıpica y gestionados a trav´ es de un entorno virtual sacando provecho de las tecnolog´ ıas para estos fines. Con las diferentes pruebas llevadas a cabo en los dos casos de uso, se puede deducir que para obtener el mayor provecho de los recursos es necesario identificar el n´ umero id´ oneo de fragmentos en los cuales hay que dividir el proyecto de Cinelerra que se enviar´ a a procesar en los nodos de trabajo disponibles. En los resultados mostrados, el hecho de contar con ocho fragmentos del proyecto cuando se tiene un nodo maestro m´ as dos nodos de renderizaci´ on entrega los mejores tiempos en todas las pruebas, con lo que se afianza la necesidad de identificar la carga id´ onea para que la infraestructura sea viable. Es importante que al momento de planificar este tipo de soluciones se debe evitar que en los nodos virtuales se den lugar situaciones de sobre demanda de recursos que puedan ocasionar p´ erdida de rendimiento debido a la competencia que puede existir entre las m´ aquinas virtuales y el anfitri´ on. Es por ello que se indic´ o que es necesario utilizar capacidad computacional que est´ e disponible, de manera que si se utilizan estaciones de trabajo compartidas se debe organizar bien la cantidad de recursos con los que el hipervisor va a disponer. Los resultados indican que la infraestructura y configuraci´ on propuesta resultan ser eficientes con proyectos grandes, utilizando tiempos razonables para concluir proyectos. Para el caso de fragmentos cortos es m´ as viable utilizar la estaci´ on de trabajo de los editores, ya que de esta forma se evita el atraso que pueda presentarse al fragmentar y distribuir archivos demasiados peque˜ nos. 4.3. Medicina En la actualidad los recursos de computaci´ on de altas prestaciones son requeridos para las actividades de investigaci´ on m´ edica, debido al volumen de datos provenientes de equipos y sensores utilizados para an´ alisis de pacientes que ofrecen grandes cantidades de datos que requieren ser analizados e interpretados. La medicina de precisi´ on es una nueva ´ area del conocimiento de participaci´ on multidisciplinaria donde las ciencias de la computaci´ on ofrecen las herramientas puente entre los diferentes profesionales que combinan esfuerzos con personal sanitario. En esta secci´ on, se analiza una aplicaci´ on relacionada con neurociencias e im´ agenes biom´ edicas llamada FreeSurfer, esta se caracteriza por ser una herramienta de software que actualmente est´ a enfocada en medicina personalizada y de precisi´ on. El acceso a equipos radiol´ ogicos digitales junto con la capacidad de realizar an´ alisis de diversa ´ ındole hacen nece70 Cap´ ıtulo 4. Casos de uso sario contar con la capacidad de sistematizar el manejo de datos para investigaci´ on y acciones cl´ ınicas [1][100][91] 4.3.1. FreeSurfer Las enfermedades neurol´ ogicas son causa importante de muerte e incapacidad permanente en la poblaci´ on mundial [22, 58, 61]. Por ello, la neuroimagen ha avanzado r´ apidamente en las ´ ultimas dos d´ ecadas. Las t´ ecnicas avanzadas de neuroimagen no invasiva, como la imagen de resonancia magn´ etica (IRM), han permitido la visualizaci´ on y el an´ alisis de la funci´ on y la estructura cerebral, con un nivel de detalle sin precedentes, transformando la forma en que estudiamos el sistema nervioso en condiciones normales y patol´ ogicas [48]. Estos avances van de la mano con nuevos recursos computacionales y/o aplicaciones para poder realizar an´ alisis ´ utiles de las im´ agenes procesadas [51][103]. La nube debido a su flexibilidad de gesti´ on, hace que sea una soluci´ on mucho m´ as eficiente, escalable y adaptable para usarse en neurociencias. Los esquemas de implementaci´ on de la nube ofrecen la facilidad de gestionar los recursos mediante una plataforma centralizada, permitiendo escalar los recursos computacionales bajo demanda o bien dependiendo de los perfiles de los usuarios [44]. El desarrollo de la nube ha permitido compartir recursos, lo que ha facilitado el manejo de mayor cantidad de informaci´ on heterog´ enea, conglomerada en la actualidad bajo el t´ ermino BigData [96]. En esta secci´ on se eval´ ua la idoneidad de las infraestructuras en la nube aplicadas al an´ alisis de im´ agenes de resonancia magn´ etica [63]. Una de las aplicaciones utilizadas en medicina es FreeSurfer [25], con la cual se pueden realizar m´ ultiples an´ alisis, reconstrucci´ on y segmentaci´ on de la corteza cerebral, permitiendo el manejo de imagen estructural y funcional por medio de visualizaci´ on. Permite realizar un registro de im´ agenes, tractograf´ ıa y otros an´ alisis. Este software requiere amplios recursos de CPU para el procesamiento de resonancias magn´ eticas, lo que la convierte en una aplicaci´ on de c´ alculo intensivo, que usualmente se ejecuta sobre estaciones de trabajo dedicadas y haciendo uso de cl´ usteres para disminuir el tiempo de ejecuci´ on. Se ha evaluado el empleo de infraestructuras cloud para su ejecuci´ on. Para ello, se realiz´ o la comparaci´ on de las diferencias del rendimiento que existen entre un ordenador f´ ısico e instancias virtualizadas en la nube, con el fin de determinar si estas ´ ultimas representan una alternativa viable para la reducci´ on y procesamiento de datos para el estudio de enfermedades cerebrales a trav´ es de neuroimagen. FreeSurfer ha sido desarrollado en el Athinoula A. Martinos Center for Biomedical Ima71 JOS ´ EISAAC ZABLAH ´ AVILA ging [55], centr´ andose en tres prop´ ositos principales: I) la creaci´ on de modelos computarizados del cerebro a partir de im´ agenes de resonancia magn´ etica, II) medir diversas propiedades morfom´ etricas del cerebro, en especial el espesor cortical, la caracter´ ısticas de curvatura, vol´ umenes regionales corticales y subcorticales, y III) la normalizaci´ on espacial cortical entre sujetos sobre la base de la alineaci´ on de patrones de plegado de un individuo con las de una poblaci´ on promedio de patr´ on de plegamiento cortical para establecer correspondencia entre regiones anat´ omicas hom´ ologas [21]. Existen trabajos relacionados para evaluar el rendimiento de FreeSurfer enfocados principalmente en la evaluaci´ on del rendimiento en computaci´ on h´ ıbrida donde Delgado J. et al. [16] propone un nuevo pipeline con la intenci´ on de optimizar el uso de recursos CPU y GPU para el procesamiento en un modelo de computaci´ on h´ ıbrida. Este esquema combina la versi´ on GPU existente de FreeSurfer con un esquema paralelo de gesti´ on de tareas. Por otra parte Gronenschild, E. et al. [32], eval´ uan los efectos sobre el rendimiento de FreeSurfer derivados de la utilizaci´ on de diferentes tipos de estaciones de trabajo y diferentes sistemas operativos. Infraestructura El flujo de trabajo o workflow de FreeSurfer para la reconstrucci´ on cortical y la segmentaci´ on volum´ etrica de im´ agenes de resonancia magn´ etica es usualmente empleado como herramienta de investigaci´ on m´ edica del cerebro y comprende dos flujos: I) el estudio de las superficies, que calcula para cada punto del cortex, el grosor cortical, el volumen, el ´ area de superficie y la curvatura y, II) los estudios volum´ etricos, que cuantifican los vol´ umenes de las estructuras subcorticales [55]. El workflow se encuentra estructurado como flujos de procesos de computaci´ on cuya ejecuci´ on se encuentra controlada por medio del script recon-all [15]. T´ ıpicamente, este flujo de trabajo puede tardar decenas de horas de computaci´ on intensiva, dependiendo principalmente de la plataforma de hardware y software empleada, el tiempo requerido se traduce en un atraso en el diagn´ ostico de los pacientes y/o en una demora en la obtenci´ on de resultados por parte de los investigadores [26, 42]. En este estudio se ha empleado FreeSurfer v5.3. Las diferentes infraestructuras de procesamiento empleadas se detallan a continuaci´ on: •Plataforma cloud: Basada en una infraestructura configurada con Apache CloudStack 4.4 [84] empleando el hipervisor KVM [87], que ha sido desplegada en los nodos de computo (CN ´ ocompute node). Los CN emplean procesadores Intel Core [email protected] 72 Cap´ ıtulo 4. Casos de uso GHz con 8 GB de RAM y sistema operativo (SO) CentOS 6.8 64 bits [24]. El procesador empleado tiene cuatro n´ ucleos y ocho hilos, una cach´ e L1 de 4x32 Kbytes de capacidad para instrucciones y 4x32 Kbytes para datos, una cach´ e L2 de 4x256 KBytes, y una cache compartida L3 de 8 MB. Tambi´ en dispone de Intel Virtualization Technology (VT-x) y virtualizaci´ on de I/O (VT-d). Un NAS de 12 TB proporciona el almacenamiento compartido, mediante NFS v4, para la infraestructura cloud. La red de interconexi´ on de esta infraestructura est´ a basada en RTL8111/8168/8411 PCI Express Gigabit Ethernet Controller. •Infraestructura f´ ısica: Tiene procesadores Intel Core [email protected] GHz con 8 GB de RAM y sistema operativo (SO) CentOS 6.8 64 bits. El procesador empleado tiene cuatro n´ ucleos y ocho hilos, una cach´ e L1 de 4x32 Kbytes de capacidad para instrucciones y 4x32 Kbytes para datos, una cach´ e L2 de 4x256 Kbytes, y una cache compartida L3 de 8 MB. Tambi´ en dispone de Intel Virtualization Technology (VTx) y virtualizaci´ on de I/O (VT-d). Un NAS de 12 TB proporciona el almacenamiento compartido, mediante NFS v4, para la infraestructura cloud. La red de interconexi´ on de esta infraestructura est´ a basada en RTL8111/8168/8411 PCI Express Gigabit Ethernet Controller. •Anfitri´ on f´ ısico: Este despliega una m´ aquina virtual KVM, que dispone de 4 GB de RAM y un disco duro de 30 GB. La red de interconexi´ on proporcionada por el hipervisor emplea controladores Virtio. El sistema operativo hu´ esped es CentOS 6.8 64 bits. •M´ aquina VirtualBox: Esta MV desplegada sobre VirtualBox v5.1.3, cuenta con 4 GB de RAM. Emplea el chipset PIIX3, I/O APIC y reloj hardware empleando tiempo UTC. El sistema de almacenamiento virtualizado es de tipo AHCI, empleando la cache de anfitri´ on de entrada/salida. Como en el caso anterior, se ha empleado CentOS 6.8 64 bits como sistema operativo (SO) hu´ esped. Resultados En este trabajo hemos considerado tres escenarios de pruebas: el primero la evaluaci´ on de FreeSurfer en una plataforma cloud empleando KVM como hipervisor. Los otros dos escenarios se han dise˜ nado con la finalidad de comparar los resultados obtenidos con otras plataformas. De esta manera, el segundo de los escenarios est´ a orientado a evaluar a FreeSurfer ejecutado sobre la plataforma f´ ısica, mientras que el tercero, y ´ ultimo, est´ a orientado a ejecutar el FreeSurfer sobre VirtualBox. 73 JOS ´ EISAAC ZABLAH ´ AVILA En cada uno de los escenarios se lleva a cabo la misma metodolog´ ıa, que consiste en la instalaci´ on de FreeSurfer en un directorio del NAS que proporciona el almacenamiento de red compartido por medio de una red Gigabit Ethernet mediante NFS v4 y que se monta en la misma ruta en cada uno de los sistemas empleados. Adem´ as, tambi´ en se efect´ ua la misma configuraci´ on del entorno en los diferentes escenarios considerados. Una vez desplegados los escenarios anteriormente descritos, se ejecutan las pruebas de FreeSurfer utilizando los datos de resonancia magn´ etica del individuo Bert que se incluye en la distribuci´ on de esta aplicaci´ on. En cada uno de los escenarios descritos, se han realizado dos tipos de mediciones, la primera de ellas eval´ ua el tiempo para completar el an´ alisis de autorecon 1 para el individuo Bert en una serie de doce ejecuciones continuas, de las cuales se han considerado las diez ´ ultimas del an´ alisis con la finalidad de eliminar el posible efecto de warm-up de los sistemas, lo cual podr´ ıa afectar a las dos primeras mediciones. Las etapas procesadas por autorecon 1 se corresponden a: I)motion correction and conform,II)NU (Non-Uniform intensity normalization),III)talairach transform computation,IV)intensity normalization y, V)skull strip El segundo tipo de medidas est´ a destinado a extraer el perfil de utilizaci´ on de la CPU en el an´ alisis de este individuo, de tal forma que durante la ejecuci´ on de FreeSurfer se mide la utilizaci´ on de la CPU de forma peri´ odica en intervalos de 10 segundos. En la figura 4.13 se representa el tiempo empleado por FreeSurfer para ejecutar el workflow correspondiente al autorecon 1 en las plataformas anteriormente descritas. La infraestructura anfitriona (host) es la m´ as eficiente empleando un tiempo promedio de 428.2 segundos, para procesar el workflow de autorecon 1. Si se ejecuta lo anterior sobre la m´ aquina virtual KVM, el tiempo promedio empleado es de 441.6 segundos, siendo un 3.2% m´ as lento que el resultado obtenido sobre el anfitri´ on. El resultado m´ as desfavorable se obtiene cuando se ejecuta el workflow de autorecon 1 sobre la m´ aquina virtual de VirtualBox, obteni´ endose un resultado promedio de 446.6 segundos, siendo un 4.3% m´ as lento el procesamiento si se toma como referencia el resultado obtenido en el anfitri´ on. Uno de los desaf´ ıos m´ as importantes de las infraestructuras cloud es mejorar el rendimiento de las operaciones de entrada/salida, que constituyen uno de los cuellos de botella en este tipo de plataformas. Por el contrario, las infraestructuras cloud efect´ uan de forma muy eficiente la asignaci´ on compartida de la CPU a diversas m´ aquinas virtuales, lo que hace que este tipo de infraestructuras sean especialmente interesantes a la hora de ejecutar aplicaciones CPU-bound. Como se ha visto, el perfil de procesamiento de FreeSurfer se corresponde con 74 Cap´ ıtulo 4. Casos de uso Figura 4.13: Tiempo de ejecuci ´ on de autorecon 1 para el sujeto Bert para cada una de las series de medidas obtenidas sobre la plataforma f´ ısica (anfitri ´ on), sobre la m ´ aquina virtual KVM y sobre la m ´ aquina virtual de VirtualBox. Figura 4.14: Perfil de utilizaci´ on de la CPU durante la ejecuci´ on de autorecon 1 para el individuo Bert frente al tiempo. 75 JOS ´ EISAAC ZABLAH ´ AVILA Figura 4.15: Tiempo (en segundos) utilizado por las infraestructuras para completar el script muestreo, en una serie de diez pruebas consecutivas de ejecuci´ on. El uso de memoria RAM en la instancia cloud antes de la ejecuci´ on fue en promedio 676.30 MB, con una desviaci´ on est´ andar de 1.95 MB, con un uso m´ aximo de 680 MB y el m´ ınimo de 674 MB en toda la serie. Posterior a la ejecuci´ on, el uso promedio fue 1341.5 MB, con una desviaci´ on est´ andar de 20.87 MB, con un uso m´ aximo de 1381 MB y un m´ ınimo de 1327 MB. Entre antes y despu´ es de la ejecuci´ on la diferencia de uso oscila en 665.20 MB en promedio entre todas las mediciones realizadas. •MySQL en m´ aquina f´ ısica SSD: El muestreo en la m´ aquina f´ ısica requiri´ o en promedio 4859.08 segundos para completar y reducir los datos, pero present´ o una desviaci´ on est´ andar de 255.82 segundos entre todas las mediciones, los resultados se muestran en la tabla 4.3 y en la tabla 4.4. En esta plataforma se mantuvo una menor desviaci´ on entre las medidas del tiempo de ejecuci´ on de cada patr´ on, pero entre ellos no fue completamente homog´ eneo. El patr´ on(1) utiliz´ o una media de 4159.53 segundos para completarse, siendo el m´ as eficiente. El patr´ on(2) us´ o 4299.23 segundos, el patr´ on(3) emple´ o 4324.69 segundos, el patr´ on(4) requiri´ o 4369.01. El patr´ on(5) us´ o 4878.44 segundos el cual represent´ o el mayor tiempo de ejecuci´ on. Es importante mencionar que el patr´ on(5), tiene el mismo n´ umero de palabras que el patr´ on(1), pero presentaron una 82 Cap´ ıtulo 4. Casos de uso M´ aquina F´ ısica Patr´ on Palabras Tiempo Medio (s) Desviaci´ on Est´ andard (s) Tiempo Medio por Palabra(s) 1 41 4159.53 106.21 101.45 2 55 4299.23 126.17 78.17 3 68 4324.69 165.42 63.60 4 27 4369.01 70.34 161.81 5 41 4878.44 267.67 118.99 Tabla 4.3: Tiempo de ejecuci´ on por patr´ on en la m ´ aquina f´ ısica. A menor tiempo mayor eficiencia. diferencia significativa de ejecuci´ on de 718.91 segundos. El tiempo medio requerido por palabra por el patr´ on(1) fue de 101.45 segundos, el patr´ on(2) us´ o 78.17 segundos; el patr´ on(3) s´ olo requiri´ o una media de 63.60 segundos, siendo el m´ as eficiente. En cambio, el patr´ on(4) fue el que m´ as tiempo emple´ o con una media de 161.81 segundos y, finalmente, el patr´ on(5) requiri´ o 118.99 segundos. En cuanto a la dispersi´ on de las mediciones, el patr´ on(4) present´ o la menor desviaci´ on est´ andar entre sus medidas, con un valor de 70.34 segundos. En cambio, los m´ as dispersos fueron los del patr´ on(5), con una desviaci´ on de 267.67 segundos. El promedio general requerido por palabra fue de 94.96 segundos entre todos los patrones. El uso de memoria RAM en la m´ aquina f´ ısica antes de la ejecuci´ on fue en promedio 1193.4 MB, con una desviaci´ on est´ andar de 23.56 MB, con un uso m´ aximo de 1240 MB y el m´ ınimo de 1170 MB en toda la serie. Posterior a la ejecuci´ on el uso promedio fue 1910.3 MB, con una desviaci´ on est´ andar de 43.28 MB, con un uso m´ aximo de 2003 MB y m´ ınimo de 1858 MB. Entre antes y despu´ es de la ejecuci´ on la diferencia de uso oscila en 716.90 MB en promedio en todas las mediciones realizadas. •Comparaci´ on de resultados MySQL: La instancia en la nube requiri´ o 42.4% m´ as tiempo de ejecuci´ on que la m´ aquina f´ ısica para completar el muestreo. Ello equivale a 2060.27 segundos de diferencia promedio para finalizar el procedimiento almacenado. A grandes rasgos, ambas infraestructuras mantuvieron un comportamiento homog´ eneo entre si durante las diversas mediciones en el conjunto de pruebas efectuadas. En cuanto a los patrones, el comportamiento entre infraestructuras fue similar entre todas las series. En todos los casos, la instancia en la nube requiri´ o m´ as tiempo para 83 JOS ´ EISAAC ZABLAH ´ AVILA Instancia Cloud Patr´ on Palabras Tiempo Medio (s) Desviaci´ on Est´ andard (s) Tiempo Medio por Palabra (s) 1 41 6212.21 237.46 151.52 2 55 6023.78 91.18 109.52 3 68 6314.30 155.52 92.86 4 27 6290.50 183.24 232.98 5 41 6635.32 118.53 161.84 Tabla 4.4: Tiempo de ejecuci´ on por patr´ on de la instancia cloud. A menor tiempo mayor eficiencia. completar las tareas de ejecuci´ on frente a la instancia f´ ısica. La mayor diferencia fue en el patr´ on(1), que requiri´ o un 49% de tiempo adicional, en cambio el patr´ on(5) s´ olo necesit´ o un 36% m´ as. El patr´ on(2) necesit´ o 40%, el patr´ on(3) un 46% y el patr´ on(4) un 44% de tiempo adicional respectivamente. En general, la instancia cloud requiri´ o en promedio de un 43% m´ as tiempo para completar todos los patrones. En cuanto al uso de memoria, ´ esta se mantuvo sin variaciones importantes entre cada ciclo de ejecuci´ on. Es importante mencionar y hacer notar que la memoria de intercambio no fue utilizada en ninguna plataforma, lo que indica que el gestor de base de datos no escal´ o de forma que requiriera esos recursos. En cuanto al uso de memoria RAM, antes de la ejecuci´ on el ordenador f´ ısico usaba en promedio 1193 MB y la instancia 677 MB con una diferencia de 43.25% menos de uso inicial de memoria por parte del cloud. Esto se debe principalmente, a que el sistema operativo en la instancia carece de interfaz gr´ afica y se est´ a ejecutando en modo consola, condici´ on que se mantiene en todo momento. Posterior a la ejecuci´ on el uso del ordenador f´ ısico fue de 1931 MB y la instancia emple´ o 1340 MB, siendo un 30.60% menos. Por otro lado, el uso promedio de la memoria RAM previo a la ejecuci´ on por parte de la instancia cloud fue de 665.20 MB siendo menor la infraestructura f´ ısica que us´ o 716.90 MB; esto es un incremento de un 7.77% por parte de la ´ ultima. Lo anterior se representa en la figura 4.16. •IOZone en cloud:En la ejecuci´ on de IOzone en esta plataforma, en cuanto a su velocidad promedio en escritura report´ o 11352 Kbytes/s, en re-escritura present´ o 11241 Kbytes/s, lectura 11686 Kbytes/s, re-lectura 12964 Kbytes/s, lectura aleatoria 9282 Kbytes/s y, finalmente, en escritura aleatoria 11190 Kbytes/s. En general, las mediciones mantu84 Cap´ ıtulo 4. Casos de uso Figura 4.16: Utilizaci´ on de memoria RAM en las diferentes ejecuciones en cada infraestructura. vieron un comportamiento similar en todas las ejecuciones, excepto en la lectura que present´ o una desviaci´ on est´ andar de 1317.69 segundos. De igual manera hubo dispersi´ on en las medidas de re-lectura con una desviaci´ on est´ andar de 1622.45 segundos y en la lectura aleatoria con 669.11 segundos respectivamente. Esta dispersi´ on en las medidas se origina por la tecnolog´ ıa de plato rotatorio y cabezales que compone al arreglo de discos que provee el NAS, donde se realizan las pruebas del cloud. Adicionalmente al ser un sistema virtualizado es afectado por el controlador de disco que provee el hipervisor. •IOzone en m´ aquina f´ ısica SSD: En esta serie de mediciones se obtuvo los mejores resultados. La velocidad promedio en escritura report´ o 150630 Kbytes/s, en re-escritura present´ o 143570 Kbytes/s, lectura 202387 Kbytes/s, re-lectura 203521 Kbytes/s, lectura aleatoria 164737 Kbytes/s y finalmente en escritura aleatoria 54095 Kbytes/s. En esta serie de mediciones se obtuvo una dispersi´ on muy baja, siendo la de mayor proporci´ on el proceso de escritura que present´ o una desviaci´ on est´ andar de 1263.40 Kbytes/s. Las otras mediciones no presentaron dispersi´ on de importancia. •IOzone en m´ aquina f´ ısica sobre NFS: En la ejecuci´ on de IOzone en esta plataforma, en 85 JOS ´ EISAAC ZABLAH ´ AVILA cuanto a su velocidad promedio en escritura report´ o 10467 Kbytes/s, en re-escritura present´ o 10614 Kbytes/s, en lectura 11331 Kbytes/s, en re-lectura 11330 Kbytes/s, en lectura aleatoria 6648 Kbytes/s y finalmente en escritura aleatoria 10529 Kbytes/s. En general, las mediciones mantuvieron un comportamiento similar en todas las ejecuciones sin presentar una dispersi´ on de importancia. •Comparaci´ on de resultados IOzone: Los mejores resultados los present´ o la m´ aquina f´ ısica, la cual contaba con una unidad de almacenamiento secundario del tipo SSD. En cambio, la instancia f´ ısica con almacenamiento NFS present´ o el peor rendimiento; pero muy similar a la instancia cloud, siendo esta mejor en re-lectura en un 14% y lectura aleatoria en un 39%. El sistema de almacenamiento en red (NAS) fue accedido sobre una red Ethernet Gigabit con el fin de limitar el efecto de la red, pero la misma no fue causa de los bajos resultados; sino que la tecnolog´ ıa que utilizan los discos que lo conforma es la cl´ asica de platos rotatorios y cabezales de lectura. El sistema de archivo que aprovech´ o el almacenamiento SSD, present´ o su mayor eficiencia en las tareas de lectura y re-lectura siendo hasta diez y siete veces superior al NFS. Conclusiones El primer tipo de script desarrollado, denominado muestreo, se encarga de crear una tabla que contiene un registro ´ unico con los datos del docente y la frecuencia de las respuestas asociadas a ´ el. El segundo tipo de script, llamado patr´ on, calcula el n´ umero de aciertos de las palabras y ra´ ıces sem´ anticas encontradas en la muestra espec´ ıfica por docente. Se repiti´ o la ejecuci´ on de los scripts en diferentes ocasiones, teniendo el cuidado de borrar los resultados y reiniciar las plataformas al finalizar cada ciclo. Al ejecutar las pruebas en ambas plataformas, el ordenador f´ ısico mostr´ o medidas superiores respecto a la instancia cloud, ya que esta ´ ultima emplea un sistema de almacenamiento basado en disco de platos rotatorios siendo menos eficiente. La tecnolog´ ıa SSD provee una interesante alternativa para ser considerada como sistema de almacenamiento en una infraestructura cloud, siendo la ´ unica limitante de esto la relaci´ on de precio y capacidad. En cambio, al evaluar el tiempo de ejecuci´ on de los scripts dentro del gestor de base de datos, los resultados se ven sacrificados en un tercio en la instancia cloud frente a la alternativa f´ ısica. Con el fin de identificar que ocasiona la p´ erdida de eficiencia, se ha ejecutado IOzone bajo tres condiciones diferentes como ser sobre la plataforma cloud, sobre la m´ aquina f´ ısica empleando como almacenamiento el SSD, y sobre la m´ aquina f´ ısica empleando como alma86 Cap´ ıtulo 4. Casos de uso cenamiento un directorio exportado desde el sistema de almacenamiento primario del cloud exportado por medio de NFS. Los resultados han mostrado que el cuello de botella de la infraestructura cloud proviene del sistema de almacenamiento primario empleado en el cloud, el sistema NAS en RAID 1, que es el que provee los discos ra´ ız de las m´ aquinas virtuales. El cambio del sistema de almacenamiento a uno de estado s´ olido puede aportar mucho beneficio en el tiempo de ejecuci´ on de aplicaciones en una instancia cloud o f´ ısica, este deber´ a ser un punto de estudio a futuro para conocer las ventajas y poderlas cuantificar. 4.4.2. Simulaciones num´ ericas en la nube Este caso de uso se estudia la influencia del n´ umero de m´ aquinas virtuales empleadas por anfitri´ on y las operaciones de entrada y salida (E/S) que se producen, espec´ ıficamente en cuanto al desempe˜ no de dos pruebas de referencia, la primera es una aplicaci´ on cient´ ıfica basada en una simulaci´ on de dispositivos semiconductores y la segunda es el benchmark Linpack. Ambos se ejecutaron con y sin el soporte al hyperthreading en el anfitri´ on f´ ısico. Las m´ aquinas virtuales son administradas utilizando el hipervisor KVM incluido en la plataforma de gesti´ on de Apache CloudStack [81]. Infraestructura En la actualidad se ha tenido un importante progreso en la tecnolog´ ıa de virtualizaci´ on, que ha permitido el desarrollo de varios hipervisores de c´ odigo abierto. Espec´ ıficamente, KVM [87] es un hipervisor potente pero relativamente simple que ha encontrado su lugar al integrarse en el kernel de Linux desde la versi´ on 2.6.20, dando las capacidades de virtualizaci´ on nativa. Utiliza la virtualizaci´ on completa asistida por hardware y no requiere sistemas operativos invitados modificados. KVM puede ejecutarse en cualquier plataforma Linux, siempre que se implemente en un microprocesador compatible con la virtualizaci´ on asistida por hardware [41]. Para KVM, cada m´ aquina virtual (MV) se considera un proceso regular de Linux, el cual tiene tres modos de ejecuci´ on: usuario, n´ ucleo e invitado. El modelo de usuario se usa como predeterminado para las aplicaciones, el modo kernel se usa cuando una aplicaci´ on necesita alg´ un servicio del kernel (por ejemplo, escribir en un disco) y el modo invitado se usa por procesos que se ejecutan desde la m´ aquina virtual [33]. Para proporcionar una abstracci´ on b´ asica de la CPU subyacente a las m´ aquinas virtuales, se requiere el uso de una plataforma de administraci´ on de la nube, para ello se utiliz´ o Apache CloudStack [84]. Este gestor ha sido dise˜ nado para implementar y gestionar grandes redes de 87 JOS ´ EISAAC ZABLAH ´ AVILA m´ aquinas virtuales, como una plataforma de computaci´ on en la nube escalable y altamente disponible. En este caso de uso se ha tomado los recursos que son parte del proyecto Formiga Cloud [28], que propone la creaci´ on de una infraestructura en la nube basada en el modelo IaaS para aprovechar los recursos computacionales disponibles en los laboratorios inform´ aticos de la una universidad. Por ejemplo, la Universidad de Santiago de Compostela (USC) [92] tiene alrededor de 1800 ordenadores personales disponibles en sus diferentes aulas de inform´ atica que est´ an inactivos fuera del horario lectivo; este recurso puede ser utilizado conforme a los objetivos del proyecto mencionado. Por lo tanto, Formiga Cloud pretende utilizar estos recursos no s´ olo para actividades de ense˜ nanza sino tambi´ en para la inform´ atica cient´ ıfica. Para evaluar el rendimiento de la infraestructura, se ha seleccionado una aplicaci´ on de inform´ atica cient´ ıfica, espec´ ıficamente un simulador de dispositivos semiconductores 1D-SIM [27], el cual se ha desarrollado en la Universidad Santiago de Compostela y de la misma manera se ha hecho uso de una referencia sint´ etica como ser la biblioteca num´ erica de Linpack [13] [19]. Usando estas aplicaciones, se ha evaluado el impacto en el rendimiento de varios elementos clave en la computaci´ on en la nube como ser la cantidad de m´ aquinas virtuales por anfitri´ on, la influencia del hyperthreading y la E/S del disco duro. Ambas amplicaciones resuelven sistemas lineales de ecuaciones conformadas por matrices dispersas para 1D-SIM y densas para Linpack. 1D-SIM es un simulador de tipo deriva-difusi´ on (drift-diffusion, (D-D)) unidimensional para dispositivos semiconductores. En la figura 4.17 se muestra un diagrama de flujo del proceso de simulaci´ on. Las ecuaciones b´ asicas que se deben resolver en el modelo de derivadifusi´ on son la ecuaci´ on de Poisson y las ecuaciones de continuidad de electr´ on-hueco. [77]. El m´ etodo de elementos finitos se aplica para discretizar el dispositivo. Para un caso discretizado en N nodos, se debe resolver un conjunto de ecuaciones no lineales acopladas de dimensi´ on 3N. Las inc´ ognitas del problema son el potencial electrost´ atico (ψ) y los potenciales cuasi-Fermi para los electrones (φn) y los huecos (φp). El m´ etodo de Gummel se aplica [75] para desacoplar estas ecuaciones, que luego se linealizan utilizando el m´ etodo de Newton [7]. El sistema lineal resultante de ecuaciones se resuelve utilizando el m´ etodo iterativo BiCGSTAB preacondicionado con una factorizaci´ on LU incompleta, que depende tanto de un cierto relleno como de un umbral num´ erico. En este caso, se ha utilizado un transistor bipolar de heterouni´ on como prueba de referencia, incluidos los efectos de emisi´ on termoi´ onica y efecto t´ unel. 88 Cap´ ıtulo 4. Casos de uso La prueba de referencia Intel Linpack resuelve un sistema denso de ecuaciones lineales, mide la cantidad de tiempo que toma para factorizar y resolver el sistema, luego convierte ese tiempo en una tasa de rendimiento y finalmente, eval´ ua la precisi´ on de los resultados. Hay que destacar que esta es una de las pruebas que se utiliza para crear la lista TOP500 [53] que da una clasificaci´ on de las s´ upercomputadoras m´ as potentes del mundo. La m´ aquina utilizada como anfitri´ on tiene un procesador Intel Core [email protected] GHz con cuatro n´ ucleos y 8 GB de RAM. La red de interconexi´ on es una Ethernet GigaBit. Los sistemas operativos del anfitri´ on y de las m´ aquinas virtuales (MV) son CentOS 64 bit versi´ on 6.1 y Debian 6.0.4 64 bit, respectivamente. Para realizar las pruebas, se desplegaron varias m´ aquinas virtuales en el mismo anfitri´ on utilizando el hipervisor KVM (qemu-kvm-0.12.1.2). La API de virtualizaci´ on [45] es libvirtd (versi´ on 0.9.4). Cada una de las m´ aquinas virtuales tiene un n´ ucleo y 1 GB de RAM disponibles. La CPU virtual es QEMU Virtual CPU (versi´ on cpu64-rhel6). El sistema de archivos de red utilizado es NFS v3. Resultados Inicialmente, hemos modificado el simulador 1D-SIM para eliminar las operaciones de escritura en el disco duro. En el anfitri´ on f´ ısico con el hyperthreading deshabilitado, ejecutamos el c´ odigo y se necesitaron 64.7 segundos para obtener la soluci´ on. En las mismas circunstancias, una m´ aquina virtual implementada con el agente de Apache CloudStack requiere s´ olo un 2.5% m´ as de tiempo para alcanzar la misma soluci´ on. Para evaluar el impacto de la cantidad de m´ aquinas virtuales implementadas por el anfitri´ on en el rendimiento del simulador unidimensional, consideramos nm´ aquinas virtuales con n = 2, 4, 6, 8. Las primeras MV n-1 ejecutan el simulador una cierta cantidad de veces y la n-´ esima ejecuta el c´ odigo y estima los tiempos de simulaci´ on. La figura 4.18 muestra los tiempos de simulaci´ on frente a la cantidad de m´ aquinas virtuales desplegadas por anfitri´ on cuando no se generan operaciones de E/S en el disco local. La influencia del hyperthreading tambi´ en se muestra en la figura. Hay un aumento en el tiempo de simulaci´ on cuando se incrementa el n´ umero de MV por anfitri´ on. Cuando se habilita el hyperthreading, este incremento es inferior al 6%, al ejecutarse cuatro o menos MV y alcanza el 13% y el 23%, respectivamente, para 6 y 8 VM. Sin embargo, si el hyperthreading est´ a desactivado, la p´ erdida en la eficiencia es m´ as notable. En este caso, cuando se implementan dos o menos m´ aquinas virtuales, el aumento en el tiempo de simulaci´ on es inferior al 5%, pero alcanza el 10% cuando se utilizan cuatro m´ aquinas virtuales. Para un mayor n´ umero de 89 JOS ´ EISAAC ZABLAH ´ AVILA Figura 4.17: Diagrama de flujo de la simulaci´ on deriva-difusi´ on (drift-diffusion) del dispositivo 1D. MV por anfitri´ on, hay un deterioro importante en el tiempo requerido, observando en seis y ocho m´ aquinas virtuales, los tiempos de simulaci´ on incrementan entre 65% y 120% respectivamente, al compararse con los obtenidos con una sola MV. Se estudi´ o la influencia de las operaciones de E/S en el rendimiento de la simulaci´ on 1DSIM. Para ello, durante cada iteraci´ on del proceso de simulaci´ on, los valores de las diferentes variables que se calculan durante la simulaci´ on (concentraciones de electr´ on-hueco y potencial electrost´ atico) se escriben en un archivo para cada nodo de la malla. Esta es una prueba m´ as realista y se realiza de la misma manera que la anterior, pero incluye una MV adicional en otro anfitri´ on que exporta un sistema de archivos NFS que se comparte entre las otras MV para almacenar los resultados de la simulaci´ on. Esta MV adicional tiene 4 n´ ucleos y se implementa en un procesador Intel Core i7-2600 @ 3.4 GHz. 90 Cap´ ıtulo 4. Casos de uso Figura 4.18: Tiempo de simulaci´ on deriva-difusi´ on del dispositivo 1D versus el n´ umero de m´ aquinas virtuales por anfitri ´ on cuando no se generan operaciones de E/S. Se comparan los resultados con hyperthreading activado o desactivado. La figura 4.19 muestra, para este caso que los tiempos de simulaci´ on frente al n´ umero de m´ aquinas virtuales implementadas por anfitri´ on. El impacto del hyperthreading tambi´ en se muestra en la figura. Cuando se incrementa el n´ umero de procesos que usan el sistema de almacenamiento NFS, se generan m´ as interrupciones en la aplicaci´ on debido a la cantidad de procesos que compiten por obtener acceso al sistema de archivos. Por lo tanto, hay un aumento considerable en el tiempo de simulaci´ on cuando se incrementa el n´ umero de m´ aquinas virtuales. Cuando el hyperthreading est´ a activado, disminuye considerablemente el tiempo requerido para la simulaci´ on, siendo m´ as evidente cuando se implementan dos o m´ as m´ aquinas virtuales. Cuando el hyperthreading est´ a deshabilitado y se usan 8 VM en el mismo anfitri´ on, observamos el mayor aumento en el tiempo de simulaci´ on de todas las pruebas, duplicando el tiempo en comparaci´ on con el valor obtenido cuando se usa el soporte hyperthreading en un caso similar con el mismo n´ umero de MV. Hemos realizado un estudio similar utilizando el benchmark Intel Linpack. En esta prueba, se utiliz´ o un tama˜ no de problema de 5000, con valores de alineaci´ on de 4 Kbytes. Linpack proporciona el rendimiento promedio en GFlops por todas las ejecuciones Linpack (cinco en nuestro caso) para una sola prueba. Estos resultados se muestran en la figura 4.20, donde se 91 JOS ´ EISAAC ZABLAH ´ AVILA Figura 4.23: Esquema de operaci ´ on de un cl´ uster para MPI. las aplicaciones desde el maestro el cual los ejecutar´ a en los nodos. Cada computadora que compone el cl´ uster ejecuta su propia instancia de un sistema operativo, as´ ı mismo pueden existir recursos compartidos accesibles como ser servidores de almacenamiento NFS, entre otros. El cl´ uster virtual que los estudiantes deben implementar en Apache CloudStack est´ a compuesto por una m´ aquina virtual configurada como maestro y dos m´ aquinas virtuales configuradas como nodos. El maestro desplegado es una MV que emplea un disco duro de 10 GB, un n´ ucleo de CPU, 1 GB de memoria RAM y ejecuta como base el sistema operativo CentOS 6.3. Tambi´ en sirve el directorio inicial a los nodos que componen el cl´ uster virtual empleando el sistema de archivos de red (NFS) como un protocolo de sistema de archivos distribuido. Los nodos implementados son m´ aquinas virtuales con un disco duro de 10 GB, cada uno tiene un CPU central con 1 GB de RAM y ejecutan el sistema operativo CentOS 6.3. Los nodos montan los directorios compartidos que provee el maestro. Las m´ aquinas virtuales utilizadas comparten una interconexi´ on de red Ethernet Gigabit. 98 Cap´ ıtulo 4. Casos de uso El cl´ uster virtual utiliza OpenMPI 1.6 [88] como implementaci´ on de MPI. OpenMPI es de c´ odigo abierto y soporta el protocolo MPI-2 [60], el cual fue desarrollado por un consorcio conformado por investigadores, acad´ emicos y socios industriales. Las caracter´ ısticas m´ as notables de MPI-2, son la seguridad, la concurrencia de subprocesos, generaci´ on de procesos din´ amicos, tolerancia a errores de red y de proceso, heterogeneidad en cuanto a redes, instrumentaci´ on en tiempo de ejecuci´ on, entre otras caracter´ ısticas. •Escenario mejorado: En las redes Ethernet que utilizan TCP existe una alta latencia de las comunicaciones MPI, es por ello que el rendimiento obtenido es limitado. Sin embargo, esta latencia se puede reducir utilizando Open-MX [36]. Esta es una implementaci´ on de alto rendimiento de la pila de transmisi´ on de mensajes Myrinet Express [14] sobre redes Ethernet gen´ ericas. Tiene las capacidades del firmware MX que se ejecuta en Myri-10G NIC como un controlador en el kernel de Linux. Para aplicaciones heredadas, una biblioteca de espacio de usuario expone la interfaz MX a las aplicaciones. Open-MX admite Linux en cualquier arquitectura y funciona al menos en kernels Linux igual o superior a la versi´ on 2.6.15, al igual ocurre con los dispositivos Ethernet que est´ an soportados en ´ el. Para funcionar correctamente todos los equipos que deseen aprovechar esta librer´ ıa deben encontrarse en el mismo segmento de red e interconectados mediante un conmutador o switch. Open-MX es compatible con el tr´ afico IP y puede coexistir perfectamente en la misma red. Para configurar Open-MX para ser utilizado por OpenMPI, es necesario tener en cuenta que este ´ ultimo debe compilarse e instalarse con la opci´ on de habilitar la compatibilidad con Open-MX. El prop´ osito de este escenario es hacer que los estudiantes presten atenci´ on a la importancia del an´ alisis del rendimiento de los ordenadores que ejecuten aplicaciones que requieran alto desempe˜ no. El cl´ uster virtual empleado en este caso tiene la misma configuraci´ on que la descrita en el escenario b´ asico, pero el cambio es contar con Open-MX para mantener las comunicaciones MPI, evitando la sobrecarga de TCP para comunicar procesos. Pruebas de referencia Para probar los escenarios descritos anteriormente, se ejecutaron tres tipos de aplicaciones, la primera es el Intel MPI Benchmarks [37], el segundo es el ejemplo HEAT MPI [10] y la tercera es la aplicaci´ on el GADGET2 [83]. 99 JOS ´ EISAAC ZABLAH ´ AVILA La primera aplicaci´ on para prueba es el Intel MPI Benchmarks 3.2.3 (IMB) que proporciona un conjunto conciso de kernels de referencia MPI elementales, tiene varios par´ ametros como ser la longitud de los mensajes o la selecci´ on de comunicadores para ejecutar un punto de referencia espec´ ıfico. IMB tambi´ en proporciona una configuraci´ on est´ andar, pero el usuario puede configurar a medida. Si se utiliza el modo est´ andar, todos los par´ ametros mencionados anteriormente son fijos y no deben modificarse. El modo seleccionado para probar la infraestructura virtual es el est´ andar. La versi´ on utilizada de IMB, contiene diferentes clases de pruebas de referencia como ser la transferencia simple o single transfer, la transferencia paralela o parallel transfer y la transferencia colectiva o collective transfer. La simple son dos pruebas, una de ellas la PingPong y la otra es PingPing. La paralela se denominan Exchange ySendrecv. La pruebas colectivas son Bcast, Allgather, Allgatherv, Alltoall, Alltoallv, Reduce, Reduce scatter, Allreduce y la Barrier. Las pruebas de transferencia simple, se describen a continuaci´ on: •PingPong:Se usa para medir el inicio y la producci´ on de un s´ olo mensaje enviado entre dos procesos. •PingPing:Mide el inicio y el rendimiento de los mensajes individuales con la diferencia de que los mensajes que se aproximan obstruyen a los mensajes enviados. Las pruebas de transferencia paralela, se describen a continuaci´ on: •MPI Exchange:Es un patr´ on de comunicaci´ on que suele ocurrir en los algoritmos de divisi´ on de cuadr´ ıculas (intercambios de l´ ımites). El grupo de procesos es similar a una cadena peri´ odica y cada proceso intercambia datos con el vecino izquierdo y derecho de la cadena. •MPI Sendrecv:Cada proceso se env´ ıa al proceso de la derecha y se recibe desde su vecino izquierdo en una especie de cadena. El intercambio es un patr´ on de comunicaci´ on que se usa a menudo en los algoritmos de divisi´ on de cuadr´ ıculas en el que el grupo de procesos se ve como una cadena peri´ odica y cada proceso intercambia datos con los vecinos izquierdo y derecho de la cadena. Las pruebas colectivas y sus funciones, se describen a continuaci´ on: 100 Cap´ ıtulo 4. Casos de uso •MPI reduce:Su objetivo es disminuir un vector de elementos flotantes de longitud Lempleando la operaci´ on MPI SUM. •Reduce scatter:Decrementa un vector de elementos con longitud flotantes Lque emplea la operaci´ on MPI SUM. En la etapa de dispersi´ on, los elementos Lse dividen lo m´ as uniformemente posible. •MPI Allreduce:Disminuye un vector de elementos con longitud flotantes Lempleando la operaci´ on MPI SUM. •MPI Allgather:Es una funci´ on en la que cada proceso env´ ıa rbytes y recibe una cantidad de bytes que es igual a rmultiplicada por la cantidad de procesos. •MPI Allgatherv:Busca mostrar si MPI produce sobrecarga al crear una situaci´ on m´ as compleja en comparaci´ on con MPI Allgather. •MPI Alltoall:Hace que cada proceso ingrese un n´ umero de bytes igual a rmultiplicado por el n´ umero de procesos (r, en cada uno de ellos) y recibe un n´ umero de bytes igual armultiplicado por el n´ umero de procesos (rde cada proceso). •MPI Alltoallv:Esta funci´ on incrementa a´ un m´ as la carga de bytes que con la funci´ on MPI Alltoall. •MPI Bcast:Se busca que el proceso ra´ ız transmita rbytes a todos. En este punto de referencia, el proceso ra´ ız de la operaci´ on se cambia c´ ıclicamente. La segunda aplicaci´ on para prueba de referencia del cl´ uster virtual se ha hecho empleando HEAT MPI de John Burkardt [10], que es una implementaci´ on en lenguaje C de la ecuaci´ on de calor dependiente de tiempo 1D que emplea una forma de descomposici´ on de dominio. La tercera aplicaci´ on para prueba se ha hecho empleando el software GADGET2 [83]. Este programa es un c´ odigo de libre disposici´ on para simulaciones cosmol´ ogicas de N-cuerpos/SPH en computadoras paralelas con memoria distribuida. Utiliza un modelo de comunicaci´ on expl´ ıcito implementado con la interfaz de comunicaci´ on MPI estandarizada. GADGET2 calcula las fuerzas gravitatorias con un algoritmo de ´ arbol jer´ arquico y representa los fluidos por medio de la hidrodin´ amica de part´ ıculas suavizadas (SPH). GADGET2 puede usarse para estudios de sistemas aislados, o en simulaciones que incluyen la expansi´ on cosmol´ ogica del espacio, con o sin condiciones de contorno peri´ odicas en ambos casos. En este tipo de 101 JOS ´ EISAAC ZABLAH ´ AVILA simulaciones, GADGET2 sigue la evoluci´ on de un sistema de N-cuerpos sin colisiones autogravitantes y permite incluir opcionalmente din´ amicas de gas. Resultados Se inicia mostrando los resultados obtenidos para el protocolo TCP y Open-MX medidos con el Intel MPI Benchmarks. Los resultados de latencia obtenidos para los puntos de referencia de transferencia simple PingPong yPingPing se pueden observar en la figura 4.24. N´ otese que en todas las figuras presentadas, el eje X est´ a en escala logar´ ıtmica. Para el punto de referencia de la prueba PingPong, la latencia se reduce en alrededor de un 30% cuando se utiliza Open-MX para la comunicaci´ on en comparaci´ on con TCP, como se muestra en las marcas cuadradas de la figura. El ´ ındice de referencia PingPing tambi´ en reduce su latencia, incluso en una cantidad mayor (alrededor de un 36%) que PingPong, cuando se utiliza Open-MX. Los resultados obtenidos tanto para Exchange como para los puntos de referencia de transferencia paralelos de Sendrecv se muestran en la 4.25. Para la prueba de rendimiento de Exchange, la latencia se reduce en aproximadamente un 45% cuando se utiliza Open-MX en comparaci´ on con TCP, como se muestra en las marcas cuadradas de la figura. Respecto a Sendrecv tambi´ en reduce su latencia en un 35% cuando Open-MX se utiliza para las comunicaciones. Los colectivos Allgather yAllgatherv se muestran en la figura 4.26. Para el punto de referencia Allgather, la latencia se reduce alrededor del 33% cuando se usa Open-MX en comparaci´ on con TCP, como se muestra en las marcas cuadradas de la figura. El ´ ındice de referencia Allgatherv tambi´ en obtiene su latencia reducida en torno al 31%. En las pruebas del conjunto Alltoall yAlltoallv se indican en la figura 4.27. Para Alltoall, la latencia se redujo en alrededor del 35% cuando se utiliza Open-MX en comparaci´ on con TCP, como se muestra en las marcas cuadradas de la figura. El ´ ındice de referencia de Alltoallv tambi´ en reduce su latencia en aproximadamente un 35% de forma similar a la descrita anteriormente. Los resultados obtenidos para los puntos de referencia colectivos Reduce yReduce scatter se representan en la figura 4.28. Para la referencia de Reduce, la latencia disminuye alrededor del 35% como se muestra en las marcas cuadradas de la figura. Para Reduce scatter tambi´ en fue menor, bajando su latencia en un 32%, en ambos casos cuando Open-MX se utiliza para comunicaciones en sustituci´ on de TCP. 102 Cap´ ıtulo 4. Casos de uso Figura 4.24: Latencia frente a bytes en la prueba de transferencia simple de red (PinPong) y (PingPing). Figura 4.25: Latencia frente a bytes en la prueba de transferencia paralela de red (Exchange) y (Sendrecv). 103 JOS ´ EISAAC ZABLAH ´ AVILA Figura 4.26: Latencia frente a bytes en la prueba detransferencia colectiva (Allgather) y (Allgatherv). Para las pruebas del ejemplo HEAT MPI se mide el tiempo computacional transcurrido. Se us´ o el protocolo TCP para comunicar procesos MPI, empleando dos nodos virtuales desplegados en Apache CloudStack. El tiempo transcurrido fue de 22.708 milisegundos. Cuando se usa Open-MX, el tiempo transcurrido obtenido fue de 15.878 milisegundos (un 30% mejor que TCP). Finalmente, de forma contraria a lo obtenido en las pruebas previas, GADGET2 no obtiene un mejor´ ıa de operaci´ on cuando se utiliza Open-MX para comunicar procesos MPI. Esto muestra que eficiencia obtenidas dependen en gran medida del problema. Conclusiones Los procesos de ense˜ nanza-aprendizaje est´ an siendo apoyados por el desarrollo de nuevas tecnolog´ ıas. En el pasado reciente, recursos como el correo electr´ onico, el chat, la audioconferencia, la videoconferencia y la conferencia v´ ıa web, se incorporaron como nuevas herramientas en el proceso lectivo. Actualmente, se est´ a dando un paso m´ as con el desarrollo y la popularizaci´ on de las tecnolog´ ıas en la nube, ya que est´ an despertando un gran inter´ es en los entornos educativos. Actualmente hay un desarrollo activo de plataformas en la nube con el lanzamiento de varias soluciones de c´ odigo abierto para construir nubes privadas, p´ ublicas e 104 Cap´ ıtulo 4. Casos de uso Figura 4.27: Latencia frente a bytes en la prueba de transferencia colectiva (AlltoAll) y (AlltoAllv). Figura 4.28: Latencia frente a bytes en la prueba de transferencia colectiva (Reduce) y (Reduce Scatter). 105 JOS ´ EISAAC ZABLAH ´ AVILA h´ ıbridas, como ser los gestores OpenNebula, Eucalyptus, OpenStack y Apache CloudStack. Cada uno de ellos tiene caracter´ ısticas ´ unicas. En el modelo de servicio en la nube m´ as b´ asico como ser la infraestructura como servicio (IaaS), se puede proporcionar recursos computacionales como m´ aquinas virtuales. En inform´ atica, este modelo ofrece a docentes y estudiantes la posibilidad de gestionar infraestructuras virtuales en las que se pueden realizar pr´ acticas de administraci´ on de sistemas y lenguajes de programaci´ on sin comprometer la configuraci´ on de los nodos f´ ısicos. Como hemos visto y entre otras ventajas, la ense˜ nanza de MPI en la nube siguiendo la teor´ ıa del constructivismo se puede realizar con el prop´ osito de preparar a los estudiantes para la resoluci´ on de problemas en entornos complejos. Por lo tanto, se implementaron dos escenarios diferentes ambos usando equipo e interconexi´ on a red con hardware b´ asico, bajo Apache CloudStack usando KVM como hipervisor. El primero constituye un cl´ uster virtual para ejecutar aplicaciones MPI y el segundo es un cl´ uster virtual mejorado que utiliza OpenMX para obtener una menor latencia de las comunicaciones de MPI para que los estudiantes tomen conciencia de la importancia de realizar el an´ alisis de rendimiento de la computadora. Ambas infraestructuras MPI virtuales se probaron empleando los puntos de referencia Intel MPI, el ejemplo HEAT MPI y el software GADGET2. Los resultados obtenidos muestran que la ejecuci´ on de aplicaciones MPI en la nube es adecuada y la latencia de las comunicaciones MPI se redujo en un 30% con Open-MX en comparaci´ on con TCP. El tiempo transcurrido obtenido para el ejemplo de HEAT MPI tambi´ en es alrededor de un 30% mejor que usando TCP. Sin embargo, dependiendo de la implementaci´ on de las aplicaciones que utilizan MPI, hay casos en los que no se observan mejoras en la latencia, como sucedi´ o con GADGET2. Estos casos de prueba demuestran que se pueden desarrollar experimentos en la nube por parte de profesores o estudiantes (estos actuando hasta como administraci´ on de sistemas), con diversidad de lenguajes de programaci´ on y desarrollando pr´ acticas para la medici´ on del rendimiento. 106 Conclusiones En este documento se ha evaluado si una infraestructura virtualizada y en la nube puede ser de utilidad para reemplazar soluciones dedicadas de procesamiento, asi mismo se pretendi´ o determinar que si esta a su vez puede emplearse en necesidades de c´ alculo intensivo que actualmente no pueden ser atendidas por falta de capacidad computacional. Los resultados de los diferentes casos de uso han sido favorables, haciendo viable emplear la nube y la virtualizaci´ on para estas y otras necesidades. La utilidad de la tecnolog´ ıa de virtualizaci´ on parte fundamental del paradigma de la computaci´ on en la nube, ofrece al campo de la astronom´ ıa y astrof´ ısica; espec´ ıficamente en las aplicaciones de CASA y GADGET2 una opci´ on para el procesamiento de datos observacionales y para el modelamiento te´ orico de la ocurrencia y evoluci´ on de fen´ omenos en cuerpos celestes. Los tiempos obtenidos son similares a los que se reportan en un ordenador f´ ısico y la diferencia existente no es significativa, ya que en la mejor de las condiciones de ejecuci´ on convierten en una alternativa de soluci´ on a los entornos de procesamiento virtualizados sobre infraestructuras flexibles frente a los ordenadores f´ ısicos dedicados. En los casos de uso relacionados con multimedia, la nube es una opci´ on, sobre todo para las actividades de renderizaci´ on y transcodaje. La ventaja de utilizar la capacidad el´ astica y bajo demanda del paradigma permite realizar actividades que antes causaban atraso a los profesionales de esta ´ area, port´ andolas a la nube ya que ahora pueden realizarse de forma desatendida. Al compararse las capacidades de un anfitri´ on f´ ısico con los virtuales se aprecia que en las mejores condiciones de ejecuci´ on la diferencia entre ambas infraestructuras no es significativa. El mayor valor que aporta virtualizaci´ on es la de reutilizar los recursos computacionales f´ ısicos y la posibilidad de liberar estaciones de trabajo con mayor demanda, delegando carga de trabajo a una soluci´ on virtual. La infraestructura virtualizada tambi´ en es de utilidad si se enfoca a un entorno de forma- JOS ´ EISAAC ZABLAH ´ AVILA ISSN 00104655. http://linkinghub.elsevier.com/retrieve/pii/ 0010465588900276. [9] Bhardwaj, S., L. Jain y S. Jain: Cloud computing: A study of infrastructure as a service (IAAS). International Journal of engineering and information Technology, 2(1):60–63, 2010. [10] Burkardt, John: MPI Examples, 2011. https://people.sc.fsu.edu/ ˜jburkardt/, visitado el 07FEB2018. [11] Byrd, G.G. y M.J. Valtonen: Internal Tail Structure and Orbit Dynamics of the Radio Galaxy 3C129. En Bulletin of the American Astronomical Society, volumen 12, p´ agina 503, 1980. [12] Cellary, W. y S. Strykowski: e-government based on cloud computing and serviceoriented architecture. En Proceedings of the 3rd International Conference on Theory and Practice of Electronic Governance - ICEGOV ’09, p´ agina 5, New York, New York, USA, 2009. ACM Press, ISBN 9781605586632. http://portal.acm. org/citation.cfm?doid=1693042.1693045. [13] Corp., INTEL: Intel Math Kernel Library Benchmarks, 2017. https://software. intel.com/en-us/articles/intel-mkl-benchmarks-suite, visitado el 21JUN2017. [14] CSPI: CSPI Technology Solutions, 2018. https://www.cspi.com/, visitado el 07FEB2018. [15] Dale, A., B. Fischl y M. Sereno: Cortical Surface-Based Analysis I: Segmentation and Surface Reconstruction. Neuroimage, 9(2):179–194, 1999. [16] Delgado, J., J.C. Moure, Y. Vives-Gilabert, M. Delfino, A. Espinosa y B. G´ omezAns´ on: Improving the Execution Performance of FreeSurfer. Neuroinformatics, 12(3):413–421, jul 2014, ISSN 1539-2791. http://link.springer.com/10. 1007/s12021-013-9214-1. [17] Dikaiakos, M.D., D. Katsaros, P. Mehra, G. Pallis y A. Vakali: Cloud computing: Distributed internet computing for IT and scientific research. IEEE Internet computing, 13(5), 2009. 114 Bibliograf´ ıa [18] Dongarra, Jack J.: The LINPACK Benchmark: An explanation. p´ aginas 456–474. 1988. https://dl.acm.org/citation.cfm?id=73977. [19] Dongarra, J.J., J.R. Bunch, C.B. Moler y G.W. Stewart: LINPACK Users’ Guide. Other Titles in Applied Mathematics. Society for Industrial and Applied Mathematics, 1979, ISBN 9780898711721. https://books.google.hn/books?id= AmSm1n3Vw0cC. [20] Ercan, T.: Effective use of cloud computing in educational institutions. Procedia - Social and Behavioral Sciences, 2(2):938–942, 2010, ISSN 18770428. http: //linkinghub.elsevier.com/retrieve/pii/S1877042810001709. [21] Fischl, B.: FreeSurfer. NeuroImage, 62(2):774–781, aug 2012, ISSN 10538119. http://linkinghub.elsevier.com/retrieve/pii/ S1053811912000389. [22] Forouzanfar, M.H., L. Alexander, H.R. Anderson, V.F. Bachman, S. Biryukov, M. Brauer y et al. Burnett: Global, regional, and national comparative risk assessment of 79 behavioural, environmental and occupational, and metabolic risks or clusters of risks in 188 countries, 1990–2013: a systematic analysis for the Global Burden of Disease Study 2013. The Lancet, 386(10010):2287–2323, dec 2015, ISSN 01406736. http://linkinghub.elsevier.com/retrieve/pii/ S0140673615001282. [23] Forum, MPEG4 Industry: MPEG-4 – The Media Standard. Informe t´ ecnico, m4if, 2002. http://www.oipf.tv/docs/mpegif/m4-out-20027.pdf. [24] Foundation, The Linux: The Xen Project, 2017. https://xenproject.org/ developers/teams/hypervisor.html, visitado el 21JUN2017. [25] FreeSurfer: FreeSurfer Software Suite, 2015. http://freesurfer.net, visitado el 15SEP2015. [26] FreeSurfer: Recon-all Step-wise Directives, 2016. https://surfer.nmr.mgh. harvard.edu/fswiki/recon-all{#}StepwiseDirectives-{%}0A1, visitado el 15SEP2016. 115 JOS ´ EISAAC ZABLAH ´ AVILA [27] Garcıa-Loureiro, A.J., T.F. Pena, J.M. Lopez-Gonzalez y Ll. Prat: Parallel implementation of a simulator for heterojunction bipolar transistors. VIII Symp. on Parallelism, p´ aginas 41–50, 1997. [28] Gomez-Folgar, F., J. Cacheiro, C. S´ anchez-Fern´ andez, A. Garcia-Loureiro y R. Valin: An e-Science infrastructure for nanoeletronic simulations based on grid and cloud technologies. En Proceedings of the 8th Spanish Conference on Electron Devices, CDE’2011, p´ aginas 1–4. IEEE, feb 2011, ISBN 978-1-4244-7863-7. http: //ieeexplore.ieee.org/document/5744153/. [29] Gomez-Folgar, F., R. Valin, A. Garcia-Loureiro, T. F. Pena y I. Zablah: Cloud computing for teaching and learning MPI with improved network communications. En Mikroyannidis, Alexander, Rocael Hern´ andez Rizzardini y Hans Christian Schmitz (editores): 1st International Workshop on Cloud Education Environments (WCLOUD 2012), p´ aginas 22–27, Antigua, Guatemala, 2012. CEUR Workshop Proceedings. http://ceur-ws.org/Vol-945/paper5.pdf. [30] Gomez Folgar, Fernando, Guillermo Indalecio Fernandez, Jose Isaac Zablah Avila, Natalia Seoane Iglesias, Antonio Jesus Garcia Loureiro y Tomas Fernandez Pena: A study of the influence of VM allocation policies on MPI Bcast and MPI Exchange latency in cloud. IEEE Latin America Transactions, 15(8):1490–1496, 2017, ISSN 1548-0992. http://ieeexplore.ieee.org/document/7994797/. [31] Greengard, S.: Cloud computing and developing nations. Communications of the ACM, 53(5):18, may 2010, ISSN 00010782. http://portal.acm.org/ citation.cfm?doid=1735223.1735232. [32] Gronenschild, E.H.B.M., P. Habets, H.I.L. Jacobs, R. Mengelers, N. Rozendaal, J. van Os y M. Marcelis: The Effects of FreeSurfer Version, Workstation Type, and Macintosh Operating System Version on Anatomical Volume and Cortical Thickness Measurements. PLoS ONE, 7(6):e38234, jun 2012, ISSN 1932-6203. http://dx.plos. org/10.1371/journal.pone.0038234. [33] Habib, Irfan: Virtualization with KVM. Linux J., 2008(166), feb 2008, ISSN 1075-3583. http://dl.acm.org/citation.cfm?id=1344209. 1344217. 116 Bibliograf´ ıa [34] Helfer, T.T., M.D. Thornley, M.W. Regan, T. Wong, K. Sheth, S.N. Vogel, L. Blitz y D.C.J. Bock: The BIMA Survey of Nearby Galaxies (BIMA SONG). II. The CO Data. The Astrophysical Journal Supplement Series, 145(2):259–327, apr 2003, ISSN 0067-0049. http://stacks.iop.org/0067-0049/145/i=2/a=259. [35] Hoffa, C., G. Mehta, T. Freeman, E. Deelman, K. Keahey, B. Berriman y J. Good: On the Use of Cloud Computing for Scientific Workflows. En 2008 IEEE Fourth International Conference on eScience, p´ aginas 640–645. IEEE, dec 2008, ISBN 978-1-4244-3380-3. http://ieeexplore.ieee.org/ document/4736878/. [36] Inria Bordeaux Research Centre: Myrinet Express over Generic Ethernet Hardware, 2018. http://open-mx.gforge.inria.fr/, visitado el 07FEB2018. [37] Intel, M P I: Benchmarks: Users Guide and Methodology Description. Intel GmbH, Germany, 452, 2004. [38] Jacobini, C. y P. Lugli: The Monte Carlo method for semiconductor device simulation. Springer Science & Business Media, 2012. [39] Jaeger, S.: The common astronomy software application (CASA). En Astronomical Data Analysis Software and Systems XVII, volumen 394, p´ aginas 623–624, 2008. [40] Jonassen, David, Mark Davidson, Mauri Collins, John Campbell y Brenda Bannan Haag: Constructivism and computer mediated communication in distance education. American Journal of Distance Education, 9(2):7–26, jan 1995, ISSN 0892-3647. http://www.tandfonline.com/doi/abs/10.1080/ 08923649509526885. [41] Jones, M.T.: Virtio: marco de virtualizaci´ on de entrada/salida para Linux. Informe t´ ecnico, IBM, 2010. https://www.ibm.com/developerworks/ssa/ linux/library/l-virtio/. [42] Klein, A. y J. Tourville: 101 Labeled Brain Images and a Consistent Human Cortical Labeling Protocol. Frontiers in Neuroscience, 6, 2012, ISSN 1662-4548. http://journal.frontiersin.org/article/10.3389/fnins. 2012.00171/abstract. 117 JOS ´ EISAAC ZABLAH ´ AVILA [43] Lawson, C. L., R. J. Hanson, D. R. Kincaid y F. T. Krogh: Basic Linear Algebra Subprograms for Fortran Usage. ACM Transactions on Mathematical Software, 5(3):308– 323, sep 1979, ISSN 00983500. http://portal.acm.org/citation.cfm? doid=355841.355847. [44] Letaifa, A.B., A.l Haji, M. Jebalia y S. Tabbane: State of the Art and Research Challenges of new services architecture technologies: Virtualization, SOA and Cloud Computing. International Journal of Grid and Distributed Computing, 3(4):69–88, 2010. [45] Libvirt Project: The virtualization API, 2018. http://libvirt.org/, visitado el 31ENE2018. [46] Lin, G., D. Fu, J. Zhu y G. Dasmalchi: Cloud computing: IT as a service. IT Professional Magazine, 11(2):10, 2009. [47] Liu, Q., R. Safavi-Naini y N.P. Sheppard: Digital Rights Management for Content Distribution. En Proceedings of the Australasian Information Security Workshop Conference on ACSW Frontiers 2003 - Volume 21, ACSW Frontiers ’03, p´ aginas 49–58, Darlinghurst, Australia, Australia, 2003. Australian Computer Society, Inc., ISBN 1-920682-00-7. http://dl.acm.org/citation.cfm?id=827987. 827994. [48] Liu, S., W. Cai, S. Liu, F. Zhang, M. Fulham, D. Feng, S. Pujol y R. Kikinis: Multimodal neuroimaging computing: a review of the applications in neuropsychiatric disorders. Brain Informatics, 2(3):167–180, sep 2015, ISSN 2198-4018. http: //link.springer.com/10.1007/s40708-015-0019-x. [49] Markowich, Peter A.: The stationary semiconductor device equations. Springer Science & Business Media, 2013. [50] Matroska Organization: Matroska Media Container, 2018. https://matroska. org/, visitado el 08ENE2018. [51] MCBIN: Testing FreeSurfer. Informe t´ ecnico, Imaging, Martinos Center for Biomedical and Neuroimaging, Laboratory for Computational, 2016. https://surfer. nmr.mgh.harvard.edu/fswiki/TestingFreeSurfer. 118 Bibliograf´ ıa [52] Mell, P. M. y T. Grance: The NIST definition of cloud computing. Informe t´ ecnico, National Institute of Standards and Technology, Gaithersburg, MD, 2011. http://nvlpubs.nist.gov/nistpubs/Legacy/SP/ nistspecialpublication800-145.pdf. [53] Meuer, H.W., E. Strohmaier, J. Dongarra, H. Simon y M. Meuer: TOP500 Supercomputer Sites, 2015. https://www.top500.org/, visitado el 21MAY2017. [54] Meyer, Kenneth, Glen Hall y Dan Offin: Introduction to Hamiltonian dynamical systems and the N-body problem, volumen 90. Springer Science & Business Media, 2008. [55] MGH/HST Athinoula A. Martinos: Center for Biomedical Imaging, 2016. https: //www.nmr.mgh.harvard.edu, visitado el 02SEP2016. [56] Miley, G.K., G.C. Perola, P.C. der Kruit y H. der Laan: Active galaxies with radio trails in Clusters. Nature, 237(5353):269–272, 1972. [57] Mills, D.L.: Network Time Protocol (Version 3) Specification, Implementation and Analysis, 1992. https://tools.ietf.org/html/rfc1305, visitado el 28DIC2017. [58] Mohsen, N.: Global, regional, and national age–sex specific all-cause and causespecific mortality for 240 causes of death, 1990–2013: a systematic analysis for the Global Burden of Disease Study 2013. The Lancet, 385(9963):117–171, jan 2015, ISSN 01406736. http://linkinghub.elsevier.com/retrieve/ pii/S0140673614616822. [59] Motahari-Nezhad, H.R. and Stephenson, B. and Singhal, S.: Outsourcing business to cloud computing services: Opportunities and challenges. IEEE Internet Computing, 10(4):1–17, 2009. [60] MPI Forum: MPI, 2018. http://mpi-forum.org/docs/, visitado el 06FEB2018. [61] Murray, C.J.L., R.M. Barber, K.J. Foreman, A.A. Ozgoren, F. Abd-Allah, S.F. Abera, V. Aboyans, J.P. Abraham, I. Abubakar, L.J. Abu-Raddad, N.M. Abu-Rmeileh y et al. Achoki: Global, regional, and national disability-adjusted life years (DALYs) for 306 diseases and injuries and healthy life expectancy (HALE) for 188 countries, 119 JOS ´ EISAAC ZABLAH ´ AVILA 1990–2013: quantifying the epidemiological transition. The Lancet, 386(10009):2145– 2191, nov 2015, ISSN 01406736. http://linkinghub.elsevier.com/ retrieve/pii/S014067361561340X. [62] NetFlix Inc.: NetFlix, 2018. https://www.netflix.com/hn/, visitado el 08ENE2018. [63] NINDS: Neurological diagnostic tests and procedures, 2016. https://www.ninds.nih.gov/Disorders/ Patient-Caregiver-Education/Fact-Sheets/ Neurological-Diagnostic-Tests-and-Procedures-Fact. [64] NIST: NIST Big Data Interoperability Framework: Volume 1, Definitions. Informe t´ ecnico, National Institute of Standards and Technology, Gaithersburg, MD, oct 2015. http://nvlpubs.nist.gov/nistpubs/SpecialPublications/ NIST.SP.1500-1.pdf. [65] Norcott, W.D.: IOZone Filesystem Benchmark, 2017. http://www.iozone.org, visitado el 22JUN2017. [66] OpenNebula Project: OpenNebula, 2017. https://opennebula.org/, visitado el 20SEP2017. [67] Oracle Corp.: MySQL 5.6 Reference Manual, 2015. https://dev.mysql. com/doc/refman/5.6/en/innodb-fulltext-index.html, visitado el 30NOV2017. [68] Oracle Corp.: MySQL, 2017. https://www.mysql.com/, visitado el 28DIC2017. [69] Ott, J. y J. Kern: CASA Synthesis & Single Dish Reduction Reference Manual & Cookbook. CASA Supplement Series, 2017. https://casa.nrao.edu/casa_ cookbook.pdf. [70] Peng, Junjie, Xuejun Zhang, Zhou Lei, Bofeng Zhang, Wu Zhang y Qing Li: Comparison of Several Cloud Computing Platforms. En 2009 Second International Symposium on Information Science and Engineering, p´ aginas 23–27. IEEE, dec 2009, ISBN 978-1-4244-6325-1. http://ieeexplore.ieee.org/ document/5447227/. 120 Bibliograf´ ıa [71] Philpott, G. y A. Kattukaran: Evolution of TV: How TV’s Migration to the Cloud Might Upend TV As We Know It. Informe t´ ecnico, Google, 2015. https://www.thinkwithgoogle.com/marketing-resources/ evolution-of-tv-migration-to-the-cloud/. [72] Roth, G.D. (editor): Handbook of Practical Astronomy. Springer Berlin Heidelberg, Berlin, H., 2009, ISBN 978-3-540-76377-2. http://www.springerlink.com/ index/10.1007/978-3-540-76379-6. [73] Roy, Gareth, Andrew R. Brown, Fikru Adamu-Lema, Scott Roy y Asen Asenov: Simulation Study of Individual and Combined Sources of Intrinsic Parameter Fluctuations in Conventional Nano-MOSFETs. IEEE Transactions on Electron Devices, 53(12):3063–3070, dec 2006, ISSN 0018-9383. http://ieeexplore.ieee. org/document/4016359/. [74] Saad, Yousef, Gen Ching Lo y Sergey Kuznetsov: PSPARSLIB users manual: A portable library of parallel sparse iterative solvers. Univ. of Minnesota, 1997. [75] Scharfetter, D.L. y H.K. Gummel: Large-signal analysis of a silicon Read diode oscillator. IEEE Transactions on Electron Devices, 16(1):64–77, jan 1969, ISSN 0018-9383. http://ieeexplore.ieee.org/document/1475609/. [76] SDRT/UNAH: Utv, 2017. https://utv.unah.edu.hn/, visitado el 11NOV2017. [77] Selberherr, S.: Analysis and Simulation of Semiconductor Devices. Springer Vienna, 2012, ISBN 9783709187524. https://books.google.hn/books?id= E7roCAAAQBAJ. [78] Selberherr, Siegfried: Analysis and Simulation of Semiconductor Devices. Springer Vienna, Vienna, 1984, ISBN 978-3-7091-8754-8. http://link.springer. com/10.1007/978-3-7091-8752-4. [79] Sempolinski, Peter y Douglas Thain: A Comparison and Critique of Eucalyptus, OpenNebula and Nimbus. En 2010 IEEE Second International Conference on Cloud Computing Technology and Science, p´ aginas 417–426. IEEE, nov 2010, ISBN 978-1-4244-9405-7. http://ieeexplore.ieee.org/document/ 5708480/. 121 JOS ´ EISAAC ZABLAH ´ AVILA [80] Seoane, N., A.J. Garc´ ıa-Loureiro, K. Kalna y A. Asenov: Impact of intrinsic parameter fluctuations on the performance of HEMTs studied with a 3D parallel drift-diffusion simulator. Solid-State Electronics, 51(3):481–488, mar 2007, ISSN 00381101. http: //linkinghub.elsevier.com/retrieve/pii/S003811010700069X. [81] Seoane, N., R. Valin, A. Garcia-Loureiro, T.F. Pena y I. Zablah: Performance of numerical simulations on the cloud. En Actas de las XXIII Jornadas de Paralelismo (JP2012), p´ aginas 395–399, Elche, Alicante, 2012. Universidad de Alicante. [82] Seoane, Natalia, A. J. Garc´ ıa-Loureiro, K. Kalna y A. Asenov: Random dopant related variability in the 30 nm gate length In0.75Ga0.25As implant free MOSFET. Journal of Computational Electronics, 7(3):159–163, sep 2008, ISSN 1569-8025. http:// link.springer.com/10.1007/s10825-008-0233-3. [83] Springel, V.: GADGET2, 2016. http://wwwmpa.mpa-garching.mpg.de/ gadget/, visitado el 20SEP2017. [84] The Apache Software Foundation: Apache CloudStack, 2017. http:// cloudstack.apache.org/, visitado el 20SEP2017. [85] The CentOS Project: CentOS, 2017. https://www.centos.org/, visitado el 28DIC2017. [86] The HandBrake Team: Handbrake: The open source video transcoder, 2017. https: //handbrake.fr/, visitado el 20OCT2017. [87] The KVM Project: KVM, 2017. https://www.linux-kvm.org/page/Main_ Page, visitado el 21JUN2017. [88] The Open MPI Project: Open Source High Performance Computing, 2018. https: //www.open-mpi.org, visitado el 07FEB2018. [89] The OpenStack project: OpenStack, 2017. https://www.openstack.org/, visitado el 20SEP2017. [90] Thilker, D.A., R. Braun y R.M. Walterbos: Expanding HI shells in NGC 2403. First results from an automated object recognition package. Astronomy and Astrophysics, 332:429–448, 1998. 122 Bibliograf´ ıa [91] Urqu´ ıa-Osorio, Hebel., Isaac Zablah y Iscia Lopes-Cendes: Medicina de precisi´ on: ¿un nuevo paradigma en salud? Revista Hispanoamericana de Ciencias de la Salud, 2(3):199–202, 2016. http://www.uhsalud.com/index.php/ revhispano/article/download/168/107. [92] USC: Universidad Santiago de Compostela, 2018. http://www.usc.es/, visitado el 31ENE2018. [93] Vecchiola, C., S. Pandey y R. Buyya: High-Performance Cloud Computing: A View of Scientific Applications. En 2009 10th International Symposium on Pervasive Systems, Algorithms, and Networks, p´ aginas 4–16. IEEE, 2009, ISBN 978-1-4244-5403-7. http://ieeexplore.ieee.org/document/5381983/. [94] VirtualBox: VirtualBox, 2017. https://www.virtualbox.org/, visitado el O1ENE2012. [95] Wang, L., J. Tao, M. Kunze, D. Rattu y A.C. Castellanos: The cumulus project: Build a scientific cloud for a data center. En First workshop on Cloud Computing and its Applications (CCA), Computation Institute and the National Center for Data Mining at UIC, Chicago, USA, URL http://www. cca08. org, 2008. [96] Ward, J.S. y A. Barker: Undefined By Data: A Survey of Big Data Definitions. arXiv, sep 2013. http://arxiv.org/abs/1309.5821. [97] Wu, D., M.J. Greer, D.W. Rosen y D. Schaefer: Cloud Manufacturing: Drivers, Current Status, and Future Trends. En Volume 2: Systems; Micro and Nano Technologies; Sustainable Manufacturing, p´ agina V002T02A003. ASME, jun 2013, ISBN 978-0-7918-5546-1. http://proceedings. asmedigitalcollection.asme.org/proceeding.aspx?doi=10. 1115/MSEC2013-1106. [98] Wu, D., M.J. Greer, D.W. Rosen y D. Schaefer: Cloud manufacturing: Strategic vision and state-of-the-art. Journal of Manufacturing Systems, 32(4):564–579, oct 2013, ISSN 02786125. http://linkinghub.elsevier.com/retrieve/ pii/S0278612513000411. [99] Zablah, I., A. Garcia-Loureiro, F. Gomez-Folgar y T. F. Pena: Render on the cloud: Using cinelerra on virtualized infrastructures. 1st International Workshop on Cloud 123 ´ Indice de tablas 2.1. Distribuci´ on de los centros de supercomputaci´ on seg´ un la lista TOP500 de noviembredel2018 .............................. 13 3.1. Resultados con Linpack, detalla capacidad de c´ alculo y tiempo requerido de ejecuci´ on. ................................... 36 3.2. Tasas de transferencia en Kbytes/s de escritura y re-escritura en IOZone. . . 38 3.3. Resultados de la simulaci´ on de nanodispositivos, valores en segundos. . . . 39 4.1. Transcodaje del archivo fuente sobre anfitri´ on f´ ısico. Medidas en segundos (s), menor tiempo indica mejores resultados. De la primera columna de izquierda a derecha, corresponden a la funcionalidad de Turbo (T) y la segunda el n´ umero de n´ ucleos empleados (N), la ´ ultima es la media aritm´ etica de las medidas(Prom.)................................ 60 4.2. Transcodaje del archivo fuente sobre m´ aquinas virtuales. Medidas en segundos (s), menor tiempo indica resultados m´ as eficientes. La primera columna de izquierda a derecha, corresponde a la funcionalidad de Turbo (T) y la segunda el n´ umero de n´ ucleos empleados (N), la ´ ultima es la media aritm´ etica delasmedidas(Prom.)............................. 60 JOS ´ EISAAC ZABLAH ´ AVILA 4.3. Tiempo de ejecuci´ on por patr´ on en la m´ aquina f´ ısica. A menor tiempo mayor eficiencia. ................................... 83 4.4. Tiempo de ejecuci´ on por patr´ on de la instancia cloud. A menor tiempo mayor eficiencia. ................................... 84 132