design and deployment of high availability services in the cloud...
TRANSCRIPT
UNIVERSIDAD POLITEacuteCNICA DE MADRID
ESCUELA TEacuteCNICA SUPERIOR DEINGENIEROS DE TELECOMUNICACIOacuteN
ETSITESCUELA TECNICA SUPERIOR DE INGENIEROS DE TELECOMUNICACIOacuteN
GRADO EN INGENIERIacuteA DE TECNOLOGIacuteASY SERVICIOS DE TELECOMUNICACIOacuteN
TRABAJO FIN DE GRADO
DISENtildeO Y DESPLIEGUE DESERVICIOS DE ALTA
DISPONIBILIDAD EN LA NUBEUSANDO HERRAMIENTAS DE
COacuteDIGO ABIERTO
Antonio Juliaacuten Alfeacuterez Zamora
2016
Trabajo Fin de Grado
Tiacutetulo Disentildeo y despliegue de servicios de alta disponibilidad enla nube usando herramientas de coacutedigo abierto
Title Design and deployment of high availability services in thecloud using open source tools
Autor Antonio Juliaacuten Alfeacuterez Zamora
Tutor D Joaquiacuten Luciano Salvachuacutea Rodriacuteguez
Departamento Departamento de Ingenieriacutea de Sistemas Telemaacuteticos
Tribunal
Presidente D Juan Quemada Vives
Vocal D Santiago Pavoacuten Goacutemez
Secretario D Gabriel Huecas Fernaacutendez-Toribio
Suplente D David Fernaacutendez Cambronero
Fecha de lectura
Calificacioacuten
i
ii
Resumen
Las empresas punteras en tecnologiacutea e innovacioacuten cuentan con numerososrecursos de computacioacuten para llevar a cabo los diversos servicios que sustentanel proceso de negocio En general a estos equipos se les asignan de forma es-taacutetica las distintas tareas lo que conlleva un uso ineficiente al no distribuirseacorde con la carga de trabajo ademaacutes del trabajo de mantenimiento que con-lleva De entre las responsabilidades de los profesionales de las tecnologiacuteas dela informacioacuten estaacute gestionar eficientemente estos recursos asiacute como garantizarla disponibilidad de estos servicios atendiendo a las diferentes demandas decapacidad
La motivacioacuten de este trabajo surge de la oportunidad de desplegar las di-ferentes tareas o servicios de una forma maacutes eficiente gracias a la evolucioacuten entecnologiacuteas como la virtualizacioacuten almacenamiento distribuido o redes definidaspor software asiacute como la mejora y el abaratamiento de los enlaces de comunica-ciones que suponen un cambio de enfoque a la hora de disentildear la infraestructurade los sistemas de informacioacuten
En particular en este proyecto se va a entrar en detalle en herramientas cuyoobjetivo es optimizar los recursos y ademaacutes dar ciertas garantiacuteas de escalabili-dad disponibilidad y tolerancia a fallos De entre las soluciones que existen enla industria hemos seleccionado dos de coacutedigo abierto que alcanzan los objeti-vos definidos DCOS desarrollada por la empresa Mesosphere y basado en elproyecto Apache Mesos y Nomad creada por Hashicorp
En primer lugar se realizaraacute un anaacutelisis del funcionamiento de estas tecno-logiacuteas al que posteriormente seguiraacute el despliegue de casos de uso en la nube yfinalmente las conclusiones a las que se han llegado comparando el rendimientode ambas Con ello se pretende dar una perspectiva de la funcionalidad de estastecnologiacuteas y como encajan en la perspectiva actual dentro de las tecnologiacuteas dela informacioacuten
Palabras clave Cluacutester Gestor de recursos Planificador Compu-tacioacuten en la nube Apache Mesos HashiCorp Nomad MesosphereDCOS
iii
iv
Summary
Tech-savvy companies have a large amount of computational resources tohandle the services that support the business process Typically tasks are al-located in these computers in a static way which is inefficient due to the factthat they are not distributed according to the workload besides involving fur-ther maintenance work Among the responsibilities of Information Technologyprofessionals is efficiently managing these resources and providing some guaran-tees of availability of those services according to the different capacity demands
The motivation of this project comes from the opportunity of efficiently dis-tributing the different tasks or services of an enterprise thanks to the evolutionof technologies such as virtualization distributed storage or software defined net-works but also with the improvement and cost reduction of the communicationlinks a potential turning point in the approach of designing IT infrastructures
This project goes into more detail on tools which pursue resource optim-ization availability scalability and fault tolerance of services Amongst theexisting solutions in the industry two open source projects have been chosenboth achieving the predefined objectives DCOS developed by the companyMesosphere and based on the Apache Mesos project and Nomad developed byHashiCorp
Firstly the internals of these two technologies will be studied followed by adeployment of use cases in both of them in the cloud Lastly the conclusionsreached comparing their performance will be described By this it is intendedto provide a perspective of the functionality of these tools and how they fit inthe nowadays perspective on Information Technology
Keywords Cluster Resource Manager Cluster Scheduler CloudComputing Apache Mesos HashiCorp Nomad Mesosphere DCOS
v
vi
Iacutendice
Resumen III
Summary V
Iacutendice de figuras IX
1 Introduccioacuten y objetivos 1
11 Contexto 1
12 Objetivos 2
13 Estructura del documento 2
2 Cloud Computing 3
3 Nuevas cargas de trabajo 5
4 Gestioacuten de recursos Planificadores 8
41 Sistemas distribuidos 8
411 Clasificacioacuten 10
5 Herramientas 13
51 DCOS 14
511 Apache Mesos 15
512 Ejemplos de uso 18
52 Nomad 19
521 Protocolo de consenso Raft 20
vii
522 Protocolo gossip SWIM 23
523 Planificacioacuten 24
6 Casos de uso y despliegue 27
61 Aplicacioacuten Web 27
611 DCOS 28
612 Nomad 33
62 Servicio de integracioacuten continua 40
621 DevOps 40
622 Integracioacuten Continua 40
623 Jenkins con Nomad 42
624 Jenkins con DCOS 42
7 Escalando la infraestructura 43
71 Disentildeo 43
72 Implementacioacuten 44
8 Resultados y conclusiones 45
81 Comparacioacuten 45
82 Conclusiones 46
83 Objetivos conseguidos 46
84 Liacuteneas de investigacioacuten 47
viii
Iacutendice de figuras
1 Comparacioacuten Centro de datos - Computacioacuten en la nube 4
2 Arquitectura Docker 6
3 Planificador monoliacutetico 11
4 Planificador de dos niveles 11
5 Planificador de estado compartido 12
6 Planificador distribuido 12
7 Arquitectura DCOS 14
8 Servicios DCOS 15
9 Arquitectura de Apache Mesos 17
10 Arquitectura multi-regioacuten en Nomad 20
11 Equipos sin consenso ejecutando el protocolo RAFT 21
12 Un equipo pasa a estado candidato (RAFT) 22
13 Cambio en un registro (RAFT) 22
14 Aprobacioacuten del resto de equipos (RAFT) 23
15 Diagrama de tiempo del protocolo SWIM 24
16 Procedimiento de asignacioacuten en Nomad 25
17 Arquitectura aplicacioacuten web 28
18 Infraestructura en Azure 29
19 Arquitectura de la aplicacioacuten web en DCOS 32
20 Despliegue en Azure de Nomad+Consul 35
ix
1 Introduccioacuten y objetivos
11 Contexto
Las tecnologiacuteas de la informacioacuten y la comunicacioacuten estaacuten suponiendo uncambio draacutestico en la sociedad en 2007 comenzaron a aparecer los teleacutefonosinteligentes tal y como los conocemos y nueves antildeos despueacutes se empieza a con-cebir la idea de dar conectividad a todo dispositivo electroacutenico movimiento queha tomado el nombre de Internet de las cosas Para hacerse una idea de la rapi-dez y magnitud de esta evolucioacuten la consultora Excelacom1 ha estimado que enun minuto se realizan 24 millones de buacutesquedas en Google o se ven 278 millonesde viacutedeos en Youtube En una eacutepoca en la que los recursos tecnoloacutegicos crecenexponencialmente y los usuarios demandan mayor contenido y movilidad nocabe duda que las empresas deben adaptarse lo maacutes raacutepidamente posible a esteproceso de digitalizacioacuten movidas por las nuevas necesidades de las personas
Dado el gran volumen de informacioacuten a lo largo de estos antildeos la compu-tacioacuten y el almacenamiento estaacuten pasando de clientes locales a concentrarse engrandes centros de datos una tendencia que Google ha denominado ldquoWarehouse-scale computingrdquo en 2009[1] Este movimiento hacia la computacioacuten desde ser-vidor no solo viene de la necesidad de mejorar la experiencia de los usuariossino tambieacuten de facilitar la gestioacuten y configuracioacuten de los recursos asiacute como laubicuidad de acceso que permite
En 2006 Amazon lanza Amazon Web Services siendo uno de los pionerosen el mercado de los recursos virtuales ofreciendo capacidad de computacioacutencon un coste proporcional exclusivamente a los recursos utilizados Todo ellocambioacute la perspectiva de los modelos tradicionales de TI a la conocida comocomputacioacuten en la nube recursos informaacuteticos que antes suponiacutean barrerasde entrada en ciertos mercados han pasado a ser condicioacuten necesaria para laconstante evolucioacuten de la tecnologiacutea y la sociedad De hecho Cisco estima quepara el antildeo 2019 maacutes del 86 de las cargas de trabajo seraacuten procesadas porcentros de datos en la nube2
1httpwwwexcelacomcomresourcesblog2016-update-what-happens-in-one-internet-minute2httpwwwciscocomcenussolutionscollateralservice-provider
global-cloud-index-gciCloud_Index_White_Paperpdf
1
12 Objetivos
El propoacutesito de este proyecto es estudiar la viabilidad del uso de planifica-dores de recursos para aumentar la eficiencia de eacutestos y facilitar al desarrolladorel despliegue de aplicaciones de forma distribuida y asiacute ofrecer un servicio ca-racterizado por una alta disponibilidad y escalabilidad
A lo largo de este trabajo se han usado algunas de las herramientas quese estaacuten comenzando a desarrollar para hacer frente a este nuevo enfoque degestioacuten de infraestructuras de las tecnologiacuteas de la informacioacuten (en adelanteinfraestructuras TI) realizando pruebas de concepto sobre cada una de ellas
13 Estructura del documento
A continuacioacuten se detalla las secciones que componen este trabajo La es-tructura queda como sigue
Cloud computing Se entra en detalle en este nuevo modelo de negocio queha originado nuevos enfoques y disentildeos de las infraestructuras TI dentrode las organizaciones
Nuevas cargas de trabajo Se explican algunas tecnologiacuteas representativasque estaacuten suponiendo un desafiacuteo para los profesionales de TI a la horade planificar los recursos y que se ven beneficiadas por entornos de tipocloud
Gestioacuten de recursos Planificadores Estado del arte de las tecnologiacuteas degestioacuten de clusters y planificacioacuten de recursos
Herramientas Descripcioacuten detallada del funcionamiento y arquitectura de lasherramientas usadas a lo largo del proyecto
Casos de uso y despliegue Se describe el proceso de implementacioacuten de unaaplicacioacuten web y un servicio de integracioacuten continua con el software pro-puesto
Escalando la infraestructura Se propone un procedimiento con cierta inde-pendencia del proveedor cloud
Resultados y conclusiones Resume las ideas y hechos a los que se ha llegadoademaacutes de introducir liacuteneas de investigacioacuten futuras
2
2 Cloud Computing
El NIST (National Insitute of Standards and Technology) define este con-cepto como un modelo que permite un acceso ubicuo y bajo demanda de formaremota a un conjunto compartido de recursos de computacioacuten que pueden seraprovisionados y liberados con unos miacutenimos esfuerzos de gestioacuten por parte delproveedor del servicio3
Clasificacioacuten
La computacioacuten en la nube abarca una amplia variedad de servicios y enfo-ques por lo que en primer lugar se va a dar una clasificacioacuten para posterior-mente entrar maacutes en detalle Existen distintos modelos de nube atendiendo a lagobernabilidad de la infraestructura seguacuten el NIST
Nubes puacuteblicas Los servicios y recursos son ofertados de forma puacuteblica yson provistos por una organizacioacuten que los comercializa bajo demanda
Nube privada Los recursos son gestionados por una uacutenica organizacioacutenpara su propio uso
Nube comunitaria En este caso la infraestructura es administrada por unconjunto de organizaciones con objetivos comunes
Nube hiacutebrida Una combinacioacuten de las anteriores
A su vez los distintos servicios que ofrece se pueden clasificar atendiendo algrado de control del usuario
Servicios de software (Software as a Service SaaS) El proveedor se encargade toda la gestioacuten de la infraestructura y oferta aplicaciones a las cuales elcliente puede acceder de forma ubicua a traveacutes de diversos clientes comoun navegador web Por ejemplo Office 365 o Google docs
Servicios de plataforma (Platform as a Service PaaS) Modelo de distribu-cioacuten que ofrece la capacidad de desplegar aplicaciones desarrolladas por elcliente usando las herramientas y lenguajes de programacioacuten soportadaspor el proveedor pero sin la posibilidad de gestionar los recursos consu-midos En este caso el cliente solo tiene control sobre la propia aplicacioacuteny algunas configuraciones del entorno Es el caso de Heroku o Google AppEngine
3httpnvlpubsnistgovnistpubsLegacySPnistspecialpublication800-145pdf
3
Servicios de infraestructura (Infrastructure as a Service IaaS) Se ofertanrecursos de computacioacuten puros como procesamiento o almacenamientomediante una plataforma de virtualizacioacuten El cliente puede controlar elsistema operativo componentes de red y aplicaciones
Figura 1 Comparacioacuten Centro de datos - Computacioacuten en la nubeFuente httpsad-hocnet
De entre las numerosas ventajas que ofrece la computacioacuten en la nube se puededestacar su flexibilidad ya que permite aprovisionar recursos y adaptarlos deacuerdo a la demanda reduce el capital inmovilizado y su amortizacioacuten laubicuidad que permite su consumo desde cualquier parte con conexioacuten a la redy la seguridad y fiabilidad que ofrece el proveedor que normalmente cuenta conrecursos geograacuteficamente distribuidos frente a la gestioacuten y mantenimiento derecursos propios
4
3 Nuevas cargas de trabajo
Las organizaciones que cuentan con sus propios infraestructuras TI han co-menzado a adoptar un enfoque de nube privada para gestionar las tareas ofunciones informaacuteticas sobre las que se sustentan el negocio ya que una es-tructura virtualizada puede ofrecer ventajas con respecto a las adaptaciones decentros de datos tradicionales en los aacutembitos de rendimiento escalabilidad eincluso seguridad4
A su vez se han desarrollado nuevas tecnologiacuteas que suponen cargas detrabajo dinaacutemicas y con gran intensidad de consumo de datos para las empresasque se ven beneficiadas al desplegarlas en recursos virtualizados
Big data
Con la creciente aceptacioacuten de las tecnologiacuteas TIC por parte de la sociedadla cantidad de datos generados en la red es ingente Las profesionales de TI tienecomo objetivo extraer valor de eacutestos para por ejemplo prever las tendencias delmercado Sin embargo este incremento exponencial hace que su procesamientoy almacenamiento requiera de un sistema con gran escalabilidad dado el hechode que una sola maacutequina no puede proveer de la capacidad necesaria
Integracioacuten continua
Modelo informaacutetico que consiste en hacer integraciones automaacuteticas de unproyecto con cualquier cambio en el coacutedigo con el objetivo de detectar fallosde forma temprana Esto implica la compilacioacuten del coacutedigo y su ejecucioacuten enun entorno de pruebas automaacuteticamente un proceso que mediante tecnologiacuteasde virtualizacioacuten permiten simular entornos con eficiencia y rapidez Su imple-mentacioacuten en sistemas distribuidos permite tanto una mejor planificacioacuten comoun mejor rendimiento de los recursos
Arquitectura de microservicios
Enfoque para desarrollar aplicaciones software como un conjunto de serviciosautoacutenomos que se comunican entre siacute a diferencia de aproximaciones monoliacuteti-cas donde la loacutegica del servicio estaacute desarrollada como una unidad Un sistemadistribuido permite el despliegue de los componentes en distintas maacutequinas loque mejora tanto su escalabilidad como la tolerancia a fallos
4httpswwwakamaicomesesresourcespublic-private-cloudjsp
5
Docker
Proyecto de coacutedigo abierto que facilita y automatiza el despliegue de aplica-ciones al encapsular el entorno de trabajo en contenedores Linux una tecnologiacuteaque permite a un sistema fiacutesico ejecutar muacuteltiples instancias de sistemas opera-tivos aislados mediante entornos virtuales con sus propios espacios de procesosy redes pero compartiendo el nuacutecleo (kernel) con el equipo anfitrioacuten
En la figura 2 se compara la pila de una virtualizacioacuten tradicional con res-pecto a los contenedores no se simula el sistema operativo por lo que el procesoes mucho maacutes ligero
Docker se caracteriza por
Autosuficiencia Los contenedores cuentan con las libreriacuteas y configuracio-nes necesarias para ejecutarse de manera autoacutenoma al compartir el nuacutecleo
Portabilidad El hecho de que sean autosuficientes implica que es inde-pendiente del host es decir se puede desplegar en cualquier equipo quesoporte esta tecnologiacutea
Tamantildeo El peso de un contenedor es sustancialmente inferior a otrastecnologiacuteas de virtualizacioacuten
Figura 2 Arquitectura DockerFuente httpsdockercom
6
Los componentes fundamentales de esta herramienta son
Imaacutegenes Describen el entorno de base sobre el que ejecutar el contene-dor por ejemplo la imagen del sistema operativo Ubuntu Sobre eacutesta seconstruyen las aplicaciones particulares del usuario dando lugar a otraimagen
Contenedores Se crean a partir de las imaacutegenes y comprenden todo aquellonecesario para arrancar la aplicacioacuten decir su entorno de ejecucioacuten
bull Voluacutemenes Encargados de gestionar la persistencia de datos e inde-pendientes del ciclo de vida del contenedor
Registros Pueden ser puacuteblicos o privados y almacenan las imaacutegenes elregistro puacuteblico oficial de Docker es Docker Hub
Dadas estas caracteriacutesticas los profesionales TI estaacuten comenzando a adoptarDocker ya que facilita tanto los despliegues como el trabajo compartido en dis-tintos entornos Sin embargo esto requiere de un software que permita desplegarlos distintos contenedores de forma que puedan trabajar en conjunto procesoque se ha denominado orquestacioacuten de contenedores
7
4 Gestioacuten de recursos Planificadores
Para sacar el maacuteximo provecho a las tecnologiacuteas anteriormente descritaslo ideal es desplegarlas en sistemas distribuidos sin embargo esto aumenta lacomplejidad del propio despliegue asiacute como la necesidad de software especiali-zado para ello Se necesitan algoritmos de planificacioacuten que permitan obtener elmaacuteximo rendimiento de los recursos por un lado y dar ciertas garantiacuteas de quetodas las tareas y procesos se van a ejecuta por otro
41 Sistemas distribuidos
En primer lugar se definen los sistemas distribuidos o clusters como unconjunto de ordenadores conectados entre siacute cuyo objetivo es trabajar como unauacutenica instancia de gran capacidad5
Su clasificacioacuten variacutea de acuerdo a cada autor pero en general se puedendividir seguacuten su objetivo en alto rendimiento aquellos cuyo objetivos es proveerde gran capacidad de coacutemputo gracias al conjunto de los nodos y alta disponi-bilidad con los cuales se busca la fiabilidad del sistema mediante redundanciayo balanceo de carga
El intereacutes de este proyecto recae en los uacuteltimos ya que el objetivo es porun lado ofrecer al desarrollador un entorno donde desplegar sus aplicaciones deforma distribuida y por otro maximizar el rendimiento de los recursos
De forma general las caracteriacutesticas que se buscan son las siguientes
Elasticidad Adaptacioacuten a cargas dinaacutemicas de trabajo aumentando (o dis-minuyendo) recursos de manera automaacutetica de tal forma que la utilizacioacutensea lo maacutes cercana a la demanda
Disponibilidad Capacidad de un sistema para mantener el servicio fun-cional
Tolerancia a fallos Recuperacioacuten del servicio ante el fallo de un compo-nente
Balanceo de carga Compartir las tareas entre las diferentes maacutequinasredundadas evitando asiacute puntos de uacutenico fallo
5httpsenwikipediaorgwikiComputer_cluster
8
Los programas que se implementan en entornos distribuidos se caracterizanpor ejecutarse de forma concurrente en equipos independientes estar conectadospor una red que introduce fallos aleatorios y no compartir memoria ni reloj Estoimplica entre otras cosas que
Los nodos soacutelo tienen un acceso raacutepido a su memoria local por lo quecualquier informacioacuten relativa al estado global puede ser potencialmenteerroacutenea
Las maacutequinas pueden sufrir caiacutedas de forma aleatoria
El intercambio de informacioacuten puede fallar ya sea por error en transmisioacuteno por caiacuteda de los nodos
Estas dificultades se ponen de manifiesto en el teorema de CAP en cienciasde la computacioacuten el teorema de CAP que lanzado inicialmente como conjetu-ra en el antildeo 2000 por Eric Brewer (motivo por el cual al teorema se le conoceformalmente como teorema de Brewer) y posteriormente demostrado en el antildeo20026 establece que es imposible para un sistema de coacutemputo distribuido ga-rantizar simultaacuteneamente dos de las tres propiedades siguientes
Consistencia (Consistency) es decir que todos los nodos vean la mismainformacioacuten al mismo tiempo Se busca que un cambio en el sistema soacutelose ejecute satisfactoriamente si y soacutelo si se efectuacutea a todos las maacutequinasde tal forma que los datos entre ellos nunca difieren y la respuesta a unapeticioacuten sea la misma independientemente del nodo que la atienda
Disponibilidad (Availability) esto es la garantiacutea de que toda peticioacuten debeobtener una respuesta (servicio funcional) aunque exista inconsistenciaentre nodos
Tolerancia al particionado (Partition Tolerance) es decir que el sistemasiga funcionado a pesar de un fallo en la comunicacioacuten entre los equipos
Por todo lo expresado anteriormente conseguir un sistema distribuido capazde ofrecer procesamiento de forma transparente implica una arquitectura TIcompleja Se requieren de subsistemas y herramientas que permitan la cohesioacutenentre todos los nodos
Gestor de los recursos de las diferentes maacutequinas
Monitorizacioacuten tanto de los servicios activos como de la funcionalidad delsistema ademaacutes de poliacuteticas para recuperacioacuten de fallo
Protocolos de consenso que permitan a los nodos ser consistentes con elestado global del cluster
6urlhttpsgroupscsailmitedutdspapersGilbertBrewer2pdf
9
Herramientas de descubrimiento de servicios que permita la comunicacioacutenentre tareas distribuidas
Planificadores Encargados de distribuir las tareas y procesos en las dife-rentes maacutequinas asignaacutendole parte de su capacidad
Los planificadores del ingleacutes cluster schedulers son un componente funda-mental por lo que vamos a entrar un poco maacutes en detalle en ellos
Planificadores (Cluster Schedulers)
Es el software encargado de monitorizar los recursos usados por cada maacute-quina perteneciente a un cluster y distribuir la carga de trabajo entre ellas deacuerdo a un poliacutetica o reglas
Este tipo de herramientas comparten cierta terminologiacutea que es relevantedefinir
Tarea Unidad de trabajo computacional comprendida por una secuenciade instrucciones datos de entrada y recursos asociados Por ejemplo laejecucioacuten de un comando o el arranque de una base de datos
Nodo Cualquier maacutequina integrante de un cluster En una arquitecturamaestro-esclavo se definen dos roles
bull Cliente Agente Esclavo Aquellos ordenadores que se encargan deejecutar las tareas
bull Maestro Servidor Su objetivo es mantener el estado del cluster ygestionar sus recursos
411 Clasificacioacuten
A lo largo de los uacuteltimos antildeos se han desarrollado diferentes tipos de plani-ficadores[2]
Monoliacutetico
Un solo planificador que se encarga de distribuir todas las tareas entran-tes La mayoriacutea de los planificadores en computacioacuten de alto rendimiento asiacutecomo Borg desarrollado por Google son de este tipo En la figura 3 se pue-de observar de forma graacutefica el procedimiento siendo las cajas grises maacutequinaspertenecientes al cluster y los ciacuterculos las tareas a asignar
10
Figura 3 Planificador monoliacuteticoFuente httpswwwclcamacuk
Planificacioacuten de dos niveles
La mayoriacutea de los clusters ejecutan aplicaciones con distintas necesidadesdesde procesos casi instantaacuteneos hasta servicios persistenteslo que implica dis-tintas necesidades de recursos
Por ello la planificacioacuten a dos niveles distingue dos funciones la gestioacutende recursos (gestor) y la disposicioacuten de las tareas (planificador) Cada serviciotiene su propio planificador de tal manera que el gestor les ldquoofertardquo recursosde acuerdo a una poliacutetica y los planificadores se encargan de escoger la maacutesadecuada Esto permite que el proceso de distribucioacuten sea maacutes acorde con lasnecesidades de los diferentes servicios Apache Mesos que detallaremos maacutesadelante sigue este esquema
Como desventaja cabriacutea sentildealar que esta programacioacuten implica que los pla-nificadores pierden la vista general de la infraestructura y las tareas soacutelo puedenejecutarse con los recursos que les son ofrecidos lo que dificulta la implementa-cioacuten de prioridades de ejecucioacuten de tareas entre otras
Figura 4 Planificador de dos niveles
11
Planificacioacuten de estado compartido
Muacuteltiples reacuteplicas del estado del cluster se actualizan independientementepara cada planificador como se observa en la figura 5 cuando sucede un cambiode forma local el planificador se encarga de informar al resto
Ejemplo de este tipo son Omega la evolucioacuten de Borg por parte de GoogleMicrosoft Apollo y Nomad que usaremos para los casos de uso
De entre las desventajas se puede destacar el hecho de que en general losnodos trabajan con informacioacuten desactualizada lo que conlleva una degradacioacutendel rendimiento en situaciones de alta contienda
Figura 5 Planificador de estado compartido
Planificacioacuten distribuida
En este caso no existe coordinacioacuten entre los distintos planificadores Cadauno de ellos funciona con su propia vista del cluster Las tareas pueden serorganizadas por cualquiera de ellos y desplegadas en cualquier parte del clusteren base a la aleatoriedad y multiplexacioacuten estadiacutestica de los flujos de trabajosin ninguacuten control central
Figura 6 Planificador distribuido
12
5 Herramientas
En la industria comienzan a aparecer soluciones software de coacutedigo abiertoque aglutinan los servicios necesarios para gestionar la infraestructura TI de ma-nera maacutes eficaz El objetivo es doble se busca facilitar la gestioacuten de los recursosde computacioacuten para organizaciones con instalaciones propias mediante su usocon un enfoque cloud esto es desplegar aplicaciones a traveacutes de un conjuntode ordenadores de forma transparente y sin tener en cuenta la infraestructurasubyacente o aprovechar el maacuteximo rendimiento de la infraestructura de losproveedores cloud puacuteblicos de forma que se tiene el maacuteximo control sobre eacutestapero no se depende de las soluciones propietarias permitiendo asiacute despliegueshiacutebridos
Entre estas herramientas se pueden destacar
OpenStack Proyecto desarrollado por la fundacioacuten del mismo nombre paraproporcionar servicios de infraestructuras (IaaS) basado en componentesque se comunican a traveacutes de APIs El componente Magnum incluye mo-tores de orquestacioacuten de contenedores
Kubernetes Sistema de orquestacioacuten de contenedores Docker creado por Goo-gle
CoreOs Sistema operativo basado en Linux disentildeado para despliegues distri-buidos sobre contenedores incluyendo mecanismos de descubrimiento deservicio y comparticioacuten de configuracioacuten
Docker Swarm Herramienta nativa de orquestacioacuten de contenedores Docker
YARN Entorno de gestioacuten de recursos y aplicaciones distribuidas de Hadoopuna libreriacutea software de procesamiento de grandes conjuntos de datos
Como podemos observar existe un gran rango de opciones para gestionar lainfraestructura desde un bajo nivel como puede ser OpenStack hasta Kuberne-tes o Docker Swarm que ofrecen exclusivamente orquestacioacuten de contenedores
En este trabajo se ha optado por Mesosphere DCOS y HashiCorp Nomadque se encuentran en el teacutermino medio su objetivo es proporcionar serviciosde plataforma que permitan la coexistencia dediferentes cargas de trabajo en elcluster
13
51 DCOS
DCOS es un proyecto de coacutedigo abierto7 creado y desarrollado por la empre-sa Mesosphere Se describe como un sistema operativo distribuido que abstraelos recursos de un cluster (capacidad de procesamiento memoria) permite lagestioacuten de muacuteltiples ordenadores de forma transparente y simplifica la instala-cioacuten de aplicaciones distribuidas
Su arquitectura se puede comparar a la de Linux en teacuterminos de nuacutecleo(kernel) y espacio de usuario El primero consta de recursos protegidos a losque no puede acceder el usuario e involucra operaciones de bajo nivel comoasignacioacuten de recursos o aislamiento de procesos En el espacio de usuario seejecutan las aplicaciones y servicios de maacutes alto nivel
Siguiendo con este siacutemil el nuacutecleo de DCOS estaacute basado en Apache Mesosque se explicaraacute en un apartado posterior y el espacio de usuario que estaacute com-prendido por los componentes del sistema esto es las diferentes herramientasque en conjunto conforman DCOS y los servicios encargados de planificar yejecutar las aplicaciones y tareas del usuario
Figura 7 Arquitectura DCOSFuente httpsdcosio
De entre los componentes que conforman DCOS destacan
Admin Router Balanceador de carga central basado en NGINX que dis-pone un proxy entre todos los servicios en el puerto 80 permitiendo sugestioacuten mediante la interfaz graacutefica Ademaacutes se encarga de la autenticacioacutenpara acceder al panel de administracioacuten
Cosmos Gestor de paquetes de las aplicaciones
Diagnostics Se ejecuta en todos los nodos y se encarga de monitorizar elestado de los daemons que sustentan DCOS
7Desde abril de 2016 httpsmesospherecomblog20160419open-source-dcos
14
Exhibitor Gestiona y automatiza el despliegue de ZooKeper la herra-mienta que provee de configuracioacuten centralizada y registro de nombres
Marathon Equivale al proceso init de los sistemas tipo Unix esto es elprimer proceso en ejecucioacuten tras la carga del kernel y que genera los demaacutesprocesos Se encarga de arrancar y monitorizar las aplicaciones y servicios
Mesos-DNS Servicio de DNS interno que define el dominio mesos pa-ra nodos y tareas en el cluster es decir permite resolver nombres conindependencia de la direccioacuten fiacutesica
Minuteman Balanceador de carga integrado a nivel TCPUDP disponiblepara las propias aplicaciones
Por otra parte se definen como servicios a las diferentes aplicaciones dis-tribuidas que DCOS permite instalar en el cluster y que pueden haber sidodesarrollados por la misma empresa Mesosphere o por terceros por ejemploApache Spark Jenkins o Apache Hadoop En la figura 8 se muestra un diagramade los servicios disponibles incluyendo algunos de las aplicaciones distribuidasque soporta DCOS
Figura 8 Servicios DCOSFuente httpsdcosio
511 Apache Mesos
El nuacutecleo de DCOS estaacute basado en Apache Mesos un proyecto de coacutedigoabierto creado por la Universidad de California Berkeley y desarrollado actual-mente por la fundacioacuten Apache Se trata de un administrador de clusters queabstrae los recursos y los dispone para diferentes aplicaciones y entornos de tra-bajo distribuidos (frameworks) mediante una interfaz comuacuten En el momento deredaccioacuten de este proyecto Apache Mesos soportaba una variedad de entornosque abarcaba desde Big Data (Apache Spark Hadoop) hasta bases de datos(Cassandra Hypertable)
15
Arquitectura
Mesos se basa en la asignacioacuten de dos roles diferentes a los nodos
Maestros (Masters) Se encargan de la gestioacuten y reparticioacuten de los recursospara los diferentes entornos de trabajo mediante ldquoofertas de recursosrdquo deacuerdo a los disponibles y a la poliacutetica de asignacioacuten (planificacioacuten en dosniveles)
Esclavos (Slaves) Ordenadores donde se ejecutaraacuten las aplicaciones y cu-yos recursos son ofertados por los maestros
En el caso de fallo del maestro las tareas pueden seguir ejecutaacutendose perono se podraacute asignar nuevos recursos ni tareas por ello pueden existir varios enel cluster para configuraciones de alta disponibilidad pero soacutelo uno orquesta alos esclavos
Para la eleccioacuten del master liacuteder Mesos usa Apache ZooKeeper un proyectode software desarrollado por la misma fundacioacuten cuyo objetivo es proveer deun servicio de configuracioacuten centralizado y registro de nombres8
Por otra parte los entornos de trabajo son los programas que deciden final-mente queacute recursos se van a usar y se encargan de que los esclavos ejecuten lastareas Eacutestos se ejecutan sobre Mesos y constan de dos componentes
Planificador (Scheduler) Optimiza y decide los recursos a utilizar de losofertados informando a los Masters
Procesador (Executor) Ejecuta las aplicaciones o servicios en los esclavos
El objetivo final es conseguir una interfaz liviana tolerante a fallos paracualquier tipo de entorno de trabajo de tal manera que en los esclavos del clusterpuedan ejecutarse simultaacuteneamente tareas con necesidades y duracioacuten diferentesPara ello se basa en dos conceptos asignacioacuten y aislamiento de recursos
Asignacioacuten de recursos
En el cluster pueden coexistir entornos de trabajo con tareas de larga dura-cioacuten y con gran consumo de recursos con tareas cortas que los ocupan y liberancon rapidez El maestro integra un moacutedulo de asignacioacuten de recursos (allocationmodule) que se encarga del algoritmo de distribucioacuten
En el momento de escribir este proyecto estaban desarrollados dos moacutedulosuno mediante el cual el usuario puede asignar prioridades y otro que implementa
8httpszookeeperapacheorg
16
el algoritmo Dominant Resource Fairness9 a grandes rasgos se determina entodos los esclavos la tarea en ejecucioacuten que necesita maacutes recursos y se calcula laproporcioacuten del recurso de mayor peso con respecto al total por ejemplo si unatarea ocupa 2 GB de memoria con respecto a 10 GB totales que tiene el clusterse le asigna un dominant share del 20 la tarea se asignaraacute al nodo con menordominant share
Aislamiento de recursos
Para conseguir que tareas de diferentes entornos de trabajo y con distin-ta naturaleza se ejecuten simultaacuteneamente en un mismo nodo Mesos usa loscontenedores Linux (descritos en la seccioacuten 3)
Funcionamiento
La figura 9 muestra el esquema de la arquitectura de Apache Mesos conalta disponibilidad (tres maestros) y con dos entornos de trabajo ejecutaacutendo-se Hadoop que permite el almacenamiento y procesamiento de gran cantidadde datos para proyectos de big data y un sistema que implementa la interfazsistema de paso de mensajes MPI
Como se puede observar el sistema ZooKeeper elige a un solo maestro comoliacuteder y eacuteste orquesta el cluster comunicando los esclavos con los planificadoresde los diferentes entornos de trabajo Tambieacuten se puede observar como las tareasde los distintos entornos estaacuten distribuidas entre los tres esclavos disponibles
Figura 9 Arquitectura de Apache MesosFuente httpsmesosapacheorg
El proceso de asignacioacuten se realiza como sigue en primer lugar un usuariosolicita la ejecucioacuten de una tarea mediante la interfaz de cada entorno de traba-jo (interfaz graacutefica API HTTP ) De forma paralela un esclavo informa almaestro de los recursos que tiene libres En consecuencia eacuteste se lo notifica almoacutedulo de asignacioacuten que en funcioacuten de su configuracioacuten decide cuaacutento ofertar
9httpspeopleeecsberkeleyedu~aligpapersdrfpdf
17
y a queacute entorno de trabajo y enviacutea la oferta a los planificadores Eacutestos respondenal maestro con queacute recursos ha decidido usar para cada tarea Finalmente lastareas son enviadas al esclavo seleccionado el cual asigna los recursos indicadosal procesador (executor) quien finalmente las ejecuta
Cabriacutea pensar que esta metodologiacutea puede conducir a situaciones en lasque un entorno podriacutea quedarse con tareas sin ejecutarse a la espera de unaoferta satisfactoria para ello Mesos implementa un sistema de filtros medianteel cual los entornos especifican los requisitos miacutenimos que debe cumplir unaoferta por ejemplo se puede especificar en queacute nodos debe desplegarse la tareaEste sistema estaacute disentildeado asiacute con el objetivo de mantener lo maacutes transparenteposible esta herramientas de forma que acepte entornos de trabajo de distintasnaturalezas
512 Ejemplos de uso
Grandes empresas estaacuten usando Apache Mesos con eficacia de acuerdo a susnecesidades e infraestructuras Caben destacar
Ebay En el modelo de implementacioacuten continua en esta empresa10 cadadesarrollador cuenta con su propia instancia que se ejecuta en una maacutequinavirtual dedicada lo que ha conllevado un uso de los recursos poco eficiente Enuna prueba de concepto consiguieron realizar una herramienta de integracioacutencontinua distribuida basada en un cluster con Apache mesos y con el entornoMarathon y Jenkins
Apple Anuncioacute que el motor de su famosa herramienta de asistencia per-sonal para iPhones Siri estaacute desplegada sobre Apache Mesos11 Para ello handesarrollado su propio entorno para facilitar a los ingenieros a desplegar los ser-vicios que la herramienta necesita para resolver las peticiones de los usuarios
Twitter Desarrolloacute su propio entorno denominado Aurora y actualmentegestionan sus recursos y miden el coste de las tareas que los empleados usancon el objetivo de que sean conscientes del gasto que puede suponer un usoinadecuado de la infraestructura12
10httpwwwebaytechblogcom20140404delivering-ebays-ci-solution-with-apache-mesos-part-i11httpwwwbusinessinsidercomapple-siri-uses-apache-mesos-2015-812httpswwwlinuxcomNEWS4-UNIQUE-WAYS-UBER-TWITTER-PAYPAL-AND-HUBSPOT-USE-APACHE-MESOS
18
52 Nomad
Herramienta de coacutedigo abierto de gestioacuten de clusters creada y desarrolladapor Hashicorp13 que permite el despliegue de aplicaciones y procesos de formadistribuida
Las principales diferencias con Apache Mesos a grandes rasgos son
Arquitectura maacutes ligera Nomad soacutelo requiere de un fichero para funcionarejecutaacutendolo con las correspondientes configuraciones en todos los nodosrealiza las funciones de gestioacuten del cluster eleccioacuten de liacuteder planificacioacutende recursos y ejecucioacuten de las tareas
Centro de datos y regiones muacuteltiples Su arquitectura estaacute orientada afacilitar la gestioacuten de diferentes centros de datos geograacuteficamente distri-buidos
Entorno de ejecucioacuten Las tareas se definen y son interpretadas mediantecontroladores integrados en Nomad que se valen de los recursos y herra-mientas de los nodos clientes para ejecutarlas Esta integracioacuten dificultael desarrollo de controladores por parte de terceros a diferencia de Mesosque delega dicha responsabilidad en los entornos de trabajo externos alproyecto
Usa un planificador de estado compartido con respecto a la planificacioacutenen dos niveles de Mesos
Antes de entrar en maacutes detalle en la arquitectura es importante definir lossiguientes teacuterminos
Controlador (Driver) Software que se encarga de interpretar las definicionesde las tareas y ejecutarlas semejante a los procesadores de los entornosde trabajo de Mesos A la hora de redactar este proyecto Nomad contabacon controladores para contenedores Docker virtualizacioacuten de maacutequinasmediante el emulador QEMU aplicaciones java y archivos binarios
Grupo de trabajo (Task Group) Conjunto de tareas que se ejecutan en elmismo nodo cliente
Trabajo (Job) Conjunto loacutegico de tareas y grupos de trabajo que se despliegana la vez
Asignacioacuten (Allocation) Relacioacuten entre un grupo de trabajo y el cliente don-de se ejecuta
Evaluacioacuten (Evaluation) Proceso mediante el cual Nomad planifica y ges-tiona el registro o actualizaciones de los trabajos
13httpswwwhashicorpcom
19
Nomad sigue una arquitectura maestro-esclavo similar a la de Apache Mesosmuacuteltiples servidores acuerdan entre siacute un liacuteder que gestiona la planificacioacuten detareas en los clientes que soacutelo conocen sus asignaciones y las ejecutan
Todos los servidores participan paralelamente en tareas de planificacioacuten derecursos y asignacioacuten de tareas y ademaacutes entre ellos eligen un liacuteder que seencarga de la coordinacioacuten de la suscripcioacuten de los clientes al cluster y de lagestioacuten de las peticiones
Los clientes estaacuten configurados para comunicarse con el servidor usando lla-madas a procedimiento remoto (RPC por sus siglas en ingleacutes) que permite unordenador ejecutar coacutedigo en otra maacutequina Mediante esta tecnologiacutea los nodosclientes avisan de su estado e informa de sus asignaciones recursos y controla-dores disponibles
Existe la posibilidad de gestionar varios centros de datos agrupados en regio-nes eacutestas son independientes pero permite definir tareas o comprobar el estadode todas ellas desde cualquier punto A continuacioacuten se muestra una figura dela arquitectura a alto nivel de esta configuracioacuten
Figura 10 Arquitectura multi-regioacuten en NomadFuente httpswwwnomadprojectio
La herramienta se sustenta sobre tres protocolos fundamentales un protocolode consenso entre los servidores para compartir informacioacuten sobre su estado yel liacuteder un protocolo Gossip para la gestioacuten entre regiones y el planificador detareas
521 Protocolo de consenso Raft
El objetivo es obtener consistencia en un conjunto de nodos que comparteninformacioacuten es decir si un cliente realiza un cambio que todos los nodos veanla misma informacioacuten a la vez y ademaacutes sea tolerante a fallos Para ello se basaen el algoritmo Raft[13] que se detalla brevemente a continuacioacuten
20
Los nodos participantes en el algoritmo pueden estar en tres estados
Liacuteder (Leader) Todos los cambios que realicen en el cluster pasan por eacutel pri-mero
Seguidor (Follower) Nodo pasivo cuya responsabilidad es responder a laspeticiones del nodo liacuteder
Candidato (Candidate) Maacutequina que no ha encontrado liacuteder y solicita sueleccioacuten
Supongamos que tenemos cinco equipos que acaban de arrancar el protocoloEn la figura 11 se observan los nodos y sus respectivos registros a la derecha
Figura 11 Equipos sin consenso ejecutando el protocolo RAFTFuente httpsgithubcomongardieraftscope
Al comenzar todos los nodos son seguidores esperando recibir comunicacioacutende un nodo que actuacutee como liacuteder Cada nodo tiene un tiempo de espera aleatoriodespueacutes del cual si no es informado por un liacuteder pasa a estado candidato y pideel ldquovotordquo al resto de los participantes El algoritmo divide el tiempo en plazos uncandidato pasa a liacuteder si recibe la mayoriacutea de los votos en un plazo determinadoSe define mayoriacutea o cuoacuterum (quorum) comolceil
N2rceil
+ 1 (1)
donde N representa el nuacutemero de nodos
Para el ejemplo propuesto de 5 equipos se requieren de 3 votos Soacutelo losnodos que se encuentren en estado seguidor pueden votar una uacutenica vez a laprimera solicitud que reciba dentro de un plazo
Supoacutengase que el nodo denotado con S1 ha cumplido su tiempo de espera yrealiza la peticioacuten de voto (figura 12) A partir de este momento se pueden dartres casos
La maacutequina gana la eleccioacuten y pasa a ser liacuteder informando al resto
Otro servidor se establece como liacuteder en el mismo momento
Varios nodos pasan a ser candidatos por lo que ninguno consigue los votos
21
Figura 12 Un equipo pasa a estado candidato (RAFT)
Si un candidato recibe un aviso de un liacuteder en el mismo plazo el primeropasa a ser seguidor y se acaba la eleccioacuten de liacuteder
Por otro lado si un equipo candidato no recibe los votos en el plazo y agotasu tiempo de espera avanza al siguiente plazo y repite el proceso de votacioacutenLa tercera posibilidad puede conllevar a un estado indefinido ya que varioscandidatos pueden agotar su tiempo de espera al mismo tiempo y repartir losvotos Para solventarlo el algoritmo establece tiempos de espera aleatorios paralos candidatos
Siguiendo con el ejemplo propuesto el servidor S1 pasa a ser el liacuteder Cadacierto tiempo eacuteste debe realizar avisos a los nodos seguidores para no agotar sutiempo de espera
En este momento el cluster de servidores estaacute en ldquoconsensordquo y la informacioacutenen todos los nodos estaacute actualizada Un cambio en la informacioacuten inicia unproceso de replicacioacuten el liacuteder registra el cambio lo pasa al resto de nodos yuna vez eacutestos responden el cambio se hace efectivo
Supoacutengase que se realiza un cambio en los datos en la figura 13 en la partederecha se observa el cambio en el registro del servidor S1 que informa a losnodos seguidores En consecuencia los nodos registran el cambio y responden aS1
Figura 13 Cambio en un registro (RAFT)
Una vez el cuoacuterum (en el ejemplo tres equipos) informa al liacuteder de que
22
ha registrado el cambio el liacuteder lo hace efectivo en su sistema y notifica a losnodos que hacen lo mismo En la figura 14 el enviacuteo todaviacutea no ha llegado ala maacutequina S3 y se observa que no ha hecho efectivo el cambio (en el registroaparece punteado)
Figura 14 Aprobacioacuten del resto de equipos (RAFT)
Este protocolo funcionaraacute correctamente mientras exista un nuacutemero de nodosen funcionamiento igual o superior al cuoacuterum en el ejemplo propuesto elcuoacuterum es tres por lo que el sistema puede tolerar la caiacuteda de dos de los equipos
522 Protocolo gossip SWIM
Nomad permite la gestioacuten simultaacutenea de varios centros de datos reparti-dos en regiones geograacuteficamente separadas requiriendo de un protocolo ligeroque mantenga a los miembros actualizados sobre los participantes del conjun-to Para ello usa una ligera variante del protocolo SWIM[3] (Scalable Weakly-consistent Infection-style Process Group Membership Protocol) desarrollada porHashiCorp Estaacute clasificado como un protocolo de tipo gossip que debe su nom-bre a la semejanza con coacutemo se distribuye un rumor en una red social
SWIM se sustenta en dos caracteriacutesticas fundamentales la deteccioacuten de fallosy la distribucioacuten de la informacioacuten relativa a los miembros A continuacioacuten sedetalla el funcionamiento de ambos componentes
Deteccioacuten de fallos
Este componente tiene dos paraacutemetros el periodo de protocolo T y el nuacutemerode subgrupos de deteccioacuten de fallos k en los que se dividen los nodos Paracomprobar la comunicacioacuten entre dos maacutequinas usa la utilidad ping basadaen el protocolo ICMP La deteccioacuten de caiacuteda de un servidor sigue el siguientealgoritmo
Durante el periodo T cada miembro Mi de un subgrupo elige otro al azar Mjdel mismo subgrupo y le enviacutea un mensaje ping para comprobar su estado Enel caso de que se cumpla un tiempo de espera determinado por una estimacioacuten
23
del tiempo de ida y vuelta (RTT por sus siglas en ingleacutes) de la red y no hayarespuesta Mi le vuelve a enviar un mensaje ping indirectamente a traveacutes deun nuacutemero k de miembros escogidos aleatoriamente De no recibir ninguna res-puesta Mi establece que Mj ha sufrido un fallo y lo etiqueta como ldquosospechosordquoinformando al componente de distribucioacuten
Figura 15 Diagrama de tiempo del protocolo SWIMFuente httpswwwcscornelledu
Componente de distribucioacuten
Se encarga de informar de cualquier cambio en los miembros a todo el con-junto Los eventos de nodo caiacutedo y la unioacuten o disociacioacuten de un miembro setransmiten a todos los servidores para que actualicen sus lista Para distribuirla informacioacuten a todos los nodos se podriacutea usar el meacutetodo de multicast perosuele estar deshabilitado Por ello se utiliza una teacutecnica de transmisioacuten denomi-nada Piggybacking mediante la cual se adjunta a los propios mensajes PINGy ACK del algoritmo la informacioacuten a distribuir reduciendo asiacute la congestioacutenen la red
523 Planificacioacuten
Proceso encargado de distribuir las tareas entre los nodos clientes de acuerdoa su estado
El planificador de Nomad estaacute basado en las publicaciones de Google sobresus herramientas de gestioacuten de clusters Borg y Omega14 y entiende los trabajosdescritos por el usuario como un estado deseado es decir su despliegue en unamaacutequina cliente de forma correcta y los clientes como el estado actual esto eslo que se encuentra en ejecucioacuten El registro actualizacioacuten o cancelacioacuten de un
14httpresearchgooglecompubspub43438html
24
trabajo asiacute como el fallo de un nodo cliente implican un cambio de estado atramitar por el sistema lo que se define como evaluacioacuten (evaluation) Esto uacutelti-mo supone comparar el estado actual (clientes) con el estado deseado (conjuntode trabajos registrados) y enviarlos a los planificadores correspondientes que seencargaraacuten de asignar las tareas a los nodos clientes
Figura 16 Procedimiento de asignacioacuten en NomadFuente httpswwwnomadprojectio
En la figura 16 se observa el flujo de trabajo en el que las distintas evalua-ciones se encolan en el evaluation broker que se ejecuta en el servidor liacuteder ygestiona las evaluaciones pendientes asignaacutendoles prioridades
A continuacioacuten los nodos servidores ejecutan los scheduling workers queprocesan las evaluaciones llamando a los distintos planificadores que generanun plan de asignacioacuten esto es un conjunto de relaciones entre las tareas y losnodos clientes donde se ejecutaraacuten Este proceso se divide en dos fases primerose descartan aquellos clientes que no cumplan los requisitos y posteriormentese asigna una calificacioacuten al resto Se selecciona el nodo con mayor puntuacioacuteny se encola el plan en el gestor que se ejecuta en el servidor liacuteder Existen tresplanificadores de acuerdo al tipo de trabajo
Service Incluye aquellos trabajos que estaacuten destinados a ejecutarse en un pe-riacuteodo largo de tiempo Para realizar las asignaciones el planificador evaluacuteala mayor parte de los nodos y usa una versioacuten del algoritmo Best fit in-fluenciada por el trabajo de Google en su herramienta Borg Se trata deun algoritmo de planificacioacuten que sacrifica tiempo a cambio de maximizarel rendimiento de los clientes asignando la tarea a la maacutequina que tengala mayor carga de trabajo con el objetivo de reducir equipos en funciona-
25
miento
Batch Tareas que incluyen listas de comandos en general de menor duracioacuteny que no requieren interaccioacuten con el usuario Se vale del algoritmo deSparrow desarrollado por la universidad de Berkeley15 para limitar losnodos clientes a evaluar
System Trabajos destinados a ejecutarse en todos los nodos incluso los que seunen al cluster posteriormente
Core Mantenimiento interno de Nomad
Una vez se ha realizado el proceso de planificacioacuten el nodo liacuteder lo registra enla cola de planes (plan queue) que se encarga de asignarles prioridad y manejarcondiciones de carrera es decir que no accedan a los recursos de los clientes sincontrol y evitar que eacutestos superen su capacidad
La maacutequina liacuteder del conjunto puede de este modo aceptar una asignacioacuteny ser ejecutada por los clientes o por el contrario rechazaacutersela al planificadorlo que implicariacutea realizar un plan parcial o totalmente nuevo
Finalmente el estado de las evaluaciones se actualizan y los clientes soninformados de las asignaciones ejecutaacutendose las tareas
15httppeopleeecsberkeleyedu~keopublicationssosp13-final17pdf
26
6 Casos de uso y despliegue
Con el objetivo de mostrar las posibles utilidades que este tipo de sistemaspueden tener en las infraestructuras TI actuales se han desplegado las dos he-rramientas en la nube Microsoft Azure usando su servicio cloud de instancias demaacutequinas virtuales Linux para simular un conjunto de ordenadores conectadosentre siacute por una red LAN Sobre ellas se ha implementado dos casos de usouna aplicacioacuten web con una arquitectura con cierta orientacioacuten a microserviciosy un sistema de integracioacuten continua
El coacutedigo y todos los ficheros de configuracioacuten se pueden encontrar en elrepositorio del proyecto en GitHub16
61 Aplicacioacuten Web
Se busca simular el proceso de adaptacioacuten de una solucioacuten web para su des-pliegue en un sistema distribuido con las herramientas anteriormente descritascon el objetivo de aumentar tanto su escalabilidad como disponibilidad medianteredundancia
Se ha partido de una aplicacioacuten ya existente17 un servicio de almacenamien-to y reproduccioacuten de canciones A grandes rasgos este servicio permite crearusuarios subir canciones con sus respectivas portadas tener playlists propias yescuchar las canciones a traveacutes de un navegador web
La solucioacuten estaacute dividida en 4 partes (figura 17)
Una vista web con la loacutegica
Un almacenamiento conectado en red (NAS por sus siglas en ingleacutes)
Una API REST para gestionar las peticiones al almacenamiento
Base de datos NoSQL basada en MongoDB
La nueva tendencia de los proyectos web es su implementacioacuten en contene-dores Docker ya que facilitan su portabilidad y ofrecen un procedimiento dedespliegue raacutepido sobre todo a la hora de desarrollar y realizar pruebas en en-tornos de produccioacuten simulados Por ello en este caso se va a hacer uso de los
16httpsgithubcomAntonioAlfrzCloud-Orchestrators17httpsgithubcomsonsoleslpCDPSfy
27
motores de orquestacioacuten de contenedores de ambas herramientas Marathon enDCOS y el controlador Docker en el caso de Nomad
Figura 17 Arquitectura aplicacioacuten web
A continuacioacuten vamos detallar el despliegue en ambas herramientas de es-ta solucioacuten y observar tanto queacute dificultades se encuentran como que ventajasofrecen El objetivo final es adaptar el proyecto modificaacutendolo lo menos posiblecon objeto de analizar la capacidad de estas herramientas para desplegar cual-quier aplicacioacuten sin que eso conlleve la modificacioacuten de la arquitectura de eacutestaes decir que no sea dependiente del entorno
611 DCOS
Se ha descrito DCOS como una herramienta que se despliega sobre un con-junto de ordenadores y que permite instalar gestionar el despliegue de sistemasdistribuidos
Microsoft Azure cuenta con una plantilla para desplegar en su servicio cloudun cluster de maacutequinas virtuales con DCOS ya instalado que cuenta con
Maacutequinas maestras (1 3 o 5 a seleccionar por el usuario) configuradascomo un conjunto de disponibilidad esto eso Azure da ciertas garantiacuteasde que al menos una maacutequina estaraacute en funcionamiento
Maacutequinas agentes Por motivos de seguridad se distinguen dos roles
bull Nodos privados solo accesibles desde la red interna y configuradoscomo un conjunto de escala un recurso de Azure para gestionar ydesplegar maacutequinas con configuraciones ideacutenticas para permitir unraacutepido escalado
bull Un equipo conectado accesible desde Internet a travntildees de un balan-ceador de carga puacuteblico y situado en una subred externa
28
Dos balanceadores de carga
bull La interfaz puacuteblica del cluster que se conecta con el cliente puacuteblicobull Acceso a los equipos maestros para el administrador que soacutelo permiteconexioacuten mediante SSH y credenciales
Almacenamiento para todas las maacutequinas
Configuraciones necesarias de red y seguridad
En la figura 18 se observa un diagrama de la infraestructura
Figura 18 Infraestructura en Azure
El primer obstaacuteculo es la persistencia de estado de la aplicacioacuten que seconsigue gracias a una base de datos no relacional basada en MongoDB asiacutecomo el almacenamiento de las canciones Para implementarla tenemos variasposibilidades
Montar un sistema externo de almacenamiento conectado en red en todoslos agentes donde se ejecuten las tareas de esta manera si una tarea pasade un nodo a otro por cualquier motivo puede tener acceso a los mismosficheros (opcioacuten del caso de uso original)
Implementar un sistema de ficheros distribuidos en los agentes
Usar los servicios de almacenamiento de las nubes puacuteblicas
Aprovechar el sistema de voluacutemenes persistentes de Apache Mesos Eacutestepermite reservar recursos de un agente de forma que al arrancar una tarease crea un volumen independiente del ciclo de vida de eacutesta con ello esosrecursos donde se ha almacenado la informacioacuten pueden volver a ofrecerseal mismo entorno de tal manera que otra tarea pueda acceder a ella
DCOS aprovecha este sistema de voluacutemenes persistentes y permite instalarbases de datos distribuidas como ArangoDB o Apache Cassandra sin embargoesto implicariacutea modificar todo el coacutedigo referente al modelo de la base de datos
29
Por motivos de eficiencia y latencia asiacute como de una mayor gobernabilidadde los datos la mejor opcioacuten es usar el recurso de voluacutemenes persistentes queofrece Apache Mesos ya que de esta manera se gestionariacutea la aplicacioacuten completamediante una uacutenica herramienta Sin embargo esto implica que la informacioacutense encuentra exclusivamente en el agente donde se haya ejecutado la tarea y porlo tanto se sigue requiriendo de software externo para distribuir la informacioacutenpara que se accesible para todos los agentes A la hora de realizar este proyectose encontraba en desarrollo Flocker una solucioacuten desarrollada por ClusterHQque permite compartir los voluacutemenes de Docker a traveacutes de un cluster quesi bien es compatible con el planificador de Mesos el proyecto se encontrabatodaviacutea en fases tempranas de desarrollo y los sistemas de almacenamiento quesoporta quedaban fuera del aacutembito de este trabajo
Por todo ello dado que las maacutequinas se han desplegado en la nube puacuteblicade Azure se decidioacute usar su servicio de almacenamiento de objetos para lascanciones y otra maacutequina para desplegar MongoDB y asiacute mantener el modelode datos original de la aplicacioacuten La diferencia del almacenamiento de obje-tos con respecto a nivel de fichero es que el primero no tiene jerarquiacutea paraorganizar los archivos eacutestos se guardan como objetos (con sus metadatos) enun mismo espacio soacutelo diferenciaacutendose por un identificador uacutenico esto implicaentre otras cosas que se puede acceder a un fichero dado uacutenicamente su IDindependientemente de la localizacioacuten fiacutesica de eacuteste facilitando pues la gestioacuteny el desarrollo
El coacutedigo del proyecto se ha modificado en los siguientes apartados
Las direcciones de la base de datos y los balanceadores de carga asiacute comosus puertos estaban originalmente fijos Se han configurado como variablesde entorno para facilitar el descubrimiento del servicio y hacer transpa-rente la aplicacioacuten al entorno de despliegue
La API REST se ha adaptado al almacenamiento en Azure en vez de enlocal
Estas modificaciones no suponen un cambio sustancial pero permiten separala persistencia de las tareas ejecutadas por DCOS lo que facilita en granmedida su ejecucioacuten al ser totalmente sin estado y ademaacutes implican tenerlos datos bajo un mayor control
Para la orquestacioacuten de contenedores se va a usar el entorno Marathondesarrollado tambieacuten por Mesosphere Eacuteste se puede usar a traveacutes de una interfazgraacutefica la interfaz de liacutenea de comandos (en lo que sigue CLI por sus siglas eningleacutes) de DCOS o con su API HTTP
Primero se han publicado la imaacutegenes de los contenedores que encapsulanla interfaz web y la api de la aplicacioacuten en el repositorio puacuteblico DockerHub
Los despliegues en este entorno se describen mediante ficheros JSON en losque se detalla entre otras opciones la imagen del contenedor los puertos a usar
30
los recursos que debe ocupar en un nodo o las instrucciones de monitorizacioacuten
Para el servicio de descubrimiento DCOS ofrece la posibilidad de asignardirecciones IP virtuales (VIP por sus siglas en ingleacutes) a tareas que se compartenen todos los nodos DCOS lleva integrado un balanceador de carga a nivel TCP(el componente denominado Minuteman) que balancea entre las direccionesvirtuales de las tareas y todas las instancias de eacutestas a lo largo del cluster Estoes necesario por dos motivos equilibrar la carga de los equipos con el fin deevitar un punto de uacutenico fallo mediante redundancia y evitar la contienda dedirecciones al ejecutar las tareas en puertos aleatorios
Este balanceador de carga estaacute basado en el trabajo de Michael Mitzenma-cher The Power of Two Choices in Randomized Load Balancing18 A grandesrasgos el algoritmo mantiene una media moacutevil exponencial de latencias paracada destino (backend) ademaacutes de las caiacutedas consecutivas Si un destino noresponde a una negociacioacuten en tres pasos (three way handshake) de forma con-secutiva en un periodo inferior a 5 ms se considera caiacutedo El algoritmo iterasobre los destinos disponibles en base a su histoacuterico de fallos y escoge dos deforma aleatoria de los cuales coge el de mejor meacutetrica
Las direcciones virtuales soacutelo se pueden resolver dentro del cluster porello para implementar la interfaz puacuteblica de la aplicacioacuten esto es el balancea-dor de carga de la interfaz web usaremos un paquete de DCOS denominadomarathon-lb un balanceador basado en HAProxy y adaptado por MesosphereEn este caso equilibra la carga de todas instancias de las tareas ejecutadas porel entorno Marathon por sus etiquetas y permite ademaacutes definir como puntode entrada muacuteltiples hosts virtuales definidos por sus nombres completos dedominio (FQDN por sus siglas en ingleacutes) en nuestro caso la interfaz puacuteblicadel balanceador de Azure para los agentes
Por motivos de seguridad todas las tareas se ejecutan en los agentes privadoses decir los que son exclusivamente accesibles desde la red interna Por su partemarathon-lb se ejecuta en el agente puacuteblico que cuenta con IP puacuteblica y lospuertos 80 (HTTP) y 8080 abiertos de forma que la aplicacioacuten sea accesibledesde Internet Esto es posible debido a que Apache Mesos permite reservarrecursos mediante roles asignados a nodos para un uso especiacutefico De esta formala arquitectura vista desde la aplicacioacuten quedariacutea como en la figura 19
18httpswwweecsharvardedu~michaelmpostscriptstpds2001pdf
31
Figura 19 Arquitectura de la aplicacioacuten web en DCOS
Ejecucioacuten
A la hora de desplegar la aplicacioacuten DCOS puede gestionarse medianteuna interfaz graacutefica o una interfaz de liacutenea de comandos La primera se accedea traveacutes de un navegador web en el puerto 80 (HTTP) y permite instalar losentornos disponibles observar el estado de los nodos y las tareas que se estaacutenejecutando y los ficheros de registros que eacutestas generan
La CLI permite el control desde un nodo o una maacutequina remota (suponiendoque los maestros tienen IP puacuteblica y el puerto 80 abierto) ya que DCOS tieneun sistema de autorizacioacuten que permite tener una interfaz puacuteblica con ciertasgarantiacuteas de seguridad
Por su parte cada entorno de trabajo puede ser controlado por la CLI peroademaacutes cuenta con sus propias interfaces Marathon expone una API HTTPen el puerto 8080 de la direccioacuten puacuteblica de los maestros del cluster asiacute comootra interfaz graacutefica Para desplegar un contenedor se podriacutea usar la CLI
$ dcos marathon app add lt f i l e j songt
O la API HTTP
$ cu r l minusX POST http lt ip_maestro gt8080v2apps minusd ltf i l e jsongt minusH Contentminustype app l i c a t i o n j son
32
612 Nomad
La arquitectura de Nomad es maacutes sencilla ya que solo requiere de un ficheroejecutable en todos los nodos para funcionar Si DCOS es la base de instala-cioacuten de entornos de terceros Nomad integra todas las funcionalidades baacutesicasesto es gestor de recursos planificador y ejecutor en los nodos cliente Estaherramienta cuenta con un menor tiempo de desarrollo y en el momento deescribir este documento cuenta exclusivamente con los siguientes controladoresen comparacioacuten con los entornos de DCOS
Motor Docker es decir funcioacuten de orquestacioacuten de contenedores
Ejecucioacuten de archivos binarios como comandos de Shell
Ejecucioacuten de aplicaciones Java
Virtualizacioacuten de maacutequinas mediante tecnologiacutea QEMU
Todos ellos necesitan que la tecnologiacutea subyacente esteacute instalada en las maacute-quinas clientes (Docker Java QEMU) Actualmente no permite el registro decontroladores por parte de terceros aunque estaacute planificado en un futuro ofreceruna interfaz para su desarrollo
Nomad no cuenta con el servicio de descubrimiento sin embargo puede inte-grarse con la herramienta Consul desarrollada por la misma empresa Por otrolado para el balanceo de carga usaremos un contenedor Docker con HAProxyuna herramienta de coacutedigo abierto que ofrece tanto servicios de proxy como debalanceador y cuyos ficheros de configuracioacuten completaremos con el proyectoConsul Template19
Consul
Consul sigue la misma arquitectura que Nomad es decir un nodo servidorque orquesta un conjunto de maacutequinas clientes y permite a los procesos que seejecutan en los equipos definirlos como servicios ofreciendo diversas caracteriacutes-ticas entorno a estos de los cuales vamos a usar dos
Descubrimiento de servicio Las maacutequinas clientes publican en el cataacutelogode servicios las tareas en ejecucioacuten y Consul les asigna nombres de dominioaccesibles por todos los miembros del cluster a traveacutes de la interfaz DNSincluida en esta herramientaConsul se integra con Nomad de forma que todas las tareas que se ejecu-ten en la segunda son automaacuteticamente publicados como servicios de laprimera de esta manera no hace falta conocer la direccioacuten de la maacutequinacliente donde se esteacute ejecutando el proceso ya que se puede acceder a eacutela traveacutes de su nombre de dominio de forma transparente Por ejemplo si
19[httpsgithubcomhashicorpconsul-template]
33
ejecutamos una tarea con ID web en el puerto 8080 se puede acceder aella en la direccioacuten webserviceconsul8080Para que las direcciones propias de Consul las resuelva su propio DNS y noel que esteacute asignado por defecto en la maacutequina usaremos la herramientadnsmasq20 que permite especificar la direccioacuten de un servidor DNS paraconsultas de direcciones especiacuteficas
Monitorizacioacuten Permite realizar comprobaciones del servicio y seguir su esta-do Aprovecharemos esta funcionalidad tanto para definir el propio procesode Nomad como servicio de Consul como las tareas desplegadas
HAProxy + Consul Template
HAProxy es una solucioacuten versaacutetil de coacutedigo abierto que ofrece solucionesde balanceo de carga y proxy Existen otras herramientas en el mercado comoNGINX o ldirectord sin embargo HAProxy suponiacutea una solucioacuten sencilla deconfigurar para mostrar el caso de uso
El uso de estas herramientas se debe a dos motivos para que no existacontienda con respecto a los puertos de los clientes usados por las tareas eacutestos sevan a asignar de forma dinaacutemica lo que en principio implicariacutea que la aplicacioacutendeberiacutea realizar consultas DNS de tipo SRV (que incluye puertos) a la interfazde Consul y balancear la carga entre tareas por redundancia y capacidad
Como la direccioacuten IP y puerto son variables cada vez que las tareas seactualicen o se reasignen es necesario volver a configurar HAProxy de formamanual Por ello HashiCorp ha desarrollado un programa denominado Con-sul Template que realiza peticiones sucesivas a la interfaz HTTP de Consul delas direcciones fiacutesicas de un servicio y reinicia automaacuteticamente el proceso deHAProxy Asiacute definiendo estas tareas como servicios Consul podremos tantomonitorizarlas como escalar las tareas dinaacutemicamente sin necesidad de cambiarel balanceador A partir del contenedor Docker oficial de HAProxy se ha desa-rrollado otro con la configuracioacuten baacutesica y con Consul Template para desplegarlocomo una tarea en Nomad
Despliegue
Se ha usado el mismo coacutedigo que en el apartado anterior con la persistenciaen el servicio de almacenamiento de Azure Desde la perspectiva del hardwarese implementaraacute la misma infraestructura que en el caso de DCOS (figura 18)estos es definiremos dos tipos de maacutequinas clientes un agente que se conectaraacutecon el balanceador de carga con nombre de dominio puacuteblico y donde se desple-garaacute el balanceador de carga de la vista web y agentes privados no accesiblesdesde fuera del cluster y donde se ejecutaraacuten el resto de tareas en la red inter-na La principal diferencia radica en las tareas que ejecutan HAproxy y ConsulTemplate que sustituye a las direcciones IP virtuales que ofrece DCOS
20httpwwwthekelleysorgukdnsmasqdochtml
34
Figura 20 Despliegue en Azure de Nomad+Consul
Cabe matizar que los balanceadores basados en HAProxy se implementanpor necesidad de la aplicacioacuten para el descubrimiento del servicio a diferenciade los de Azure que se implementan por motivos de seguridad y escalabilidaddel cluster en siacute
Configuracioacuten Nomad
Los ficheros de configuracioacuten de las maacutequinas maacutester y cliente son similaresy comparten la mayoriacutea de las opciones como por ejemplo el nombre del nodoo la interfaz de red donde escucha Nomad las peticiones Sus opciones son engeneral auto-explicativas sin embargo existen dos detalles que matizar
El proceso de Nomad escucha las peticiones tanto de los protocolos deconsenso como del usuario a traveacutes de una interfaz de red que se debeindicar en el fichero de configuracioacuten
En el caso de los clientes se deben indicar las direcciones de los servidoresdel cluster sin embargo se trata de un sistema dinaacutemico en el que losnodos pueden sufrir errores y cambiar de direccioacuten Por ello se ha definidoNomad como un servicio de Consul y asiacute poder definir la direccioacuten de losservidores como un nombre de dominio no por su direccioacuten fiacutesica que elservidor DNS de Consul se encargaraacute de resolver
Por defecto Nomad usa los siguientes puertos
API HTTP 4646 Peticiones HTTP y recepcioacuten de oacuterdenes mediante laliacutenea de comandos
RPC 4647 Protocolo de consenso entre los nodos del cluster
Serf 4648 Protocolo de gossip entre los servidores de los centros de datosgobernados por Nomad
35
Los dos uacuteltimos deben ser interfaces alcanzables por otros nodos sin embargo laAPI HTTP por motivos de seguridad deberiacutea ser local ya que en caso contrariocualquier persona con acceso a ella tiene el control sobre la herramienta Eacutestasolo deberiacutea estar accesible en un servidor o gestionarlo mediante una terminalSSH por ejemplo En este trabajo al ser una prueba de concepto se ha abiertoen todos los nodos
Trabajos de Nomad
Las tareas se detallan en ficheros con formato HashiCorp Configuration Lan-guage un derivado del formato JSON creado por la empresa que le da nombrecompatible con eacuteste y que permite comentarios
En estos ficheros se puede definir
La regioacuten y el centro de datos donde se ejecutaraacute (Nomad permite lagestioacuten de centros de datos geograacuteficamente distribuidos en regiones)
La poliacutetica de actualizacioacuten de la tarea
Grupo de tareas esto es que se ejecutaraacuten en el mismo nodo
El nuacutemero de grupos a ejecutarescalar asiacute como los liacutemite que debencumplir los nodos asignados
La poliacutetica de reinicio ante fallo o error
Tareas El controlador su configuracioacuten los paraacutemetros del servicio aso-ciado a registrar en Consul asiacute como los recursos que consume (puertosmemoria)
En nuestro caso usamos sobre todo el controlador Docker esto eso orques-tacioacuten de contenedores en los nodos clientes y tres de sus opciones
Imagen del contenedor Se han subido todas las imaacutegenes del proyecto a Doc-ker Hub donde por defecto se busca la imagen
Puertos Los puertos a usar por el contenedor que pueden ser estaacuteticos asigna-dos por el usuario o dinaacutemicos siendo Nomad el que se encarga de mapearun puerto libre del nodo cliente al expuesto por el contenedor
Servidores DNS Como usamos la interfaz DNS de Consul como descubri-miento de servicio se debe configurar el contenedor para que use cualquiernodo del cluster como servidor DNS
Configuracioacuten Consul
Al ser desarrolladas por la misma empresa los ficheros de configuracioacuten deConsul y Nomad comparten muchas opciones Consul tambieacuten acepta peticionesa traveacutes de una interfaz de red siendo los puertos usados por defecto
36
RPC 8300 8400 Maneja la peticiones del resto de nodos y usuarios
Serf 8301 8302 Protocolo gossip
HTTP API 8500
HTTPS API Desactivada por defecto
Interfaz DNS 8600
Se debe asignar a los protocolos internos del cluster esto es RPC y Serf unainterfaz alcanzable por los nodos y por el contrarioasignar a los dos uacuteltimos ala interfaz de loopback por motivos de seguridad
Cabe destacar que Consul tambieacuten cuenta con una interfaz graacutefica que per-mite ver el estado de los equipos y los servicios registrados y que se encuentra enel mismo puerto que la API HTTP en la direccioacuten httpIP_EQUIPO8500ui
Ejecucioacuten
Tanto Nomad como Consul requieren de la ejecucioacuten de un fichero en todoslos nodos integrantes del cluster Como prueba de concepto se ha decidido usardos servidores para ambos aunque cabe matizar que es un nuacutemero ineficienteya que la caiacuteda de uno de ellos supondriacutea la peacuterdida del cuoacuterum y por tantodel consenso del cluster
En primer lugar se arrancan los servidores que son los encargados de ejecu-tar el protocolo de consenso y gestionar el cluster y a continuacioacuten los clientesque no tienen praacutecticamente estado y dependen de los servidores
En el caso de Consul se debe indicar el directorio donde se guardan losficheros que describen los servicios asiacute como el archivo que especifica el resto delas opciones
1 Se inicia el primer servidor en uno de los equipos
$ consu l agent minuscon f i gminusd i r e t c consu l d s e r v i c e s minuscon f i gminus f i l e consu l_server j son
2 Los siguientes equipos deben unirse al anterior por lo que antildeadimos elargumento join con la direccioacuten del primer servidor Para el caso de otrosservidores
$ consu l agent minuscon f i gminusd i r e t c consu l d s e r v i c e s minuscon f i gminus f i l e consu l_server j son minus j o i n ltIP_servidor1gt
37
Una vez los servidores han alcanzado el consenso y elegido un liacuteder en losclientes
$ consu l agent minuscon f i gminusd i r e t c consu l d s e r v i c e s minuscon f i gminus f i l e c on su l_c l i en t j son minus j o i n ltIP_cualquierServ idorgt
El proceso para iniciar Nomad es igual y los comandos similares sin embargoya no es necesario indicar una direccioacuten IP fija en los equipos sino el nombre dedominio del servicio de Nomad registrado por Consul En el primer servidor
$ nomad agent minusc on f i g nomad_server j son
Y el resto de equipos (con su fichero de configuracioacuten correspondiente)$ nomad agent minusc on f i g nomad_server j son minus j o i n nomad s e r v i c e consu l
Por uacuteltimo para desplegar la aplicacioacuten web se han escrito tres ficherosque detallan las tareas de la interfaz web API y los balanceadores de cargaMediante la CLI
$ nomad run minusaddress=http lt ip_c lus te r gt4646 lt f i l e hclgt
O mediante la API HTTP de Nomad$ cu r l minusX POST minusd ltf i l e hclgthttp lt ip_c lus te r gt4646 jobltjob_namegt
Ansible
Como se puede comprobar con el aumento del nuacutemero de equipos pasa aser inviable manejar todos los nodos a traveacutes de terminal Ademaacutes como seha comentado con anterioridad Nomad requiere que en los nodos clientes es-teacuten instalados las herramientas que soporten las tareas por ejemplo el motorde Docker Por ello para facilitar tanto el arranque como la instalacioacuten de lasdependencias vamos a usar Ansible una herramienta de coacutedigo abierto desarro-llada en Python que permite gestionar configuraciones aprovisionar recursosdespliegue de aplicaciones de forma automaacutetica
A grandes rasgos esta herramienta funciona mediante ficheros en formatoYAML denominados play-books que describen un conjunto de pasos a ejecutaren una lista de equipos remotos Estos pasos son ejecutados por moacutedulos inde-pendientes a traveacutes de SSH es decir en cualquier ordenador con conexioacuten a los
38
hosts dado su contrasentildea o clave puacuteblica puede arrancar el script y realizariacutealos pasos de forma remota gestionando el cluster desde un solo equipo
Se han desarrollado guiones para lo siguiente
Descarga de los binarios de Nomad y Consul en todos los nodos copiade los ficheros de configuracioacuten baacutesicos y modificarlos de acuerdo a cadanodo (nombre del equipo direccioacuten IP)
Instalacioacuten de las dependencias
Arranque de Nomad y Consul
Ansible extiende su funcionalidad a traveacutes de moacutedulos independientes que per-miten por ejemplo instalar paquetes mediante herramientas de gestioacuten de pa-quetes (APT yum) aprovisionar automaacuteticamente maacutequinas virtuales de Ama-zon EC2
Algunas opciones de los ficheros de configuracioacuten de Nomad y Consul sondependientes del nodo particular por ejemplo la interfaz de red Para estetrabajo se ha realizado un moacutedulo para modificar los ficheros de configuracioacutende forma automaacutetica En el repositorio del proyecto se encuentra una carpetadonde se encuentran todos los ficheros necesarios para desplegar un clustertotalmente funcional solo requiere de una liacutenea de terminal con Ansible
$ ans ib l eminusplaybook minus i hos t s minusk ltssh_passgt minusu ltnode_usergt s i t e yml
39
62 Servicio de integracioacuten continua
Se ha implementado un sistema de integracioacuten continua que permite ejecu-tar tareas de compilacioacuten y pruebas de forma distribuida aumentando asiacute elrendimiento de los equipos En primer lugar se detallaraacute los motivos por los quepuede resultar beneficioso para las empresas una implementacioacuten de este tipo alo que seguiraacute los detalles del despliegue
621 DevOps
Metodologiacutea que defiende la comunicacioacuten y colaboracioacuten entre desarrolla-dores de software y los profesionales de operaciones a lo largo de todo el ciclo devida de una aplicacioacuten Estaacute muy relacionado con el desarrollo aacutegil de softwareesto es un enfoque para los proyectos que defiende el desarrollo iterativo e in-cremental donde los requisitos y soluciones evolucionan con el tiempo seguacuten lanecesidad del proyecto DevOps extiende esta filosofiacutea a todas los componentesde un servicio incluyendo sistemas y operaciones
Se trata de un concepto que cada organizacioacuten o empresa adapta a suspropias necesidades y procesos de negocio en este proyecto nos vamos a centraren la integracioacuten continua una praacutectica fundamental tanto del desarrollo aacutegilcomo de esta filosofiacutea
622 Integracioacuten Continua
Se define como una praacutectica de desarrollo software donde los miembros delequipo ponen en comuacuten su trabajo frecuentemente al menos una vez al diacutea21Cada integracioacuten se verifica con una compilacioacuten automaacutetica que incluye laejecucioacuten de pruebas para detectar errores de integracioacuten tan pronto como seaposible
Desde el punto de vista operativo esto supone automatizar la configuracioacutende equipos o el despliegue de maacutequinas virtuales donde compilar el proyecto yejecutar las pruebas y posteriormente eliminarlas Este flujo de trabajo se vebeneficiado en entornos distribuidos ya que el objetivo del desarrollador es com-probar el resultado de las pruebas raacutepidamente sin preocuparse del despliegueo los propios equipos
Para esta prueba de concepto vamos a usar Jenkins un servidor de integra-cioacuten continua escrito en Java que nos permite definir trabajos que contendraacutenla descripcioacuten tanto del entorno como su ejecucioacuten
Este sigue una estructura maestro-esclavo muy similar al de los gestores declusters usados en este proyecto el maestro contiene toda la loacutegica del servicio
21httpmartinfowlercomarticlescontinuousIntegrationhtml
40
trabajos autenticacioacuten y los esclavos son los encargados de la ejecucioacuten ensiacute Jenkins tiene varias viacuteas para aprovisionar los uacuteltimos
Mediante SSH
Interfaz graacutefica
Desarrollar un script propio
Ejecucioacuten de un fichero java
La ventaja de usar planificadores es que el despliegue de esclavos es dinaacutemicoes decir no tener una maacutequina especiacuteficamente configurada para ello DCOS yNomad se encargaraacuten de configurar estos despliegues en sus maacutequinas y poste-riormente eliminarlos Para ello se ha usado la uacuteltima opcioacuten definiendo tareasque descarguen el fichero java Con todo ello se consigue un entorno de inte-gracioacuten continua eficiente que ademaacutes permite la ejecucioacuten de otros servicios deforma independiente
Jenkins permite la creacioacuten de plugins que extienden sus funcionalidadesTanto Nomad22 como Apache Mesos cuentan con uno que permite su integra-cioacuten
Para esta prueba se va a usar el mismo proyecto que para el caso de usode orquestacioacuten de contenedores la aplicacioacuten web al que se le ha antildeadido untest para comprobar que se conecta correctamente a la base de datos medianteMocha un framework de Nodejs Por otro lado se antildeade el plugin de git ya queel coacutedigo se obtiene de GitHub el repositorio remoto de control de versiones delproyecto
El proceso general de ejecucioacuten seriacutea como sigue
1 Se ejecuta el maestro de Jenkins como tarea Docker partiendo de la imagenoficial
2 Al arrancar un trabajo se manda una tarea a los planificadores que laasignaraacuten a un nodo cliente Esta tarea consiste en la descarga del ficherode configuracioacuten Java y arrancarlo configurando el equipo como un clientede Jenkins temporalmente
3 Jenkins ejecuta el trabajo en el nuevo cliente en este caso iniciar la apli-cacioacuten web iniciar las pruebas y generar un informe
4 Se elimina el cliente
A continuacioacuten se detallan los matices de cada herramienta a la hora de imple-mentar este servicio
22Desarrollado por Ivo Verberk httpwwwivoverberknl
41
623 Jenkins con Nomad
El plugin permite la ejecucioacuten del fichero Java mediante dos controladorescontenedores Docker y Java En este proyecto nos hemos decantado por el pri-mero ya que nos ahorra instalar la maacutequina virtual de java en todos los nodoscliente Por ello se ha construido un contenedor base con Java para la ejecucioacutendel fichero de configuracioacuten y Nodejs para lanzar la aplicacioacuten web
El plugin se configura con la direccioacuten IP del cluster y el contenedor queejecuta el esclavo Jenkins Por su parte el trabajo en Jenkins se define conel repositorio en GitHub donde se aloja el coacutedigo del proyecto a probar y loscomandos a ejecutar en este caso npm update y npm test
624 Jenkins con DCOS
En el caso de DCOS su sistema de paquetes incluye Jenkins por lo queal instalarlo ya se tiene la configuracioacuten de Mesos totalmente funcional Sinembargo para ejecutar la aplicacioacuten en particular y las pruebas se requiere deNodejs en los equipos esclavos por ello debemos antildeadir un plugin de Jenkinsque permite instalar este entorno antes de ejecutar el trabajo Una vez hechoesto soacutelo queda definir la tarea igual que en el caso anterior
Cabe destacar que Mesosphere tambieacuten ha desarrollado un plugin que per-mite hacer despliegues en Marathon de tal manera que permitiriacutea con cadacommit del coacutedigo compilar la imagen del contenedor Docker y desplegarlaautomaacuteticamente aunque en este proyecto no se ha hecho pruebas de esta fun-cionalidad
42
7 Escalando la infraestructura
Uno de los factores clave que se busca a la hora de implementar sistemasdistribuidos es el poder escalar la infraestructura de forma maacutes sencilla estoes detectar que las maacutequinas estaacuten alcanzando el liacutemite de su capacidad yaumentar eacutesta ya sea mejorando sus caracteriacutesticas teacutecnicas o antildeadiendo maacutesnodos al cluster
El coacutedigo y todos los ficheros de configuracioacuten de esta seccioacuten tambieacuten sepueden encontrar en el repositorio del proyecto en GitHub23
71 Disentildeo
Microsoft Azure permite organizar los servicios cloud de forma loacutegica a traveacutesde grupos de recursos y asiacute poder crear o eliminar eacutestos en conjunto parauna aplicacioacuten determinada (por ejemplo una aplicacioacuten web suele requerir demaacutequinas virtuales bases de datos almacenamiento) Ademaacutes dispone dela opcioacuten de crear plantillas en formato JSON que permite al desarrolladordefinir los recursos y su interrelacioacuten para desplegar de forma automaacutetica unainfraestructura TI en la nube
Azure tambieacuten ofrece la posibilidad de monitorizar el estado de las maacutequinasvirtuales a traveacutes de extensiones lo que permite configurar el escalado automaacute-tico al alcanzar cierto liacutemite definido por el operador Eacutesta es a priori la formaen que deberiacutea implementarse hablando en teacuterminos de eficiencia sin embargoesta aproximacioacuten es totalmente dependiente de la plataforma es decir no sepuede extrapolar a otro proveedor o sobre recursos propios sin realizar un nue-vo disentildeo En este proyecto las tareas que son ejecutadas por estos equipos notienen estado ya que todo lo relativo a la persistencia lo hemos asignado fueradel cluster esto permite escalar la plataforma a traveacutes de otra aproximaciones
Las plantillas aceptan una serie de variables a indicar por el usuario entreotras los conjuntos de escala para definir los nodos aceptan una variable quedefine el nuacutemero de maacutequinas que los componen Por otro lado Azure ofreceuna API REST y kits de desarrollo software (SDK por sus siglas en ingleacutes) quepermiten su despliegue de forma programaacutetica Aprovechando estas facilidadesen este proyecto se va a aproximar la escalabilidad con el sucesivo desplieguede la infraestructura de forma automaacutetica se monitorizan los equipos y si sedetecta una maacutequina excesivamente cargada se aumenta el nuacutemero de equiposen la plantilla y se vuelve a desplegar
23httpsgithubcomAntonioAlfrzCloud-Orchestrators
43
En este proyecto se han disentildeado las plantillas para desplegar la arquitec-tura necesaria tanto de Nomad como de DCOS En el caso de la primera eldespliegue es maacutes descriptivo ya que incluye maacutequinas virtuales grupos de se-guridad redes En el caso de DCOS Azure cuenta con un servicio especiacuteficopara clusters gobernados por DCOS denominado Azure Container Service queincluye los componentes necesarios y la instalacioacuten ya realizada
72 Implementacioacuten
En primer lugar para monitorizar el estado de los equipos se va a usar laherramienta Nagios un sistema que permite controlar el estado del hardwarey los servicios de un equipo Se trata de una herramienta muy completa de laque se va a usar su capacidad para ejecutar comandos (plugins) en los nodospara detectar picos de carga generar alertas y ejecutar programas para estoseventos
Se ha desplegado una maacutequina virtual con esta herramienta en ambos siste-mas y se ha instalado una extensioacuten de Nagios (Nagios Remote Plugin Executor)en todos los nodos que permite ejecutar comprobaciones remotamente en con-creto para esta prueba de concepto medir el nivel de saturacioacuten de la unidadcentral de procesamiento (CPU por sus siglas del ingleacutes) Cuando sucede uncambio de estado de una maacutequina esto es cuando este paraacutemetro supera el liacutemi-te definido por el operador Nagios permite actuar en consecuencia ejecutandoprogramas por ello se ha desarrollado un script que ejecuta lo siguiente
Un programa desarrollado en Python con el SDK de Azure que modificalas plantillas y despliega los recursos
Un guioacuten de Ansible para instalar todos los componentes necesarios en lasnuevas maacutequinas y arrancar de nuevo el cluster y las aplicaciones
44
8 Resultados y conclusiones
En este uacuteltimo apartado se da una visioacuten global del proyecto asiacute como a lasconclusiones maacutes importantes a las que se ha llegado y posibles temas futurosde desarrollo
81 Comparacioacuten
Ambas herramientas ofrecen las funcionalidades para gestionar los recursoseficientemente ofreciendo a los desarrolladores una plataforma donde desplegarsus aplicaciones de forma distribuida independientemente de los equipos fiacutesicosy el hardware que las soporten
DCOS es una herramienta que en un comienzo fue privativa pero cuyos res-ponsables la empresa Mesosphere decidieron publicar una versioacuten de coacutedigoEacutesta nos permite gestionar un cluster de una forma sencilla y usable ademaacutes decomplementarlo con otras herramientas como el balanceador de carga integradoo la autenticacioacuten de usuarios ademaacutes estaacute basada en Apache Mesos un pro-yecto de relativa madurez y con el soporte de la Apache Software FoundationDe forma resumida DCOS ofrece muchas posibilidades y servicios a cambiode una arquitectura e instalacioacuten maacutes compleja
Por su parte HashiCorp con menor tiempo de desarrollo ha conseguidouna herramienta muy sencilla de desplegar que ademaacutes cumple con todas lasfuncionalidades baacutesicas ejecutando un simple binario en cada nodo se puededesplegar un gestor de clusters totalmente funcional Sin embargo no cuentacon todas las posibilidades de Mesos (Nomad cuenta con menos controladoresque entornos posibles de Mesos) ni con los antildeadidos de DCOS lo que implicael uso de otras herramientas para complementar el servicio (Consul HAProxy)
De entre las dificultades encontradas al usar estas herramientas y desplegaraplicaciones sobre ellas se puede destacar la depuracioacuten en ocasiones se desco-noce si un error viene de la propia herramienta de la aplicacioacuten desplegada o delequipo fiacutesico si no se cuenta con un sistema de procesamiento de registro unose puede encontrar con muacuteltiples terminales abiertas inspeccionando numerososficheros de registro buscando posibles errores Ademaacutes no dejan de ser solucio-nes que para usar eficientemente se debe conocer parte de su funcionamientoy sintaxis a la hora de describir la tareas lo que supone un esfuerzo antildeadido yaque cada una tiene sus particularidades y liacutemites
45
82 Conclusiones
En una sociedad cada vez maacutes digital las empresas deben adaptarse a unmercado cuya demanda de contenido no deja de crecer Las nuevas arquitecturascomo microservicios asiacute como la gran cantidad de datos generada implica queuna mejor gestioacuten de los recursos y la rapidez para desplegar o escalar solucionesdando valor al cliente lo maacutes raacutepido posible es uno de los objetivos de todas lasempresas de base tecnoloacutegica
Las ventajas que ofrecen los planificadores con aplicaciones distribuidas sonnumerosas sin ir maacutes lejos empresas tan punteras como Google llevan maacutesde 10 antildeos orquestando contenedores24 Por un lado permiten aumentar elrendimiento de los equipos propios y por otro implementar un servicio comoplataforma para despliegues distribuidos sobre cualquier conjunto hardware deesta forma se provee un servicio similar al de la nube puacuteblica pero con laprincipal diferencia de que se elimina la independencia con el proveedor (vendorlock-in) esto es las aplicaciones no tienen limitaciones impuestas por eacuteste talescomo lenguaje de programacioacuten o herramientas y permite despliegues hiacutebridosentre recursos propios y la nube
83 Objetivos conseguidos
Implementacioacuten de los planificadores propuestos en la nube Se ha en-tendido y detallado el funcionamiento de estas herramientas y se hanimplementado en el servicio de infraestructura de Microsoft Azure
Despliegue de aplicaciones y servicios distribuidos Servicios que se usanactualmente en la industria del desarrollo software asiacute como una aplica-cioacuten web con una arquitectura moderna han sido desplegados de formadistribuida en los equipos cumpliendo con la funcionalidad esperada ade-maacutes de consiguiendo una alta disponibilidad
Aproximacioacuten de arquitectura escalable Se ha hecho una aproximacioacutende infraestructura escalable de forma que sea parcialmente extrapolable aotros proveedores
24httpwwwnextplatformcom20160322decade-container-control-google
46
84 Liacuteneas de investigacioacuten
Siguiendo con la materia de este proyecto se presentan posibles liacuteneas deinvestigacioacuten
Analizar el despliegue con estas herramientas de aplicaciones de Big Datay comparar la eficiencia con respecto a soluciones especializadas
Analizar el rendimiento de los algoritmos de planificacioacuten antes pruebasde estreacutes y situaciones de alta contienda
Comparar el uso de estas herramientas con las praacutecticas actuales de laindustria o implementacioacuten en un sistema de produccioacuten real
47
Referencias
[1] LA Barroso y U Houmllzle laquoThe Datacenter as a Computer An Introduc-tion to the Design of Warehouse-Scale Machinesraquo En Morgan amp ClaypoolPublishers ()
[2] Systems Research Group ndash NetOS (University of Cambridge) The evolu-tion of cluster scheduler architectures 2016 url httpswwwclcamacukresearchsrgnetoscamsasblog2016-03-09-scheduler-architectureshtml
[3] A Das I Gupta y A Motivala SWIM Scalable Weakly-consistent Infection-style Process Group Membership Protocol Inf teacutec Dept of ComputerScience Cornell University url https www cs cornell edu ~asdasresearchdsn02-swimpdf
[4] D Dubhashi y A Das Mastering Mesos PACKT Publishing mayo de2016
[5] The Apache Software Foundation Apache Mesos documentation urlhttpsmesosapacheorg
[6] David Greenberg Building Applications on Mesos OrsquoReilly Media 2016[7] Armand Grillet Comparison of Container Schedulers Inf teacutec Technische
Universitaumlt Berlin[8] HashiCorp Consul documentation url httpswwwconsulio[9] HashiCorp Nomad documentation url httpsdcosio[10] Dan C Marinescu Cloud computing theory and practice Morgan Kauf-
mann 2013[11] Mesosphere DCOS documentation url httpswwwnomadproject
io[12] Microsoft Azure documentation url httpsazuremicrosoftcom
es-esdocumentation[13] D Ongaro y J Ousterhout In Search of an Understandable Consensus
Algorithm Inf teacutec Stanford University url httpsraftgithubioraftpdf
[14] Fei Teng laquoRessource allocation and schelduling models for cloud compu-tingraquo Tesis de mtriacutea Ecole Centrale Paris 2011
[15] A Williams y col Automation and Orchestration with Docker and Contai-ners A Comprehensive Overview of the Docker and Container Ecosystem3 The New Stack 2016
48
- Resumen
- Summary
- Iacutendice de figuras
- Introduccioacuten y objetivos
-
- Contexto
- Objetivos
- Estructura del documento
-
- Cloud Computing
- Nuevas cargas de trabajo
- Gestioacuten de recursos Planificadores
-
- Sistemas distribuidos
-
- Clasificacioacuten
-
- Herramientas
-
- DCOS
-
- Apache Mesos
- Ejemplos de uso
-
- Nomad
-
- Protocolo de consenso Raft
- Protocolo gossip SWIM
- Planificacioacuten
-
- Casos de uso y despliegue
-
- Aplicacioacuten Web
-
- DCOS
- Nomad
-
- Servicio de integracioacuten continua
-
- DevOps
- Integracioacuten Continua
- Jenkins con Nomad
- Jenkins con DCOS
-
- Escalando la infraestructura
-
- Disentildeo
- Implementacioacuten
-
- Resultados y conclusiones
-
- Comparacioacuten
- Conclusiones
- Objetivos conseguidos
- Liacuteneas de investigacioacuten
-
Trabajo Fin de Grado
Tiacutetulo Disentildeo y despliegue de servicios de alta disponibilidad enla nube usando herramientas de coacutedigo abierto
Title Design and deployment of high availability services in thecloud using open source tools
Autor Antonio Juliaacuten Alfeacuterez Zamora
Tutor D Joaquiacuten Luciano Salvachuacutea Rodriacuteguez
Departamento Departamento de Ingenieriacutea de Sistemas Telemaacuteticos
Tribunal
Presidente D Juan Quemada Vives
Vocal D Santiago Pavoacuten Goacutemez
Secretario D Gabriel Huecas Fernaacutendez-Toribio
Suplente D David Fernaacutendez Cambronero
Fecha de lectura
Calificacioacuten
i
ii
Resumen
Las empresas punteras en tecnologiacutea e innovacioacuten cuentan con numerososrecursos de computacioacuten para llevar a cabo los diversos servicios que sustentanel proceso de negocio En general a estos equipos se les asignan de forma es-taacutetica las distintas tareas lo que conlleva un uso ineficiente al no distribuirseacorde con la carga de trabajo ademaacutes del trabajo de mantenimiento que con-lleva De entre las responsabilidades de los profesionales de las tecnologiacuteas dela informacioacuten estaacute gestionar eficientemente estos recursos asiacute como garantizarla disponibilidad de estos servicios atendiendo a las diferentes demandas decapacidad
La motivacioacuten de este trabajo surge de la oportunidad de desplegar las di-ferentes tareas o servicios de una forma maacutes eficiente gracias a la evolucioacuten entecnologiacuteas como la virtualizacioacuten almacenamiento distribuido o redes definidaspor software asiacute como la mejora y el abaratamiento de los enlaces de comunica-ciones que suponen un cambio de enfoque a la hora de disentildear la infraestructurade los sistemas de informacioacuten
En particular en este proyecto se va a entrar en detalle en herramientas cuyoobjetivo es optimizar los recursos y ademaacutes dar ciertas garantiacuteas de escalabili-dad disponibilidad y tolerancia a fallos De entre las soluciones que existen enla industria hemos seleccionado dos de coacutedigo abierto que alcanzan los objeti-vos definidos DCOS desarrollada por la empresa Mesosphere y basado en elproyecto Apache Mesos y Nomad creada por Hashicorp
En primer lugar se realizaraacute un anaacutelisis del funcionamiento de estas tecno-logiacuteas al que posteriormente seguiraacute el despliegue de casos de uso en la nube yfinalmente las conclusiones a las que se han llegado comparando el rendimientode ambas Con ello se pretende dar una perspectiva de la funcionalidad de estastecnologiacuteas y como encajan en la perspectiva actual dentro de las tecnologiacuteas dela informacioacuten
Palabras clave Cluacutester Gestor de recursos Planificador Compu-tacioacuten en la nube Apache Mesos HashiCorp Nomad MesosphereDCOS
iii
iv
Summary
Tech-savvy companies have a large amount of computational resources tohandle the services that support the business process Typically tasks are al-located in these computers in a static way which is inefficient due to the factthat they are not distributed according to the workload besides involving fur-ther maintenance work Among the responsibilities of Information Technologyprofessionals is efficiently managing these resources and providing some guaran-tees of availability of those services according to the different capacity demands
The motivation of this project comes from the opportunity of efficiently dis-tributing the different tasks or services of an enterprise thanks to the evolutionof technologies such as virtualization distributed storage or software defined net-works but also with the improvement and cost reduction of the communicationlinks a potential turning point in the approach of designing IT infrastructures
This project goes into more detail on tools which pursue resource optim-ization availability scalability and fault tolerance of services Amongst theexisting solutions in the industry two open source projects have been chosenboth achieving the predefined objectives DCOS developed by the companyMesosphere and based on the Apache Mesos project and Nomad developed byHashiCorp
Firstly the internals of these two technologies will be studied followed by adeployment of use cases in both of them in the cloud Lastly the conclusionsreached comparing their performance will be described By this it is intendedto provide a perspective of the functionality of these tools and how they fit inthe nowadays perspective on Information Technology
Keywords Cluster Resource Manager Cluster Scheduler CloudComputing Apache Mesos HashiCorp Nomad Mesosphere DCOS
v
vi
Iacutendice
Resumen III
Summary V
Iacutendice de figuras IX
1 Introduccioacuten y objetivos 1
11 Contexto 1
12 Objetivos 2
13 Estructura del documento 2
2 Cloud Computing 3
3 Nuevas cargas de trabajo 5
4 Gestioacuten de recursos Planificadores 8
41 Sistemas distribuidos 8
411 Clasificacioacuten 10
5 Herramientas 13
51 DCOS 14
511 Apache Mesos 15
512 Ejemplos de uso 18
52 Nomad 19
521 Protocolo de consenso Raft 20
vii
522 Protocolo gossip SWIM 23
523 Planificacioacuten 24
6 Casos de uso y despliegue 27
61 Aplicacioacuten Web 27
611 DCOS 28
612 Nomad 33
62 Servicio de integracioacuten continua 40
621 DevOps 40
622 Integracioacuten Continua 40
623 Jenkins con Nomad 42
624 Jenkins con DCOS 42
7 Escalando la infraestructura 43
71 Disentildeo 43
72 Implementacioacuten 44
8 Resultados y conclusiones 45
81 Comparacioacuten 45
82 Conclusiones 46
83 Objetivos conseguidos 46
84 Liacuteneas de investigacioacuten 47
viii
Iacutendice de figuras
1 Comparacioacuten Centro de datos - Computacioacuten en la nube 4
2 Arquitectura Docker 6
3 Planificador monoliacutetico 11
4 Planificador de dos niveles 11
5 Planificador de estado compartido 12
6 Planificador distribuido 12
7 Arquitectura DCOS 14
8 Servicios DCOS 15
9 Arquitectura de Apache Mesos 17
10 Arquitectura multi-regioacuten en Nomad 20
11 Equipos sin consenso ejecutando el protocolo RAFT 21
12 Un equipo pasa a estado candidato (RAFT) 22
13 Cambio en un registro (RAFT) 22
14 Aprobacioacuten del resto de equipos (RAFT) 23
15 Diagrama de tiempo del protocolo SWIM 24
16 Procedimiento de asignacioacuten en Nomad 25
17 Arquitectura aplicacioacuten web 28
18 Infraestructura en Azure 29
19 Arquitectura de la aplicacioacuten web en DCOS 32
20 Despliegue en Azure de Nomad+Consul 35
ix
1 Introduccioacuten y objetivos
11 Contexto
Las tecnologiacuteas de la informacioacuten y la comunicacioacuten estaacuten suponiendo uncambio draacutestico en la sociedad en 2007 comenzaron a aparecer los teleacutefonosinteligentes tal y como los conocemos y nueves antildeos despueacutes se empieza a con-cebir la idea de dar conectividad a todo dispositivo electroacutenico movimiento queha tomado el nombre de Internet de las cosas Para hacerse una idea de la rapi-dez y magnitud de esta evolucioacuten la consultora Excelacom1 ha estimado que enun minuto se realizan 24 millones de buacutesquedas en Google o se ven 278 millonesde viacutedeos en Youtube En una eacutepoca en la que los recursos tecnoloacutegicos crecenexponencialmente y los usuarios demandan mayor contenido y movilidad nocabe duda que las empresas deben adaptarse lo maacutes raacutepidamente posible a esteproceso de digitalizacioacuten movidas por las nuevas necesidades de las personas
Dado el gran volumen de informacioacuten a lo largo de estos antildeos la compu-tacioacuten y el almacenamiento estaacuten pasando de clientes locales a concentrarse engrandes centros de datos una tendencia que Google ha denominado ldquoWarehouse-scale computingrdquo en 2009[1] Este movimiento hacia la computacioacuten desde ser-vidor no solo viene de la necesidad de mejorar la experiencia de los usuariossino tambieacuten de facilitar la gestioacuten y configuracioacuten de los recursos asiacute como laubicuidad de acceso que permite
En 2006 Amazon lanza Amazon Web Services siendo uno de los pionerosen el mercado de los recursos virtuales ofreciendo capacidad de computacioacutencon un coste proporcional exclusivamente a los recursos utilizados Todo ellocambioacute la perspectiva de los modelos tradicionales de TI a la conocida comocomputacioacuten en la nube recursos informaacuteticos que antes suponiacutean barrerasde entrada en ciertos mercados han pasado a ser condicioacuten necesaria para laconstante evolucioacuten de la tecnologiacutea y la sociedad De hecho Cisco estima quepara el antildeo 2019 maacutes del 86 de las cargas de trabajo seraacuten procesadas porcentros de datos en la nube2
1httpwwwexcelacomcomresourcesblog2016-update-what-happens-in-one-internet-minute2httpwwwciscocomcenussolutionscollateralservice-provider
global-cloud-index-gciCloud_Index_White_Paperpdf
1
12 Objetivos
El propoacutesito de este proyecto es estudiar la viabilidad del uso de planifica-dores de recursos para aumentar la eficiencia de eacutestos y facilitar al desarrolladorel despliegue de aplicaciones de forma distribuida y asiacute ofrecer un servicio ca-racterizado por una alta disponibilidad y escalabilidad
A lo largo de este trabajo se han usado algunas de las herramientas quese estaacuten comenzando a desarrollar para hacer frente a este nuevo enfoque degestioacuten de infraestructuras de las tecnologiacuteas de la informacioacuten (en adelanteinfraestructuras TI) realizando pruebas de concepto sobre cada una de ellas
13 Estructura del documento
A continuacioacuten se detalla las secciones que componen este trabajo La es-tructura queda como sigue
Cloud computing Se entra en detalle en este nuevo modelo de negocio queha originado nuevos enfoques y disentildeos de las infraestructuras TI dentrode las organizaciones
Nuevas cargas de trabajo Se explican algunas tecnologiacuteas representativasque estaacuten suponiendo un desafiacuteo para los profesionales de TI a la horade planificar los recursos y que se ven beneficiadas por entornos de tipocloud
Gestioacuten de recursos Planificadores Estado del arte de las tecnologiacuteas degestioacuten de clusters y planificacioacuten de recursos
Herramientas Descripcioacuten detallada del funcionamiento y arquitectura de lasherramientas usadas a lo largo del proyecto
Casos de uso y despliegue Se describe el proceso de implementacioacuten de unaaplicacioacuten web y un servicio de integracioacuten continua con el software pro-puesto
Escalando la infraestructura Se propone un procedimiento con cierta inde-pendencia del proveedor cloud
Resultados y conclusiones Resume las ideas y hechos a los que se ha llegadoademaacutes de introducir liacuteneas de investigacioacuten futuras
2
2 Cloud Computing
El NIST (National Insitute of Standards and Technology) define este con-cepto como un modelo que permite un acceso ubicuo y bajo demanda de formaremota a un conjunto compartido de recursos de computacioacuten que pueden seraprovisionados y liberados con unos miacutenimos esfuerzos de gestioacuten por parte delproveedor del servicio3
Clasificacioacuten
La computacioacuten en la nube abarca una amplia variedad de servicios y enfo-ques por lo que en primer lugar se va a dar una clasificacioacuten para posterior-mente entrar maacutes en detalle Existen distintos modelos de nube atendiendo a lagobernabilidad de la infraestructura seguacuten el NIST
Nubes puacuteblicas Los servicios y recursos son ofertados de forma puacuteblica yson provistos por una organizacioacuten que los comercializa bajo demanda
Nube privada Los recursos son gestionados por una uacutenica organizacioacutenpara su propio uso
Nube comunitaria En este caso la infraestructura es administrada por unconjunto de organizaciones con objetivos comunes
Nube hiacutebrida Una combinacioacuten de las anteriores
A su vez los distintos servicios que ofrece se pueden clasificar atendiendo algrado de control del usuario
Servicios de software (Software as a Service SaaS) El proveedor se encargade toda la gestioacuten de la infraestructura y oferta aplicaciones a las cuales elcliente puede acceder de forma ubicua a traveacutes de diversos clientes comoun navegador web Por ejemplo Office 365 o Google docs
Servicios de plataforma (Platform as a Service PaaS) Modelo de distribu-cioacuten que ofrece la capacidad de desplegar aplicaciones desarrolladas por elcliente usando las herramientas y lenguajes de programacioacuten soportadaspor el proveedor pero sin la posibilidad de gestionar los recursos consu-midos En este caso el cliente solo tiene control sobre la propia aplicacioacuteny algunas configuraciones del entorno Es el caso de Heroku o Google AppEngine
3httpnvlpubsnistgovnistpubsLegacySPnistspecialpublication800-145pdf
3
Servicios de infraestructura (Infrastructure as a Service IaaS) Se ofertanrecursos de computacioacuten puros como procesamiento o almacenamientomediante una plataforma de virtualizacioacuten El cliente puede controlar elsistema operativo componentes de red y aplicaciones
Figura 1 Comparacioacuten Centro de datos - Computacioacuten en la nubeFuente httpsad-hocnet
De entre las numerosas ventajas que ofrece la computacioacuten en la nube se puededestacar su flexibilidad ya que permite aprovisionar recursos y adaptarlos deacuerdo a la demanda reduce el capital inmovilizado y su amortizacioacuten laubicuidad que permite su consumo desde cualquier parte con conexioacuten a la redy la seguridad y fiabilidad que ofrece el proveedor que normalmente cuenta conrecursos geograacuteficamente distribuidos frente a la gestioacuten y mantenimiento derecursos propios
4
3 Nuevas cargas de trabajo
Las organizaciones que cuentan con sus propios infraestructuras TI han co-menzado a adoptar un enfoque de nube privada para gestionar las tareas ofunciones informaacuteticas sobre las que se sustentan el negocio ya que una es-tructura virtualizada puede ofrecer ventajas con respecto a las adaptaciones decentros de datos tradicionales en los aacutembitos de rendimiento escalabilidad eincluso seguridad4
A su vez se han desarrollado nuevas tecnologiacuteas que suponen cargas detrabajo dinaacutemicas y con gran intensidad de consumo de datos para las empresasque se ven beneficiadas al desplegarlas en recursos virtualizados
Big data
Con la creciente aceptacioacuten de las tecnologiacuteas TIC por parte de la sociedadla cantidad de datos generados en la red es ingente Las profesionales de TI tienecomo objetivo extraer valor de eacutestos para por ejemplo prever las tendencias delmercado Sin embargo este incremento exponencial hace que su procesamientoy almacenamiento requiera de un sistema con gran escalabilidad dado el hechode que una sola maacutequina no puede proveer de la capacidad necesaria
Integracioacuten continua
Modelo informaacutetico que consiste en hacer integraciones automaacuteticas de unproyecto con cualquier cambio en el coacutedigo con el objetivo de detectar fallosde forma temprana Esto implica la compilacioacuten del coacutedigo y su ejecucioacuten enun entorno de pruebas automaacuteticamente un proceso que mediante tecnologiacuteasde virtualizacioacuten permiten simular entornos con eficiencia y rapidez Su imple-mentacioacuten en sistemas distribuidos permite tanto una mejor planificacioacuten comoun mejor rendimiento de los recursos
Arquitectura de microservicios
Enfoque para desarrollar aplicaciones software como un conjunto de serviciosautoacutenomos que se comunican entre siacute a diferencia de aproximaciones monoliacuteti-cas donde la loacutegica del servicio estaacute desarrollada como una unidad Un sistemadistribuido permite el despliegue de los componentes en distintas maacutequinas loque mejora tanto su escalabilidad como la tolerancia a fallos
4httpswwwakamaicomesesresourcespublic-private-cloudjsp
5
Docker
Proyecto de coacutedigo abierto que facilita y automatiza el despliegue de aplica-ciones al encapsular el entorno de trabajo en contenedores Linux una tecnologiacuteaque permite a un sistema fiacutesico ejecutar muacuteltiples instancias de sistemas opera-tivos aislados mediante entornos virtuales con sus propios espacios de procesosy redes pero compartiendo el nuacutecleo (kernel) con el equipo anfitrioacuten
En la figura 2 se compara la pila de una virtualizacioacuten tradicional con res-pecto a los contenedores no se simula el sistema operativo por lo que el procesoes mucho maacutes ligero
Docker se caracteriza por
Autosuficiencia Los contenedores cuentan con las libreriacuteas y configuracio-nes necesarias para ejecutarse de manera autoacutenoma al compartir el nuacutecleo
Portabilidad El hecho de que sean autosuficientes implica que es inde-pendiente del host es decir se puede desplegar en cualquier equipo quesoporte esta tecnologiacutea
Tamantildeo El peso de un contenedor es sustancialmente inferior a otrastecnologiacuteas de virtualizacioacuten
Figura 2 Arquitectura DockerFuente httpsdockercom
6
Los componentes fundamentales de esta herramienta son
Imaacutegenes Describen el entorno de base sobre el que ejecutar el contene-dor por ejemplo la imagen del sistema operativo Ubuntu Sobre eacutesta seconstruyen las aplicaciones particulares del usuario dando lugar a otraimagen
Contenedores Se crean a partir de las imaacutegenes y comprenden todo aquellonecesario para arrancar la aplicacioacuten decir su entorno de ejecucioacuten
bull Voluacutemenes Encargados de gestionar la persistencia de datos e inde-pendientes del ciclo de vida del contenedor
Registros Pueden ser puacuteblicos o privados y almacenan las imaacutegenes elregistro puacuteblico oficial de Docker es Docker Hub
Dadas estas caracteriacutesticas los profesionales TI estaacuten comenzando a adoptarDocker ya que facilita tanto los despliegues como el trabajo compartido en dis-tintos entornos Sin embargo esto requiere de un software que permita desplegarlos distintos contenedores de forma que puedan trabajar en conjunto procesoque se ha denominado orquestacioacuten de contenedores
7
4 Gestioacuten de recursos Planificadores
Para sacar el maacuteximo provecho a las tecnologiacuteas anteriormente descritaslo ideal es desplegarlas en sistemas distribuidos sin embargo esto aumenta lacomplejidad del propio despliegue asiacute como la necesidad de software especiali-zado para ello Se necesitan algoritmos de planificacioacuten que permitan obtener elmaacuteximo rendimiento de los recursos por un lado y dar ciertas garantiacuteas de quetodas las tareas y procesos se van a ejecuta por otro
41 Sistemas distribuidos
En primer lugar se definen los sistemas distribuidos o clusters como unconjunto de ordenadores conectados entre siacute cuyo objetivo es trabajar como unauacutenica instancia de gran capacidad5
Su clasificacioacuten variacutea de acuerdo a cada autor pero en general se puedendividir seguacuten su objetivo en alto rendimiento aquellos cuyo objetivos es proveerde gran capacidad de coacutemputo gracias al conjunto de los nodos y alta disponi-bilidad con los cuales se busca la fiabilidad del sistema mediante redundanciayo balanceo de carga
El intereacutes de este proyecto recae en los uacuteltimos ya que el objetivo es porun lado ofrecer al desarrollador un entorno donde desplegar sus aplicaciones deforma distribuida y por otro maximizar el rendimiento de los recursos
De forma general las caracteriacutesticas que se buscan son las siguientes
Elasticidad Adaptacioacuten a cargas dinaacutemicas de trabajo aumentando (o dis-minuyendo) recursos de manera automaacutetica de tal forma que la utilizacioacutensea lo maacutes cercana a la demanda
Disponibilidad Capacidad de un sistema para mantener el servicio fun-cional
Tolerancia a fallos Recuperacioacuten del servicio ante el fallo de un compo-nente
Balanceo de carga Compartir las tareas entre las diferentes maacutequinasredundadas evitando asiacute puntos de uacutenico fallo
5httpsenwikipediaorgwikiComputer_cluster
8
Los programas que se implementan en entornos distribuidos se caracterizanpor ejecutarse de forma concurrente en equipos independientes estar conectadospor una red que introduce fallos aleatorios y no compartir memoria ni reloj Estoimplica entre otras cosas que
Los nodos soacutelo tienen un acceso raacutepido a su memoria local por lo quecualquier informacioacuten relativa al estado global puede ser potencialmenteerroacutenea
Las maacutequinas pueden sufrir caiacutedas de forma aleatoria
El intercambio de informacioacuten puede fallar ya sea por error en transmisioacuteno por caiacuteda de los nodos
Estas dificultades se ponen de manifiesto en el teorema de CAP en cienciasde la computacioacuten el teorema de CAP que lanzado inicialmente como conjetu-ra en el antildeo 2000 por Eric Brewer (motivo por el cual al teorema se le conoceformalmente como teorema de Brewer) y posteriormente demostrado en el antildeo20026 establece que es imposible para un sistema de coacutemputo distribuido ga-rantizar simultaacuteneamente dos de las tres propiedades siguientes
Consistencia (Consistency) es decir que todos los nodos vean la mismainformacioacuten al mismo tiempo Se busca que un cambio en el sistema soacutelose ejecute satisfactoriamente si y soacutelo si se efectuacutea a todos las maacutequinasde tal forma que los datos entre ellos nunca difieren y la respuesta a unapeticioacuten sea la misma independientemente del nodo que la atienda
Disponibilidad (Availability) esto es la garantiacutea de que toda peticioacuten debeobtener una respuesta (servicio funcional) aunque exista inconsistenciaentre nodos
Tolerancia al particionado (Partition Tolerance) es decir que el sistemasiga funcionado a pesar de un fallo en la comunicacioacuten entre los equipos
Por todo lo expresado anteriormente conseguir un sistema distribuido capazde ofrecer procesamiento de forma transparente implica una arquitectura TIcompleja Se requieren de subsistemas y herramientas que permitan la cohesioacutenentre todos los nodos
Gestor de los recursos de las diferentes maacutequinas
Monitorizacioacuten tanto de los servicios activos como de la funcionalidad delsistema ademaacutes de poliacuteticas para recuperacioacuten de fallo
Protocolos de consenso que permitan a los nodos ser consistentes con elestado global del cluster
6urlhttpsgroupscsailmitedutdspapersGilbertBrewer2pdf
9
Herramientas de descubrimiento de servicios que permita la comunicacioacutenentre tareas distribuidas
Planificadores Encargados de distribuir las tareas y procesos en las dife-rentes maacutequinas asignaacutendole parte de su capacidad
Los planificadores del ingleacutes cluster schedulers son un componente funda-mental por lo que vamos a entrar un poco maacutes en detalle en ellos
Planificadores (Cluster Schedulers)
Es el software encargado de monitorizar los recursos usados por cada maacute-quina perteneciente a un cluster y distribuir la carga de trabajo entre ellas deacuerdo a un poliacutetica o reglas
Este tipo de herramientas comparten cierta terminologiacutea que es relevantedefinir
Tarea Unidad de trabajo computacional comprendida por una secuenciade instrucciones datos de entrada y recursos asociados Por ejemplo laejecucioacuten de un comando o el arranque de una base de datos
Nodo Cualquier maacutequina integrante de un cluster En una arquitecturamaestro-esclavo se definen dos roles
bull Cliente Agente Esclavo Aquellos ordenadores que se encargan deejecutar las tareas
bull Maestro Servidor Su objetivo es mantener el estado del cluster ygestionar sus recursos
411 Clasificacioacuten
A lo largo de los uacuteltimos antildeos se han desarrollado diferentes tipos de plani-ficadores[2]
Monoliacutetico
Un solo planificador que se encarga de distribuir todas las tareas entran-tes La mayoriacutea de los planificadores en computacioacuten de alto rendimiento asiacutecomo Borg desarrollado por Google son de este tipo En la figura 3 se pue-de observar de forma graacutefica el procedimiento siendo las cajas grises maacutequinaspertenecientes al cluster y los ciacuterculos las tareas a asignar
10
Figura 3 Planificador monoliacuteticoFuente httpswwwclcamacuk
Planificacioacuten de dos niveles
La mayoriacutea de los clusters ejecutan aplicaciones con distintas necesidadesdesde procesos casi instantaacuteneos hasta servicios persistenteslo que implica dis-tintas necesidades de recursos
Por ello la planificacioacuten a dos niveles distingue dos funciones la gestioacutende recursos (gestor) y la disposicioacuten de las tareas (planificador) Cada serviciotiene su propio planificador de tal manera que el gestor les ldquoofertardquo recursosde acuerdo a una poliacutetica y los planificadores se encargan de escoger la maacutesadecuada Esto permite que el proceso de distribucioacuten sea maacutes acorde con lasnecesidades de los diferentes servicios Apache Mesos que detallaremos maacutesadelante sigue este esquema
Como desventaja cabriacutea sentildealar que esta programacioacuten implica que los pla-nificadores pierden la vista general de la infraestructura y las tareas soacutelo puedenejecutarse con los recursos que les son ofrecidos lo que dificulta la implementa-cioacuten de prioridades de ejecucioacuten de tareas entre otras
Figura 4 Planificador de dos niveles
11
Planificacioacuten de estado compartido
Muacuteltiples reacuteplicas del estado del cluster se actualizan independientementepara cada planificador como se observa en la figura 5 cuando sucede un cambiode forma local el planificador se encarga de informar al resto
Ejemplo de este tipo son Omega la evolucioacuten de Borg por parte de GoogleMicrosoft Apollo y Nomad que usaremos para los casos de uso
De entre las desventajas se puede destacar el hecho de que en general losnodos trabajan con informacioacuten desactualizada lo que conlleva una degradacioacutendel rendimiento en situaciones de alta contienda
Figura 5 Planificador de estado compartido
Planificacioacuten distribuida
En este caso no existe coordinacioacuten entre los distintos planificadores Cadauno de ellos funciona con su propia vista del cluster Las tareas pueden serorganizadas por cualquiera de ellos y desplegadas en cualquier parte del clusteren base a la aleatoriedad y multiplexacioacuten estadiacutestica de los flujos de trabajosin ninguacuten control central
Figura 6 Planificador distribuido
12
5 Herramientas
En la industria comienzan a aparecer soluciones software de coacutedigo abiertoque aglutinan los servicios necesarios para gestionar la infraestructura TI de ma-nera maacutes eficaz El objetivo es doble se busca facilitar la gestioacuten de los recursosde computacioacuten para organizaciones con instalaciones propias mediante su usocon un enfoque cloud esto es desplegar aplicaciones a traveacutes de un conjuntode ordenadores de forma transparente y sin tener en cuenta la infraestructurasubyacente o aprovechar el maacuteximo rendimiento de la infraestructura de losproveedores cloud puacuteblicos de forma que se tiene el maacuteximo control sobre eacutestapero no se depende de las soluciones propietarias permitiendo asiacute despliegueshiacutebridos
Entre estas herramientas se pueden destacar
OpenStack Proyecto desarrollado por la fundacioacuten del mismo nombre paraproporcionar servicios de infraestructuras (IaaS) basado en componentesque se comunican a traveacutes de APIs El componente Magnum incluye mo-tores de orquestacioacuten de contenedores
Kubernetes Sistema de orquestacioacuten de contenedores Docker creado por Goo-gle
CoreOs Sistema operativo basado en Linux disentildeado para despliegues distri-buidos sobre contenedores incluyendo mecanismos de descubrimiento deservicio y comparticioacuten de configuracioacuten
Docker Swarm Herramienta nativa de orquestacioacuten de contenedores Docker
YARN Entorno de gestioacuten de recursos y aplicaciones distribuidas de Hadoopuna libreriacutea software de procesamiento de grandes conjuntos de datos
Como podemos observar existe un gran rango de opciones para gestionar lainfraestructura desde un bajo nivel como puede ser OpenStack hasta Kuberne-tes o Docker Swarm que ofrecen exclusivamente orquestacioacuten de contenedores
En este trabajo se ha optado por Mesosphere DCOS y HashiCorp Nomadque se encuentran en el teacutermino medio su objetivo es proporcionar serviciosde plataforma que permitan la coexistencia dediferentes cargas de trabajo en elcluster
13
51 DCOS
DCOS es un proyecto de coacutedigo abierto7 creado y desarrollado por la empre-sa Mesosphere Se describe como un sistema operativo distribuido que abstraelos recursos de un cluster (capacidad de procesamiento memoria) permite lagestioacuten de muacuteltiples ordenadores de forma transparente y simplifica la instala-cioacuten de aplicaciones distribuidas
Su arquitectura se puede comparar a la de Linux en teacuterminos de nuacutecleo(kernel) y espacio de usuario El primero consta de recursos protegidos a losque no puede acceder el usuario e involucra operaciones de bajo nivel comoasignacioacuten de recursos o aislamiento de procesos En el espacio de usuario seejecutan las aplicaciones y servicios de maacutes alto nivel
Siguiendo con este siacutemil el nuacutecleo de DCOS estaacute basado en Apache Mesosque se explicaraacute en un apartado posterior y el espacio de usuario que estaacute com-prendido por los componentes del sistema esto es las diferentes herramientasque en conjunto conforman DCOS y los servicios encargados de planificar yejecutar las aplicaciones y tareas del usuario
Figura 7 Arquitectura DCOSFuente httpsdcosio
De entre los componentes que conforman DCOS destacan
Admin Router Balanceador de carga central basado en NGINX que dis-pone un proxy entre todos los servicios en el puerto 80 permitiendo sugestioacuten mediante la interfaz graacutefica Ademaacutes se encarga de la autenticacioacutenpara acceder al panel de administracioacuten
Cosmos Gestor de paquetes de las aplicaciones
Diagnostics Se ejecuta en todos los nodos y se encarga de monitorizar elestado de los daemons que sustentan DCOS
7Desde abril de 2016 httpsmesospherecomblog20160419open-source-dcos
14
Exhibitor Gestiona y automatiza el despliegue de ZooKeper la herra-mienta que provee de configuracioacuten centralizada y registro de nombres
Marathon Equivale al proceso init de los sistemas tipo Unix esto es elprimer proceso en ejecucioacuten tras la carga del kernel y que genera los demaacutesprocesos Se encarga de arrancar y monitorizar las aplicaciones y servicios
Mesos-DNS Servicio de DNS interno que define el dominio mesos pa-ra nodos y tareas en el cluster es decir permite resolver nombres conindependencia de la direccioacuten fiacutesica
Minuteman Balanceador de carga integrado a nivel TCPUDP disponiblepara las propias aplicaciones
Por otra parte se definen como servicios a las diferentes aplicaciones dis-tribuidas que DCOS permite instalar en el cluster y que pueden haber sidodesarrollados por la misma empresa Mesosphere o por terceros por ejemploApache Spark Jenkins o Apache Hadoop En la figura 8 se muestra un diagramade los servicios disponibles incluyendo algunos de las aplicaciones distribuidasque soporta DCOS
Figura 8 Servicios DCOSFuente httpsdcosio
511 Apache Mesos
El nuacutecleo de DCOS estaacute basado en Apache Mesos un proyecto de coacutedigoabierto creado por la Universidad de California Berkeley y desarrollado actual-mente por la fundacioacuten Apache Se trata de un administrador de clusters queabstrae los recursos y los dispone para diferentes aplicaciones y entornos de tra-bajo distribuidos (frameworks) mediante una interfaz comuacuten En el momento deredaccioacuten de este proyecto Apache Mesos soportaba una variedad de entornosque abarcaba desde Big Data (Apache Spark Hadoop) hasta bases de datos(Cassandra Hypertable)
15
Arquitectura
Mesos se basa en la asignacioacuten de dos roles diferentes a los nodos
Maestros (Masters) Se encargan de la gestioacuten y reparticioacuten de los recursospara los diferentes entornos de trabajo mediante ldquoofertas de recursosrdquo deacuerdo a los disponibles y a la poliacutetica de asignacioacuten (planificacioacuten en dosniveles)
Esclavos (Slaves) Ordenadores donde se ejecutaraacuten las aplicaciones y cu-yos recursos son ofertados por los maestros
En el caso de fallo del maestro las tareas pueden seguir ejecutaacutendose perono se podraacute asignar nuevos recursos ni tareas por ello pueden existir varios enel cluster para configuraciones de alta disponibilidad pero soacutelo uno orquesta alos esclavos
Para la eleccioacuten del master liacuteder Mesos usa Apache ZooKeeper un proyectode software desarrollado por la misma fundacioacuten cuyo objetivo es proveer deun servicio de configuracioacuten centralizado y registro de nombres8
Por otra parte los entornos de trabajo son los programas que deciden final-mente queacute recursos se van a usar y se encargan de que los esclavos ejecuten lastareas Eacutestos se ejecutan sobre Mesos y constan de dos componentes
Planificador (Scheduler) Optimiza y decide los recursos a utilizar de losofertados informando a los Masters
Procesador (Executor) Ejecuta las aplicaciones o servicios en los esclavos
El objetivo final es conseguir una interfaz liviana tolerante a fallos paracualquier tipo de entorno de trabajo de tal manera que en los esclavos del clusterpuedan ejecutarse simultaacuteneamente tareas con necesidades y duracioacuten diferentesPara ello se basa en dos conceptos asignacioacuten y aislamiento de recursos
Asignacioacuten de recursos
En el cluster pueden coexistir entornos de trabajo con tareas de larga dura-cioacuten y con gran consumo de recursos con tareas cortas que los ocupan y liberancon rapidez El maestro integra un moacutedulo de asignacioacuten de recursos (allocationmodule) que se encarga del algoritmo de distribucioacuten
En el momento de escribir este proyecto estaban desarrollados dos moacutedulosuno mediante el cual el usuario puede asignar prioridades y otro que implementa
8httpszookeeperapacheorg
16
el algoritmo Dominant Resource Fairness9 a grandes rasgos se determina entodos los esclavos la tarea en ejecucioacuten que necesita maacutes recursos y se calcula laproporcioacuten del recurso de mayor peso con respecto al total por ejemplo si unatarea ocupa 2 GB de memoria con respecto a 10 GB totales que tiene el clusterse le asigna un dominant share del 20 la tarea se asignaraacute al nodo con menordominant share
Aislamiento de recursos
Para conseguir que tareas de diferentes entornos de trabajo y con distin-ta naturaleza se ejecuten simultaacuteneamente en un mismo nodo Mesos usa loscontenedores Linux (descritos en la seccioacuten 3)
Funcionamiento
La figura 9 muestra el esquema de la arquitectura de Apache Mesos conalta disponibilidad (tres maestros) y con dos entornos de trabajo ejecutaacutendo-se Hadoop que permite el almacenamiento y procesamiento de gran cantidadde datos para proyectos de big data y un sistema que implementa la interfazsistema de paso de mensajes MPI
Como se puede observar el sistema ZooKeeper elige a un solo maestro comoliacuteder y eacuteste orquesta el cluster comunicando los esclavos con los planificadoresde los diferentes entornos de trabajo Tambieacuten se puede observar como las tareasde los distintos entornos estaacuten distribuidas entre los tres esclavos disponibles
Figura 9 Arquitectura de Apache MesosFuente httpsmesosapacheorg
El proceso de asignacioacuten se realiza como sigue en primer lugar un usuariosolicita la ejecucioacuten de una tarea mediante la interfaz de cada entorno de traba-jo (interfaz graacutefica API HTTP ) De forma paralela un esclavo informa almaestro de los recursos que tiene libres En consecuencia eacuteste se lo notifica almoacutedulo de asignacioacuten que en funcioacuten de su configuracioacuten decide cuaacutento ofertar
9httpspeopleeecsberkeleyedu~aligpapersdrfpdf
17
y a queacute entorno de trabajo y enviacutea la oferta a los planificadores Eacutestos respondenal maestro con queacute recursos ha decidido usar para cada tarea Finalmente lastareas son enviadas al esclavo seleccionado el cual asigna los recursos indicadosal procesador (executor) quien finalmente las ejecuta
Cabriacutea pensar que esta metodologiacutea puede conducir a situaciones en lasque un entorno podriacutea quedarse con tareas sin ejecutarse a la espera de unaoferta satisfactoria para ello Mesos implementa un sistema de filtros medianteel cual los entornos especifican los requisitos miacutenimos que debe cumplir unaoferta por ejemplo se puede especificar en queacute nodos debe desplegarse la tareaEste sistema estaacute disentildeado asiacute con el objetivo de mantener lo maacutes transparenteposible esta herramientas de forma que acepte entornos de trabajo de distintasnaturalezas
512 Ejemplos de uso
Grandes empresas estaacuten usando Apache Mesos con eficacia de acuerdo a susnecesidades e infraestructuras Caben destacar
Ebay En el modelo de implementacioacuten continua en esta empresa10 cadadesarrollador cuenta con su propia instancia que se ejecuta en una maacutequinavirtual dedicada lo que ha conllevado un uso de los recursos poco eficiente Enuna prueba de concepto consiguieron realizar una herramienta de integracioacutencontinua distribuida basada en un cluster con Apache mesos y con el entornoMarathon y Jenkins
Apple Anuncioacute que el motor de su famosa herramienta de asistencia per-sonal para iPhones Siri estaacute desplegada sobre Apache Mesos11 Para ello handesarrollado su propio entorno para facilitar a los ingenieros a desplegar los ser-vicios que la herramienta necesita para resolver las peticiones de los usuarios
Twitter Desarrolloacute su propio entorno denominado Aurora y actualmentegestionan sus recursos y miden el coste de las tareas que los empleados usancon el objetivo de que sean conscientes del gasto que puede suponer un usoinadecuado de la infraestructura12
10httpwwwebaytechblogcom20140404delivering-ebays-ci-solution-with-apache-mesos-part-i11httpwwwbusinessinsidercomapple-siri-uses-apache-mesos-2015-812httpswwwlinuxcomNEWS4-UNIQUE-WAYS-UBER-TWITTER-PAYPAL-AND-HUBSPOT-USE-APACHE-MESOS
18
52 Nomad
Herramienta de coacutedigo abierto de gestioacuten de clusters creada y desarrolladapor Hashicorp13 que permite el despliegue de aplicaciones y procesos de formadistribuida
Las principales diferencias con Apache Mesos a grandes rasgos son
Arquitectura maacutes ligera Nomad soacutelo requiere de un fichero para funcionarejecutaacutendolo con las correspondientes configuraciones en todos los nodosrealiza las funciones de gestioacuten del cluster eleccioacuten de liacuteder planificacioacutende recursos y ejecucioacuten de las tareas
Centro de datos y regiones muacuteltiples Su arquitectura estaacute orientada afacilitar la gestioacuten de diferentes centros de datos geograacuteficamente distri-buidos
Entorno de ejecucioacuten Las tareas se definen y son interpretadas mediantecontroladores integrados en Nomad que se valen de los recursos y herra-mientas de los nodos clientes para ejecutarlas Esta integracioacuten dificultael desarrollo de controladores por parte de terceros a diferencia de Mesosque delega dicha responsabilidad en los entornos de trabajo externos alproyecto
Usa un planificador de estado compartido con respecto a la planificacioacutenen dos niveles de Mesos
Antes de entrar en maacutes detalle en la arquitectura es importante definir lossiguientes teacuterminos
Controlador (Driver) Software que se encarga de interpretar las definicionesde las tareas y ejecutarlas semejante a los procesadores de los entornosde trabajo de Mesos A la hora de redactar este proyecto Nomad contabacon controladores para contenedores Docker virtualizacioacuten de maacutequinasmediante el emulador QEMU aplicaciones java y archivos binarios
Grupo de trabajo (Task Group) Conjunto de tareas que se ejecutan en elmismo nodo cliente
Trabajo (Job) Conjunto loacutegico de tareas y grupos de trabajo que se despliegana la vez
Asignacioacuten (Allocation) Relacioacuten entre un grupo de trabajo y el cliente don-de se ejecuta
Evaluacioacuten (Evaluation) Proceso mediante el cual Nomad planifica y ges-tiona el registro o actualizaciones de los trabajos
13httpswwwhashicorpcom
19
Nomad sigue una arquitectura maestro-esclavo similar a la de Apache Mesosmuacuteltiples servidores acuerdan entre siacute un liacuteder que gestiona la planificacioacuten detareas en los clientes que soacutelo conocen sus asignaciones y las ejecutan
Todos los servidores participan paralelamente en tareas de planificacioacuten derecursos y asignacioacuten de tareas y ademaacutes entre ellos eligen un liacuteder que seencarga de la coordinacioacuten de la suscripcioacuten de los clientes al cluster y de lagestioacuten de las peticiones
Los clientes estaacuten configurados para comunicarse con el servidor usando lla-madas a procedimiento remoto (RPC por sus siglas en ingleacutes) que permite unordenador ejecutar coacutedigo en otra maacutequina Mediante esta tecnologiacutea los nodosclientes avisan de su estado e informa de sus asignaciones recursos y controla-dores disponibles
Existe la posibilidad de gestionar varios centros de datos agrupados en regio-nes eacutestas son independientes pero permite definir tareas o comprobar el estadode todas ellas desde cualquier punto A continuacioacuten se muestra una figura dela arquitectura a alto nivel de esta configuracioacuten
Figura 10 Arquitectura multi-regioacuten en NomadFuente httpswwwnomadprojectio
La herramienta se sustenta sobre tres protocolos fundamentales un protocolode consenso entre los servidores para compartir informacioacuten sobre su estado yel liacuteder un protocolo Gossip para la gestioacuten entre regiones y el planificador detareas
521 Protocolo de consenso Raft
El objetivo es obtener consistencia en un conjunto de nodos que comparteninformacioacuten es decir si un cliente realiza un cambio que todos los nodos veanla misma informacioacuten a la vez y ademaacutes sea tolerante a fallos Para ello se basaen el algoritmo Raft[13] que se detalla brevemente a continuacioacuten
20
Los nodos participantes en el algoritmo pueden estar en tres estados
Liacuteder (Leader) Todos los cambios que realicen en el cluster pasan por eacutel pri-mero
Seguidor (Follower) Nodo pasivo cuya responsabilidad es responder a laspeticiones del nodo liacuteder
Candidato (Candidate) Maacutequina que no ha encontrado liacuteder y solicita sueleccioacuten
Supongamos que tenemos cinco equipos que acaban de arrancar el protocoloEn la figura 11 se observan los nodos y sus respectivos registros a la derecha
Figura 11 Equipos sin consenso ejecutando el protocolo RAFTFuente httpsgithubcomongardieraftscope
Al comenzar todos los nodos son seguidores esperando recibir comunicacioacutende un nodo que actuacutee como liacuteder Cada nodo tiene un tiempo de espera aleatoriodespueacutes del cual si no es informado por un liacuteder pasa a estado candidato y pideel ldquovotordquo al resto de los participantes El algoritmo divide el tiempo en plazos uncandidato pasa a liacuteder si recibe la mayoriacutea de los votos en un plazo determinadoSe define mayoriacutea o cuoacuterum (quorum) comolceil
N2rceil
+ 1 (1)
donde N representa el nuacutemero de nodos
Para el ejemplo propuesto de 5 equipos se requieren de 3 votos Soacutelo losnodos que se encuentren en estado seguidor pueden votar una uacutenica vez a laprimera solicitud que reciba dentro de un plazo
Supoacutengase que el nodo denotado con S1 ha cumplido su tiempo de espera yrealiza la peticioacuten de voto (figura 12) A partir de este momento se pueden dartres casos
La maacutequina gana la eleccioacuten y pasa a ser liacuteder informando al resto
Otro servidor se establece como liacuteder en el mismo momento
Varios nodos pasan a ser candidatos por lo que ninguno consigue los votos
21
Figura 12 Un equipo pasa a estado candidato (RAFT)
Si un candidato recibe un aviso de un liacuteder en el mismo plazo el primeropasa a ser seguidor y se acaba la eleccioacuten de liacuteder
Por otro lado si un equipo candidato no recibe los votos en el plazo y agotasu tiempo de espera avanza al siguiente plazo y repite el proceso de votacioacutenLa tercera posibilidad puede conllevar a un estado indefinido ya que varioscandidatos pueden agotar su tiempo de espera al mismo tiempo y repartir losvotos Para solventarlo el algoritmo establece tiempos de espera aleatorios paralos candidatos
Siguiendo con el ejemplo propuesto el servidor S1 pasa a ser el liacuteder Cadacierto tiempo eacuteste debe realizar avisos a los nodos seguidores para no agotar sutiempo de espera
En este momento el cluster de servidores estaacute en ldquoconsensordquo y la informacioacutenen todos los nodos estaacute actualizada Un cambio en la informacioacuten inicia unproceso de replicacioacuten el liacuteder registra el cambio lo pasa al resto de nodos yuna vez eacutestos responden el cambio se hace efectivo
Supoacutengase que se realiza un cambio en los datos en la figura 13 en la partederecha se observa el cambio en el registro del servidor S1 que informa a losnodos seguidores En consecuencia los nodos registran el cambio y responden aS1
Figura 13 Cambio en un registro (RAFT)
Una vez el cuoacuterum (en el ejemplo tres equipos) informa al liacuteder de que
22
ha registrado el cambio el liacuteder lo hace efectivo en su sistema y notifica a losnodos que hacen lo mismo En la figura 14 el enviacuteo todaviacutea no ha llegado ala maacutequina S3 y se observa que no ha hecho efectivo el cambio (en el registroaparece punteado)
Figura 14 Aprobacioacuten del resto de equipos (RAFT)
Este protocolo funcionaraacute correctamente mientras exista un nuacutemero de nodosen funcionamiento igual o superior al cuoacuterum en el ejemplo propuesto elcuoacuterum es tres por lo que el sistema puede tolerar la caiacuteda de dos de los equipos
522 Protocolo gossip SWIM
Nomad permite la gestioacuten simultaacutenea de varios centros de datos reparti-dos en regiones geograacuteficamente separadas requiriendo de un protocolo ligeroque mantenga a los miembros actualizados sobre los participantes del conjun-to Para ello usa una ligera variante del protocolo SWIM[3] (Scalable Weakly-consistent Infection-style Process Group Membership Protocol) desarrollada porHashiCorp Estaacute clasificado como un protocolo de tipo gossip que debe su nom-bre a la semejanza con coacutemo se distribuye un rumor en una red social
SWIM se sustenta en dos caracteriacutesticas fundamentales la deteccioacuten de fallosy la distribucioacuten de la informacioacuten relativa a los miembros A continuacioacuten sedetalla el funcionamiento de ambos componentes
Deteccioacuten de fallos
Este componente tiene dos paraacutemetros el periodo de protocolo T y el nuacutemerode subgrupos de deteccioacuten de fallos k en los que se dividen los nodos Paracomprobar la comunicacioacuten entre dos maacutequinas usa la utilidad ping basadaen el protocolo ICMP La deteccioacuten de caiacuteda de un servidor sigue el siguientealgoritmo
Durante el periodo T cada miembro Mi de un subgrupo elige otro al azar Mjdel mismo subgrupo y le enviacutea un mensaje ping para comprobar su estado Enel caso de que se cumpla un tiempo de espera determinado por una estimacioacuten
23
del tiempo de ida y vuelta (RTT por sus siglas en ingleacutes) de la red y no hayarespuesta Mi le vuelve a enviar un mensaje ping indirectamente a traveacutes deun nuacutemero k de miembros escogidos aleatoriamente De no recibir ninguna res-puesta Mi establece que Mj ha sufrido un fallo y lo etiqueta como ldquosospechosordquoinformando al componente de distribucioacuten
Figura 15 Diagrama de tiempo del protocolo SWIMFuente httpswwwcscornelledu
Componente de distribucioacuten
Se encarga de informar de cualquier cambio en los miembros a todo el con-junto Los eventos de nodo caiacutedo y la unioacuten o disociacioacuten de un miembro setransmiten a todos los servidores para que actualicen sus lista Para distribuirla informacioacuten a todos los nodos se podriacutea usar el meacutetodo de multicast perosuele estar deshabilitado Por ello se utiliza una teacutecnica de transmisioacuten denomi-nada Piggybacking mediante la cual se adjunta a los propios mensajes PINGy ACK del algoritmo la informacioacuten a distribuir reduciendo asiacute la congestioacutenen la red
523 Planificacioacuten
Proceso encargado de distribuir las tareas entre los nodos clientes de acuerdoa su estado
El planificador de Nomad estaacute basado en las publicaciones de Google sobresus herramientas de gestioacuten de clusters Borg y Omega14 y entiende los trabajosdescritos por el usuario como un estado deseado es decir su despliegue en unamaacutequina cliente de forma correcta y los clientes como el estado actual esto eslo que se encuentra en ejecucioacuten El registro actualizacioacuten o cancelacioacuten de un
14httpresearchgooglecompubspub43438html
24
trabajo asiacute como el fallo de un nodo cliente implican un cambio de estado atramitar por el sistema lo que se define como evaluacioacuten (evaluation) Esto uacutelti-mo supone comparar el estado actual (clientes) con el estado deseado (conjuntode trabajos registrados) y enviarlos a los planificadores correspondientes que seencargaraacuten de asignar las tareas a los nodos clientes
Figura 16 Procedimiento de asignacioacuten en NomadFuente httpswwwnomadprojectio
En la figura 16 se observa el flujo de trabajo en el que las distintas evalua-ciones se encolan en el evaluation broker que se ejecuta en el servidor liacuteder ygestiona las evaluaciones pendientes asignaacutendoles prioridades
A continuacioacuten los nodos servidores ejecutan los scheduling workers queprocesan las evaluaciones llamando a los distintos planificadores que generanun plan de asignacioacuten esto es un conjunto de relaciones entre las tareas y losnodos clientes donde se ejecutaraacuten Este proceso se divide en dos fases primerose descartan aquellos clientes que no cumplan los requisitos y posteriormentese asigna una calificacioacuten al resto Se selecciona el nodo con mayor puntuacioacuteny se encola el plan en el gestor que se ejecuta en el servidor liacuteder Existen tresplanificadores de acuerdo al tipo de trabajo
Service Incluye aquellos trabajos que estaacuten destinados a ejecutarse en un pe-riacuteodo largo de tiempo Para realizar las asignaciones el planificador evaluacuteala mayor parte de los nodos y usa una versioacuten del algoritmo Best fit in-fluenciada por el trabajo de Google en su herramienta Borg Se trata deun algoritmo de planificacioacuten que sacrifica tiempo a cambio de maximizarel rendimiento de los clientes asignando la tarea a la maacutequina que tengala mayor carga de trabajo con el objetivo de reducir equipos en funciona-
25
miento
Batch Tareas que incluyen listas de comandos en general de menor duracioacuteny que no requieren interaccioacuten con el usuario Se vale del algoritmo deSparrow desarrollado por la universidad de Berkeley15 para limitar losnodos clientes a evaluar
System Trabajos destinados a ejecutarse en todos los nodos incluso los que seunen al cluster posteriormente
Core Mantenimiento interno de Nomad
Una vez se ha realizado el proceso de planificacioacuten el nodo liacuteder lo registra enla cola de planes (plan queue) que se encarga de asignarles prioridad y manejarcondiciones de carrera es decir que no accedan a los recursos de los clientes sincontrol y evitar que eacutestos superen su capacidad
La maacutequina liacuteder del conjunto puede de este modo aceptar una asignacioacuteny ser ejecutada por los clientes o por el contrario rechazaacutersela al planificadorlo que implicariacutea realizar un plan parcial o totalmente nuevo
Finalmente el estado de las evaluaciones se actualizan y los clientes soninformados de las asignaciones ejecutaacutendose las tareas
15httppeopleeecsberkeleyedu~keopublicationssosp13-final17pdf
26
6 Casos de uso y despliegue
Con el objetivo de mostrar las posibles utilidades que este tipo de sistemaspueden tener en las infraestructuras TI actuales se han desplegado las dos he-rramientas en la nube Microsoft Azure usando su servicio cloud de instancias demaacutequinas virtuales Linux para simular un conjunto de ordenadores conectadosentre siacute por una red LAN Sobre ellas se ha implementado dos casos de usouna aplicacioacuten web con una arquitectura con cierta orientacioacuten a microserviciosy un sistema de integracioacuten continua
El coacutedigo y todos los ficheros de configuracioacuten se pueden encontrar en elrepositorio del proyecto en GitHub16
61 Aplicacioacuten Web
Se busca simular el proceso de adaptacioacuten de una solucioacuten web para su des-pliegue en un sistema distribuido con las herramientas anteriormente descritascon el objetivo de aumentar tanto su escalabilidad como disponibilidad medianteredundancia
Se ha partido de una aplicacioacuten ya existente17 un servicio de almacenamien-to y reproduccioacuten de canciones A grandes rasgos este servicio permite crearusuarios subir canciones con sus respectivas portadas tener playlists propias yescuchar las canciones a traveacutes de un navegador web
La solucioacuten estaacute dividida en 4 partes (figura 17)
Una vista web con la loacutegica
Un almacenamiento conectado en red (NAS por sus siglas en ingleacutes)
Una API REST para gestionar las peticiones al almacenamiento
Base de datos NoSQL basada en MongoDB
La nueva tendencia de los proyectos web es su implementacioacuten en contene-dores Docker ya que facilitan su portabilidad y ofrecen un procedimiento dedespliegue raacutepido sobre todo a la hora de desarrollar y realizar pruebas en en-tornos de produccioacuten simulados Por ello en este caso se va a hacer uso de los
16httpsgithubcomAntonioAlfrzCloud-Orchestrators17httpsgithubcomsonsoleslpCDPSfy
27
motores de orquestacioacuten de contenedores de ambas herramientas Marathon enDCOS y el controlador Docker en el caso de Nomad
Figura 17 Arquitectura aplicacioacuten web
A continuacioacuten vamos detallar el despliegue en ambas herramientas de es-ta solucioacuten y observar tanto queacute dificultades se encuentran como que ventajasofrecen El objetivo final es adaptar el proyecto modificaacutendolo lo menos posiblecon objeto de analizar la capacidad de estas herramientas para desplegar cual-quier aplicacioacuten sin que eso conlleve la modificacioacuten de la arquitectura de eacutestaes decir que no sea dependiente del entorno
611 DCOS
Se ha descrito DCOS como una herramienta que se despliega sobre un con-junto de ordenadores y que permite instalar gestionar el despliegue de sistemasdistribuidos
Microsoft Azure cuenta con una plantilla para desplegar en su servicio cloudun cluster de maacutequinas virtuales con DCOS ya instalado que cuenta con
Maacutequinas maestras (1 3 o 5 a seleccionar por el usuario) configuradascomo un conjunto de disponibilidad esto eso Azure da ciertas garantiacuteasde que al menos una maacutequina estaraacute en funcionamiento
Maacutequinas agentes Por motivos de seguridad se distinguen dos roles
bull Nodos privados solo accesibles desde la red interna y configuradoscomo un conjunto de escala un recurso de Azure para gestionar ydesplegar maacutequinas con configuraciones ideacutenticas para permitir unraacutepido escalado
bull Un equipo conectado accesible desde Internet a travntildees de un balan-ceador de carga puacuteblico y situado en una subred externa
28
Dos balanceadores de carga
bull La interfaz puacuteblica del cluster que se conecta con el cliente puacuteblicobull Acceso a los equipos maestros para el administrador que soacutelo permiteconexioacuten mediante SSH y credenciales
Almacenamiento para todas las maacutequinas
Configuraciones necesarias de red y seguridad
En la figura 18 se observa un diagrama de la infraestructura
Figura 18 Infraestructura en Azure
El primer obstaacuteculo es la persistencia de estado de la aplicacioacuten que seconsigue gracias a una base de datos no relacional basada en MongoDB asiacutecomo el almacenamiento de las canciones Para implementarla tenemos variasposibilidades
Montar un sistema externo de almacenamiento conectado en red en todoslos agentes donde se ejecuten las tareas de esta manera si una tarea pasade un nodo a otro por cualquier motivo puede tener acceso a los mismosficheros (opcioacuten del caso de uso original)
Implementar un sistema de ficheros distribuidos en los agentes
Usar los servicios de almacenamiento de las nubes puacuteblicas
Aprovechar el sistema de voluacutemenes persistentes de Apache Mesos Eacutestepermite reservar recursos de un agente de forma que al arrancar una tarease crea un volumen independiente del ciclo de vida de eacutesta con ello esosrecursos donde se ha almacenado la informacioacuten pueden volver a ofrecerseal mismo entorno de tal manera que otra tarea pueda acceder a ella
DCOS aprovecha este sistema de voluacutemenes persistentes y permite instalarbases de datos distribuidas como ArangoDB o Apache Cassandra sin embargoesto implicariacutea modificar todo el coacutedigo referente al modelo de la base de datos
29
Por motivos de eficiencia y latencia asiacute como de una mayor gobernabilidadde los datos la mejor opcioacuten es usar el recurso de voluacutemenes persistentes queofrece Apache Mesos ya que de esta manera se gestionariacutea la aplicacioacuten completamediante una uacutenica herramienta Sin embargo esto implica que la informacioacutense encuentra exclusivamente en el agente donde se haya ejecutado la tarea y porlo tanto se sigue requiriendo de software externo para distribuir la informacioacutenpara que se accesible para todos los agentes A la hora de realizar este proyectose encontraba en desarrollo Flocker una solucioacuten desarrollada por ClusterHQque permite compartir los voluacutemenes de Docker a traveacutes de un cluster quesi bien es compatible con el planificador de Mesos el proyecto se encontrabatodaviacutea en fases tempranas de desarrollo y los sistemas de almacenamiento quesoporta quedaban fuera del aacutembito de este trabajo
Por todo ello dado que las maacutequinas se han desplegado en la nube puacuteblicade Azure se decidioacute usar su servicio de almacenamiento de objetos para lascanciones y otra maacutequina para desplegar MongoDB y asiacute mantener el modelode datos original de la aplicacioacuten La diferencia del almacenamiento de obje-tos con respecto a nivel de fichero es que el primero no tiene jerarquiacutea paraorganizar los archivos eacutestos se guardan como objetos (con sus metadatos) enun mismo espacio soacutelo diferenciaacutendose por un identificador uacutenico esto implicaentre otras cosas que se puede acceder a un fichero dado uacutenicamente su IDindependientemente de la localizacioacuten fiacutesica de eacuteste facilitando pues la gestioacuteny el desarrollo
El coacutedigo del proyecto se ha modificado en los siguientes apartados
Las direcciones de la base de datos y los balanceadores de carga asiacute comosus puertos estaban originalmente fijos Se han configurado como variablesde entorno para facilitar el descubrimiento del servicio y hacer transpa-rente la aplicacioacuten al entorno de despliegue
La API REST se ha adaptado al almacenamiento en Azure en vez de enlocal
Estas modificaciones no suponen un cambio sustancial pero permiten separala persistencia de las tareas ejecutadas por DCOS lo que facilita en granmedida su ejecucioacuten al ser totalmente sin estado y ademaacutes implican tenerlos datos bajo un mayor control
Para la orquestacioacuten de contenedores se va a usar el entorno Marathondesarrollado tambieacuten por Mesosphere Eacuteste se puede usar a traveacutes de una interfazgraacutefica la interfaz de liacutenea de comandos (en lo que sigue CLI por sus siglas eningleacutes) de DCOS o con su API HTTP
Primero se han publicado la imaacutegenes de los contenedores que encapsulanla interfaz web y la api de la aplicacioacuten en el repositorio puacuteblico DockerHub
Los despliegues en este entorno se describen mediante ficheros JSON en losque se detalla entre otras opciones la imagen del contenedor los puertos a usar
30
los recursos que debe ocupar en un nodo o las instrucciones de monitorizacioacuten
Para el servicio de descubrimiento DCOS ofrece la posibilidad de asignardirecciones IP virtuales (VIP por sus siglas en ingleacutes) a tareas que se compartenen todos los nodos DCOS lleva integrado un balanceador de carga a nivel TCP(el componente denominado Minuteman) que balancea entre las direccionesvirtuales de las tareas y todas las instancias de eacutestas a lo largo del cluster Estoes necesario por dos motivos equilibrar la carga de los equipos con el fin deevitar un punto de uacutenico fallo mediante redundancia y evitar la contienda dedirecciones al ejecutar las tareas en puertos aleatorios
Este balanceador de carga estaacute basado en el trabajo de Michael Mitzenma-cher The Power of Two Choices in Randomized Load Balancing18 A grandesrasgos el algoritmo mantiene una media moacutevil exponencial de latencias paracada destino (backend) ademaacutes de las caiacutedas consecutivas Si un destino noresponde a una negociacioacuten en tres pasos (three way handshake) de forma con-secutiva en un periodo inferior a 5 ms se considera caiacutedo El algoritmo iterasobre los destinos disponibles en base a su histoacuterico de fallos y escoge dos deforma aleatoria de los cuales coge el de mejor meacutetrica
Las direcciones virtuales soacutelo se pueden resolver dentro del cluster porello para implementar la interfaz puacuteblica de la aplicacioacuten esto es el balancea-dor de carga de la interfaz web usaremos un paquete de DCOS denominadomarathon-lb un balanceador basado en HAProxy y adaptado por MesosphereEn este caso equilibra la carga de todas instancias de las tareas ejecutadas porel entorno Marathon por sus etiquetas y permite ademaacutes definir como puntode entrada muacuteltiples hosts virtuales definidos por sus nombres completos dedominio (FQDN por sus siglas en ingleacutes) en nuestro caso la interfaz puacuteblicadel balanceador de Azure para los agentes
Por motivos de seguridad todas las tareas se ejecutan en los agentes privadoses decir los que son exclusivamente accesibles desde la red interna Por su partemarathon-lb se ejecuta en el agente puacuteblico que cuenta con IP puacuteblica y lospuertos 80 (HTTP) y 8080 abiertos de forma que la aplicacioacuten sea accesibledesde Internet Esto es posible debido a que Apache Mesos permite reservarrecursos mediante roles asignados a nodos para un uso especiacutefico De esta formala arquitectura vista desde la aplicacioacuten quedariacutea como en la figura 19
18httpswwweecsharvardedu~michaelmpostscriptstpds2001pdf
31
Figura 19 Arquitectura de la aplicacioacuten web en DCOS
Ejecucioacuten
A la hora de desplegar la aplicacioacuten DCOS puede gestionarse medianteuna interfaz graacutefica o una interfaz de liacutenea de comandos La primera se accedea traveacutes de un navegador web en el puerto 80 (HTTP) y permite instalar losentornos disponibles observar el estado de los nodos y las tareas que se estaacutenejecutando y los ficheros de registros que eacutestas generan
La CLI permite el control desde un nodo o una maacutequina remota (suponiendoque los maestros tienen IP puacuteblica y el puerto 80 abierto) ya que DCOS tieneun sistema de autorizacioacuten que permite tener una interfaz puacuteblica con ciertasgarantiacuteas de seguridad
Por su parte cada entorno de trabajo puede ser controlado por la CLI peroademaacutes cuenta con sus propias interfaces Marathon expone una API HTTPen el puerto 8080 de la direccioacuten puacuteblica de los maestros del cluster asiacute comootra interfaz graacutefica Para desplegar un contenedor se podriacutea usar la CLI
$ dcos marathon app add lt f i l e j songt
O la API HTTP
$ cu r l minusX POST http lt ip_maestro gt8080v2apps minusd ltf i l e jsongt minusH Contentminustype app l i c a t i o n j son
32
612 Nomad
La arquitectura de Nomad es maacutes sencilla ya que solo requiere de un ficheroejecutable en todos los nodos para funcionar Si DCOS es la base de instala-cioacuten de entornos de terceros Nomad integra todas las funcionalidades baacutesicasesto es gestor de recursos planificador y ejecutor en los nodos cliente Estaherramienta cuenta con un menor tiempo de desarrollo y en el momento deescribir este documento cuenta exclusivamente con los siguientes controladoresen comparacioacuten con los entornos de DCOS
Motor Docker es decir funcioacuten de orquestacioacuten de contenedores
Ejecucioacuten de archivos binarios como comandos de Shell
Ejecucioacuten de aplicaciones Java
Virtualizacioacuten de maacutequinas mediante tecnologiacutea QEMU
Todos ellos necesitan que la tecnologiacutea subyacente esteacute instalada en las maacute-quinas clientes (Docker Java QEMU) Actualmente no permite el registro decontroladores por parte de terceros aunque estaacute planificado en un futuro ofreceruna interfaz para su desarrollo
Nomad no cuenta con el servicio de descubrimiento sin embargo puede inte-grarse con la herramienta Consul desarrollada por la misma empresa Por otrolado para el balanceo de carga usaremos un contenedor Docker con HAProxyuna herramienta de coacutedigo abierto que ofrece tanto servicios de proxy como debalanceador y cuyos ficheros de configuracioacuten completaremos con el proyectoConsul Template19
Consul
Consul sigue la misma arquitectura que Nomad es decir un nodo servidorque orquesta un conjunto de maacutequinas clientes y permite a los procesos que seejecutan en los equipos definirlos como servicios ofreciendo diversas caracteriacutes-ticas entorno a estos de los cuales vamos a usar dos
Descubrimiento de servicio Las maacutequinas clientes publican en el cataacutelogode servicios las tareas en ejecucioacuten y Consul les asigna nombres de dominioaccesibles por todos los miembros del cluster a traveacutes de la interfaz DNSincluida en esta herramientaConsul se integra con Nomad de forma que todas las tareas que se ejecu-ten en la segunda son automaacuteticamente publicados como servicios de laprimera de esta manera no hace falta conocer la direccioacuten de la maacutequinacliente donde se esteacute ejecutando el proceso ya que se puede acceder a eacutela traveacutes de su nombre de dominio de forma transparente Por ejemplo si
19[httpsgithubcomhashicorpconsul-template]
33
ejecutamos una tarea con ID web en el puerto 8080 se puede acceder aella en la direccioacuten webserviceconsul8080Para que las direcciones propias de Consul las resuelva su propio DNS y noel que esteacute asignado por defecto en la maacutequina usaremos la herramientadnsmasq20 que permite especificar la direccioacuten de un servidor DNS paraconsultas de direcciones especiacuteficas
Monitorizacioacuten Permite realizar comprobaciones del servicio y seguir su esta-do Aprovecharemos esta funcionalidad tanto para definir el propio procesode Nomad como servicio de Consul como las tareas desplegadas
HAProxy + Consul Template
HAProxy es una solucioacuten versaacutetil de coacutedigo abierto que ofrece solucionesde balanceo de carga y proxy Existen otras herramientas en el mercado comoNGINX o ldirectord sin embargo HAProxy suponiacutea una solucioacuten sencilla deconfigurar para mostrar el caso de uso
El uso de estas herramientas se debe a dos motivos para que no existacontienda con respecto a los puertos de los clientes usados por las tareas eacutestos sevan a asignar de forma dinaacutemica lo que en principio implicariacutea que la aplicacioacutendeberiacutea realizar consultas DNS de tipo SRV (que incluye puertos) a la interfazde Consul y balancear la carga entre tareas por redundancia y capacidad
Como la direccioacuten IP y puerto son variables cada vez que las tareas seactualicen o se reasignen es necesario volver a configurar HAProxy de formamanual Por ello HashiCorp ha desarrollado un programa denominado Con-sul Template que realiza peticiones sucesivas a la interfaz HTTP de Consul delas direcciones fiacutesicas de un servicio y reinicia automaacuteticamente el proceso deHAProxy Asiacute definiendo estas tareas como servicios Consul podremos tantomonitorizarlas como escalar las tareas dinaacutemicamente sin necesidad de cambiarel balanceador A partir del contenedor Docker oficial de HAProxy se ha desa-rrollado otro con la configuracioacuten baacutesica y con Consul Template para desplegarlocomo una tarea en Nomad
Despliegue
Se ha usado el mismo coacutedigo que en el apartado anterior con la persistenciaen el servicio de almacenamiento de Azure Desde la perspectiva del hardwarese implementaraacute la misma infraestructura que en el caso de DCOS (figura 18)estos es definiremos dos tipos de maacutequinas clientes un agente que se conectaraacutecon el balanceador de carga con nombre de dominio puacuteblico y donde se desple-garaacute el balanceador de carga de la vista web y agentes privados no accesiblesdesde fuera del cluster y donde se ejecutaraacuten el resto de tareas en la red inter-na La principal diferencia radica en las tareas que ejecutan HAproxy y ConsulTemplate que sustituye a las direcciones IP virtuales que ofrece DCOS
20httpwwwthekelleysorgukdnsmasqdochtml
34
Figura 20 Despliegue en Azure de Nomad+Consul
Cabe matizar que los balanceadores basados en HAProxy se implementanpor necesidad de la aplicacioacuten para el descubrimiento del servicio a diferenciade los de Azure que se implementan por motivos de seguridad y escalabilidaddel cluster en siacute
Configuracioacuten Nomad
Los ficheros de configuracioacuten de las maacutequinas maacutester y cliente son similaresy comparten la mayoriacutea de las opciones como por ejemplo el nombre del nodoo la interfaz de red donde escucha Nomad las peticiones Sus opciones son engeneral auto-explicativas sin embargo existen dos detalles que matizar
El proceso de Nomad escucha las peticiones tanto de los protocolos deconsenso como del usuario a traveacutes de una interfaz de red que se debeindicar en el fichero de configuracioacuten
En el caso de los clientes se deben indicar las direcciones de los servidoresdel cluster sin embargo se trata de un sistema dinaacutemico en el que losnodos pueden sufrir errores y cambiar de direccioacuten Por ello se ha definidoNomad como un servicio de Consul y asiacute poder definir la direccioacuten de losservidores como un nombre de dominio no por su direccioacuten fiacutesica que elservidor DNS de Consul se encargaraacute de resolver
Por defecto Nomad usa los siguientes puertos
API HTTP 4646 Peticiones HTTP y recepcioacuten de oacuterdenes mediante laliacutenea de comandos
RPC 4647 Protocolo de consenso entre los nodos del cluster
Serf 4648 Protocolo de gossip entre los servidores de los centros de datosgobernados por Nomad
35
Los dos uacuteltimos deben ser interfaces alcanzables por otros nodos sin embargo laAPI HTTP por motivos de seguridad deberiacutea ser local ya que en caso contrariocualquier persona con acceso a ella tiene el control sobre la herramienta Eacutestasolo deberiacutea estar accesible en un servidor o gestionarlo mediante una terminalSSH por ejemplo En este trabajo al ser una prueba de concepto se ha abiertoen todos los nodos
Trabajos de Nomad
Las tareas se detallan en ficheros con formato HashiCorp Configuration Lan-guage un derivado del formato JSON creado por la empresa que le da nombrecompatible con eacuteste y que permite comentarios
En estos ficheros se puede definir
La regioacuten y el centro de datos donde se ejecutaraacute (Nomad permite lagestioacuten de centros de datos geograacuteficamente distribuidos en regiones)
La poliacutetica de actualizacioacuten de la tarea
Grupo de tareas esto es que se ejecutaraacuten en el mismo nodo
El nuacutemero de grupos a ejecutarescalar asiacute como los liacutemite que debencumplir los nodos asignados
La poliacutetica de reinicio ante fallo o error
Tareas El controlador su configuracioacuten los paraacutemetros del servicio aso-ciado a registrar en Consul asiacute como los recursos que consume (puertosmemoria)
En nuestro caso usamos sobre todo el controlador Docker esto eso orques-tacioacuten de contenedores en los nodos clientes y tres de sus opciones
Imagen del contenedor Se han subido todas las imaacutegenes del proyecto a Doc-ker Hub donde por defecto se busca la imagen
Puertos Los puertos a usar por el contenedor que pueden ser estaacuteticos asigna-dos por el usuario o dinaacutemicos siendo Nomad el que se encarga de mapearun puerto libre del nodo cliente al expuesto por el contenedor
Servidores DNS Como usamos la interfaz DNS de Consul como descubri-miento de servicio se debe configurar el contenedor para que use cualquiernodo del cluster como servidor DNS
Configuracioacuten Consul
Al ser desarrolladas por la misma empresa los ficheros de configuracioacuten deConsul y Nomad comparten muchas opciones Consul tambieacuten acepta peticionesa traveacutes de una interfaz de red siendo los puertos usados por defecto
36
RPC 8300 8400 Maneja la peticiones del resto de nodos y usuarios
Serf 8301 8302 Protocolo gossip
HTTP API 8500
HTTPS API Desactivada por defecto
Interfaz DNS 8600
Se debe asignar a los protocolos internos del cluster esto es RPC y Serf unainterfaz alcanzable por los nodos y por el contrarioasignar a los dos uacuteltimos ala interfaz de loopback por motivos de seguridad
Cabe destacar que Consul tambieacuten cuenta con una interfaz graacutefica que per-mite ver el estado de los equipos y los servicios registrados y que se encuentra enel mismo puerto que la API HTTP en la direccioacuten httpIP_EQUIPO8500ui
Ejecucioacuten
Tanto Nomad como Consul requieren de la ejecucioacuten de un fichero en todoslos nodos integrantes del cluster Como prueba de concepto se ha decidido usardos servidores para ambos aunque cabe matizar que es un nuacutemero ineficienteya que la caiacuteda de uno de ellos supondriacutea la peacuterdida del cuoacuterum y por tantodel consenso del cluster
En primer lugar se arrancan los servidores que son los encargados de ejecu-tar el protocolo de consenso y gestionar el cluster y a continuacioacuten los clientesque no tienen praacutecticamente estado y dependen de los servidores
En el caso de Consul se debe indicar el directorio donde se guardan losficheros que describen los servicios asiacute como el archivo que especifica el resto delas opciones
1 Se inicia el primer servidor en uno de los equipos
$ consu l agent minuscon f i gminusd i r e t c consu l d s e r v i c e s minuscon f i gminus f i l e consu l_server j son
2 Los siguientes equipos deben unirse al anterior por lo que antildeadimos elargumento join con la direccioacuten del primer servidor Para el caso de otrosservidores
$ consu l agent minuscon f i gminusd i r e t c consu l d s e r v i c e s minuscon f i gminus f i l e consu l_server j son minus j o i n ltIP_servidor1gt
37
Una vez los servidores han alcanzado el consenso y elegido un liacuteder en losclientes
$ consu l agent minuscon f i gminusd i r e t c consu l d s e r v i c e s minuscon f i gminus f i l e c on su l_c l i en t j son minus j o i n ltIP_cualquierServ idorgt
El proceso para iniciar Nomad es igual y los comandos similares sin embargoya no es necesario indicar una direccioacuten IP fija en los equipos sino el nombre dedominio del servicio de Nomad registrado por Consul En el primer servidor
$ nomad agent minusc on f i g nomad_server j son
Y el resto de equipos (con su fichero de configuracioacuten correspondiente)$ nomad agent minusc on f i g nomad_server j son minus j o i n nomad s e r v i c e consu l
Por uacuteltimo para desplegar la aplicacioacuten web se han escrito tres ficherosque detallan las tareas de la interfaz web API y los balanceadores de cargaMediante la CLI
$ nomad run minusaddress=http lt ip_c lus te r gt4646 lt f i l e hclgt
O mediante la API HTTP de Nomad$ cu r l minusX POST minusd ltf i l e hclgthttp lt ip_c lus te r gt4646 jobltjob_namegt
Ansible
Como se puede comprobar con el aumento del nuacutemero de equipos pasa aser inviable manejar todos los nodos a traveacutes de terminal Ademaacutes como seha comentado con anterioridad Nomad requiere que en los nodos clientes es-teacuten instalados las herramientas que soporten las tareas por ejemplo el motorde Docker Por ello para facilitar tanto el arranque como la instalacioacuten de lasdependencias vamos a usar Ansible una herramienta de coacutedigo abierto desarro-llada en Python que permite gestionar configuraciones aprovisionar recursosdespliegue de aplicaciones de forma automaacutetica
A grandes rasgos esta herramienta funciona mediante ficheros en formatoYAML denominados play-books que describen un conjunto de pasos a ejecutaren una lista de equipos remotos Estos pasos son ejecutados por moacutedulos inde-pendientes a traveacutes de SSH es decir en cualquier ordenador con conexioacuten a los
38
hosts dado su contrasentildea o clave puacuteblica puede arrancar el script y realizariacutealos pasos de forma remota gestionando el cluster desde un solo equipo
Se han desarrollado guiones para lo siguiente
Descarga de los binarios de Nomad y Consul en todos los nodos copiade los ficheros de configuracioacuten baacutesicos y modificarlos de acuerdo a cadanodo (nombre del equipo direccioacuten IP)
Instalacioacuten de las dependencias
Arranque de Nomad y Consul
Ansible extiende su funcionalidad a traveacutes de moacutedulos independientes que per-miten por ejemplo instalar paquetes mediante herramientas de gestioacuten de pa-quetes (APT yum) aprovisionar automaacuteticamente maacutequinas virtuales de Ama-zon EC2
Algunas opciones de los ficheros de configuracioacuten de Nomad y Consul sondependientes del nodo particular por ejemplo la interfaz de red Para estetrabajo se ha realizado un moacutedulo para modificar los ficheros de configuracioacutende forma automaacutetica En el repositorio del proyecto se encuentra una carpetadonde se encuentran todos los ficheros necesarios para desplegar un clustertotalmente funcional solo requiere de una liacutenea de terminal con Ansible
$ ans ib l eminusplaybook minus i hos t s minusk ltssh_passgt minusu ltnode_usergt s i t e yml
39
62 Servicio de integracioacuten continua
Se ha implementado un sistema de integracioacuten continua que permite ejecu-tar tareas de compilacioacuten y pruebas de forma distribuida aumentando asiacute elrendimiento de los equipos En primer lugar se detallaraacute los motivos por los quepuede resultar beneficioso para las empresas una implementacioacuten de este tipo alo que seguiraacute los detalles del despliegue
621 DevOps
Metodologiacutea que defiende la comunicacioacuten y colaboracioacuten entre desarrolla-dores de software y los profesionales de operaciones a lo largo de todo el ciclo devida de una aplicacioacuten Estaacute muy relacionado con el desarrollo aacutegil de softwareesto es un enfoque para los proyectos que defiende el desarrollo iterativo e in-cremental donde los requisitos y soluciones evolucionan con el tiempo seguacuten lanecesidad del proyecto DevOps extiende esta filosofiacutea a todas los componentesde un servicio incluyendo sistemas y operaciones
Se trata de un concepto que cada organizacioacuten o empresa adapta a suspropias necesidades y procesos de negocio en este proyecto nos vamos a centraren la integracioacuten continua una praacutectica fundamental tanto del desarrollo aacutegilcomo de esta filosofiacutea
622 Integracioacuten Continua
Se define como una praacutectica de desarrollo software donde los miembros delequipo ponen en comuacuten su trabajo frecuentemente al menos una vez al diacutea21Cada integracioacuten se verifica con una compilacioacuten automaacutetica que incluye laejecucioacuten de pruebas para detectar errores de integracioacuten tan pronto como seaposible
Desde el punto de vista operativo esto supone automatizar la configuracioacutende equipos o el despliegue de maacutequinas virtuales donde compilar el proyecto yejecutar las pruebas y posteriormente eliminarlas Este flujo de trabajo se vebeneficiado en entornos distribuidos ya que el objetivo del desarrollador es com-probar el resultado de las pruebas raacutepidamente sin preocuparse del despliegueo los propios equipos
Para esta prueba de concepto vamos a usar Jenkins un servidor de integra-cioacuten continua escrito en Java que nos permite definir trabajos que contendraacutenla descripcioacuten tanto del entorno como su ejecucioacuten
Este sigue una estructura maestro-esclavo muy similar al de los gestores declusters usados en este proyecto el maestro contiene toda la loacutegica del servicio
21httpmartinfowlercomarticlescontinuousIntegrationhtml
40
trabajos autenticacioacuten y los esclavos son los encargados de la ejecucioacuten ensiacute Jenkins tiene varias viacuteas para aprovisionar los uacuteltimos
Mediante SSH
Interfaz graacutefica
Desarrollar un script propio
Ejecucioacuten de un fichero java
La ventaja de usar planificadores es que el despliegue de esclavos es dinaacutemicoes decir no tener una maacutequina especiacuteficamente configurada para ello DCOS yNomad se encargaraacuten de configurar estos despliegues en sus maacutequinas y poste-riormente eliminarlos Para ello se ha usado la uacuteltima opcioacuten definiendo tareasque descarguen el fichero java Con todo ello se consigue un entorno de inte-gracioacuten continua eficiente que ademaacutes permite la ejecucioacuten de otros servicios deforma independiente
Jenkins permite la creacioacuten de plugins que extienden sus funcionalidadesTanto Nomad22 como Apache Mesos cuentan con uno que permite su integra-cioacuten
Para esta prueba se va a usar el mismo proyecto que para el caso de usode orquestacioacuten de contenedores la aplicacioacuten web al que se le ha antildeadido untest para comprobar que se conecta correctamente a la base de datos medianteMocha un framework de Nodejs Por otro lado se antildeade el plugin de git ya queel coacutedigo se obtiene de GitHub el repositorio remoto de control de versiones delproyecto
El proceso general de ejecucioacuten seriacutea como sigue
1 Se ejecuta el maestro de Jenkins como tarea Docker partiendo de la imagenoficial
2 Al arrancar un trabajo se manda una tarea a los planificadores que laasignaraacuten a un nodo cliente Esta tarea consiste en la descarga del ficherode configuracioacuten Java y arrancarlo configurando el equipo como un clientede Jenkins temporalmente
3 Jenkins ejecuta el trabajo en el nuevo cliente en este caso iniciar la apli-cacioacuten web iniciar las pruebas y generar un informe
4 Se elimina el cliente
A continuacioacuten se detallan los matices de cada herramienta a la hora de imple-mentar este servicio
22Desarrollado por Ivo Verberk httpwwwivoverberknl
41
623 Jenkins con Nomad
El plugin permite la ejecucioacuten del fichero Java mediante dos controladorescontenedores Docker y Java En este proyecto nos hemos decantado por el pri-mero ya que nos ahorra instalar la maacutequina virtual de java en todos los nodoscliente Por ello se ha construido un contenedor base con Java para la ejecucioacutendel fichero de configuracioacuten y Nodejs para lanzar la aplicacioacuten web
El plugin se configura con la direccioacuten IP del cluster y el contenedor queejecuta el esclavo Jenkins Por su parte el trabajo en Jenkins se define conel repositorio en GitHub donde se aloja el coacutedigo del proyecto a probar y loscomandos a ejecutar en este caso npm update y npm test
624 Jenkins con DCOS
En el caso de DCOS su sistema de paquetes incluye Jenkins por lo queal instalarlo ya se tiene la configuracioacuten de Mesos totalmente funcional Sinembargo para ejecutar la aplicacioacuten en particular y las pruebas se requiere deNodejs en los equipos esclavos por ello debemos antildeadir un plugin de Jenkinsque permite instalar este entorno antes de ejecutar el trabajo Una vez hechoesto soacutelo queda definir la tarea igual que en el caso anterior
Cabe destacar que Mesosphere tambieacuten ha desarrollado un plugin que per-mite hacer despliegues en Marathon de tal manera que permitiriacutea con cadacommit del coacutedigo compilar la imagen del contenedor Docker y desplegarlaautomaacuteticamente aunque en este proyecto no se ha hecho pruebas de esta fun-cionalidad
42
7 Escalando la infraestructura
Uno de los factores clave que se busca a la hora de implementar sistemasdistribuidos es el poder escalar la infraestructura de forma maacutes sencilla estoes detectar que las maacutequinas estaacuten alcanzando el liacutemite de su capacidad yaumentar eacutesta ya sea mejorando sus caracteriacutesticas teacutecnicas o antildeadiendo maacutesnodos al cluster
El coacutedigo y todos los ficheros de configuracioacuten de esta seccioacuten tambieacuten sepueden encontrar en el repositorio del proyecto en GitHub23
71 Disentildeo
Microsoft Azure permite organizar los servicios cloud de forma loacutegica a traveacutesde grupos de recursos y asiacute poder crear o eliminar eacutestos en conjunto parauna aplicacioacuten determinada (por ejemplo una aplicacioacuten web suele requerir demaacutequinas virtuales bases de datos almacenamiento) Ademaacutes dispone dela opcioacuten de crear plantillas en formato JSON que permite al desarrolladordefinir los recursos y su interrelacioacuten para desplegar de forma automaacutetica unainfraestructura TI en la nube
Azure tambieacuten ofrece la posibilidad de monitorizar el estado de las maacutequinasvirtuales a traveacutes de extensiones lo que permite configurar el escalado automaacute-tico al alcanzar cierto liacutemite definido por el operador Eacutesta es a priori la formaen que deberiacutea implementarse hablando en teacuterminos de eficiencia sin embargoesta aproximacioacuten es totalmente dependiente de la plataforma es decir no sepuede extrapolar a otro proveedor o sobre recursos propios sin realizar un nue-vo disentildeo En este proyecto las tareas que son ejecutadas por estos equipos notienen estado ya que todo lo relativo a la persistencia lo hemos asignado fueradel cluster esto permite escalar la plataforma a traveacutes de otra aproximaciones
Las plantillas aceptan una serie de variables a indicar por el usuario entreotras los conjuntos de escala para definir los nodos aceptan una variable quedefine el nuacutemero de maacutequinas que los componen Por otro lado Azure ofreceuna API REST y kits de desarrollo software (SDK por sus siglas en ingleacutes) quepermiten su despliegue de forma programaacutetica Aprovechando estas facilidadesen este proyecto se va a aproximar la escalabilidad con el sucesivo desplieguede la infraestructura de forma automaacutetica se monitorizan los equipos y si sedetecta una maacutequina excesivamente cargada se aumenta el nuacutemero de equiposen la plantilla y se vuelve a desplegar
23httpsgithubcomAntonioAlfrzCloud-Orchestrators
43
En este proyecto se han disentildeado las plantillas para desplegar la arquitec-tura necesaria tanto de Nomad como de DCOS En el caso de la primera eldespliegue es maacutes descriptivo ya que incluye maacutequinas virtuales grupos de se-guridad redes En el caso de DCOS Azure cuenta con un servicio especiacuteficopara clusters gobernados por DCOS denominado Azure Container Service queincluye los componentes necesarios y la instalacioacuten ya realizada
72 Implementacioacuten
En primer lugar para monitorizar el estado de los equipos se va a usar laherramienta Nagios un sistema que permite controlar el estado del hardwarey los servicios de un equipo Se trata de una herramienta muy completa de laque se va a usar su capacidad para ejecutar comandos (plugins) en los nodospara detectar picos de carga generar alertas y ejecutar programas para estoseventos
Se ha desplegado una maacutequina virtual con esta herramienta en ambos siste-mas y se ha instalado una extensioacuten de Nagios (Nagios Remote Plugin Executor)en todos los nodos que permite ejecutar comprobaciones remotamente en con-creto para esta prueba de concepto medir el nivel de saturacioacuten de la unidadcentral de procesamiento (CPU por sus siglas del ingleacutes) Cuando sucede uncambio de estado de una maacutequina esto es cuando este paraacutemetro supera el liacutemi-te definido por el operador Nagios permite actuar en consecuencia ejecutandoprogramas por ello se ha desarrollado un script que ejecuta lo siguiente
Un programa desarrollado en Python con el SDK de Azure que modificalas plantillas y despliega los recursos
Un guioacuten de Ansible para instalar todos los componentes necesarios en lasnuevas maacutequinas y arrancar de nuevo el cluster y las aplicaciones
44
8 Resultados y conclusiones
En este uacuteltimo apartado se da una visioacuten global del proyecto asiacute como a lasconclusiones maacutes importantes a las que se ha llegado y posibles temas futurosde desarrollo
81 Comparacioacuten
Ambas herramientas ofrecen las funcionalidades para gestionar los recursoseficientemente ofreciendo a los desarrolladores una plataforma donde desplegarsus aplicaciones de forma distribuida independientemente de los equipos fiacutesicosy el hardware que las soporten
DCOS es una herramienta que en un comienzo fue privativa pero cuyos res-ponsables la empresa Mesosphere decidieron publicar una versioacuten de coacutedigoEacutesta nos permite gestionar un cluster de una forma sencilla y usable ademaacutes decomplementarlo con otras herramientas como el balanceador de carga integradoo la autenticacioacuten de usuarios ademaacutes estaacute basada en Apache Mesos un pro-yecto de relativa madurez y con el soporte de la Apache Software FoundationDe forma resumida DCOS ofrece muchas posibilidades y servicios a cambiode una arquitectura e instalacioacuten maacutes compleja
Por su parte HashiCorp con menor tiempo de desarrollo ha conseguidouna herramienta muy sencilla de desplegar que ademaacutes cumple con todas lasfuncionalidades baacutesicas ejecutando un simple binario en cada nodo se puededesplegar un gestor de clusters totalmente funcional Sin embargo no cuentacon todas las posibilidades de Mesos (Nomad cuenta con menos controladoresque entornos posibles de Mesos) ni con los antildeadidos de DCOS lo que implicael uso de otras herramientas para complementar el servicio (Consul HAProxy)
De entre las dificultades encontradas al usar estas herramientas y desplegaraplicaciones sobre ellas se puede destacar la depuracioacuten en ocasiones se desco-noce si un error viene de la propia herramienta de la aplicacioacuten desplegada o delequipo fiacutesico si no se cuenta con un sistema de procesamiento de registro unose puede encontrar con muacuteltiples terminales abiertas inspeccionando numerososficheros de registro buscando posibles errores Ademaacutes no dejan de ser solucio-nes que para usar eficientemente se debe conocer parte de su funcionamientoy sintaxis a la hora de describir la tareas lo que supone un esfuerzo antildeadido yaque cada una tiene sus particularidades y liacutemites
45
82 Conclusiones
En una sociedad cada vez maacutes digital las empresas deben adaptarse a unmercado cuya demanda de contenido no deja de crecer Las nuevas arquitecturascomo microservicios asiacute como la gran cantidad de datos generada implica queuna mejor gestioacuten de los recursos y la rapidez para desplegar o escalar solucionesdando valor al cliente lo maacutes raacutepido posible es uno de los objetivos de todas lasempresas de base tecnoloacutegica
Las ventajas que ofrecen los planificadores con aplicaciones distribuidas sonnumerosas sin ir maacutes lejos empresas tan punteras como Google llevan maacutesde 10 antildeos orquestando contenedores24 Por un lado permiten aumentar elrendimiento de los equipos propios y por otro implementar un servicio comoplataforma para despliegues distribuidos sobre cualquier conjunto hardware deesta forma se provee un servicio similar al de la nube puacuteblica pero con laprincipal diferencia de que se elimina la independencia con el proveedor (vendorlock-in) esto es las aplicaciones no tienen limitaciones impuestas por eacuteste talescomo lenguaje de programacioacuten o herramientas y permite despliegues hiacutebridosentre recursos propios y la nube
83 Objetivos conseguidos
Implementacioacuten de los planificadores propuestos en la nube Se ha en-tendido y detallado el funcionamiento de estas herramientas y se hanimplementado en el servicio de infraestructura de Microsoft Azure
Despliegue de aplicaciones y servicios distribuidos Servicios que se usanactualmente en la industria del desarrollo software asiacute como una aplica-cioacuten web con una arquitectura moderna han sido desplegados de formadistribuida en los equipos cumpliendo con la funcionalidad esperada ade-maacutes de consiguiendo una alta disponibilidad
Aproximacioacuten de arquitectura escalable Se ha hecho una aproximacioacutende infraestructura escalable de forma que sea parcialmente extrapolable aotros proveedores
24httpwwwnextplatformcom20160322decade-container-control-google
46
84 Liacuteneas de investigacioacuten
Siguiendo con la materia de este proyecto se presentan posibles liacuteneas deinvestigacioacuten
Analizar el despliegue con estas herramientas de aplicaciones de Big Datay comparar la eficiencia con respecto a soluciones especializadas
Analizar el rendimiento de los algoritmos de planificacioacuten antes pruebasde estreacutes y situaciones de alta contienda
Comparar el uso de estas herramientas con las praacutecticas actuales de laindustria o implementacioacuten en un sistema de produccioacuten real
47
Referencias
[1] LA Barroso y U Houmllzle laquoThe Datacenter as a Computer An Introduc-tion to the Design of Warehouse-Scale Machinesraquo En Morgan amp ClaypoolPublishers ()
[2] Systems Research Group ndash NetOS (University of Cambridge) The evolu-tion of cluster scheduler architectures 2016 url httpswwwclcamacukresearchsrgnetoscamsasblog2016-03-09-scheduler-architectureshtml
[3] A Das I Gupta y A Motivala SWIM Scalable Weakly-consistent Infection-style Process Group Membership Protocol Inf teacutec Dept of ComputerScience Cornell University url https www cs cornell edu ~asdasresearchdsn02-swimpdf
[4] D Dubhashi y A Das Mastering Mesos PACKT Publishing mayo de2016
[5] The Apache Software Foundation Apache Mesos documentation urlhttpsmesosapacheorg
[6] David Greenberg Building Applications on Mesos OrsquoReilly Media 2016[7] Armand Grillet Comparison of Container Schedulers Inf teacutec Technische
Universitaumlt Berlin[8] HashiCorp Consul documentation url httpswwwconsulio[9] HashiCorp Nomad documentation url httpsdcosio[10] Dan C Marinescu Cloud computing theory and practice Morgan Kauf-
mann 2013[11] Mesosphere DCOS documentation url httpswwwnomadproject
io[12] Microsoft Azure documentation url httpsazuremicrosoftcom
es-esdocumentation[13] D Ongaro y J Ousterhout In Search of an Understandable Consensus
Algorithm Inf teacutec Stanford University url httpsraftgithubioraftpdf
[14] Fei Teng laquoRessource allocation and schelduling models for cloud compu-tingraquo Tesis de mtriacutea Ecole Centrale Paris 2011
[15] A Williams y col Automation and Orchestration with Docker and Contai-ners A Comprehensive Overview of the Docker and Container Ecosystem3 The New Stack 2016
48
- Resumen
- Summary
- Iacutendice de figuras
- Introduccioacuten y objetivos
-
- Contexto
- Objetivos
- Estructura del documento
-
- Cloud Computing
- Nuevas cargas de trabajo
- Gestioacuten de recursos Planificadores
-
- Sistemas distribuidos
-
- Clasificacioacuten
-
- Herramientas
-
- DCOS
-
- Apache Mesos
- Ejemplos de uso
-
- Nomad
-
- Protocolo de consenso Raft
- Protocolo gossip SWIM
- Planificacioacuten
-
- Casos de uso y despliegue
-
- Aplicacioacuten Web
-
- DCOS
- Nomad
-
- Servicio de integracioacuten continua
-
- DevOps
- Integracioacuten Continua
- Jenkins con Nomad
- Jenkins con DCOS
-
- Escalando la infraestructura
-
- Disentildeo
- Implementacioacuten
-
- Resultados y conclusiones
-
- Comparacioacuten
- Conclusiones
- Objetivos conseguidos
- Liacuteneas de investigacioacuten
-
ii
Resumen
Las empresas punteras en tecnologiacutea e innovacioacuten cuentan con numerososrecursos de computacioacuten para llevar a cabo los diversos servicios que sustentanel proceso de negocio En general a estos equipos se les asignan de forma es-taacutetica las distintas tareas lo que conlleva un uso ineficiente al no distribuirseacorde con la carga de trabajo ademaacutes del trabajo de mantenimiento que con-lleva De entre las responsabilidades de los profesionales de las tecnologiacuteas dela informacioacuten estaacute gestionar eficientemente estos recursos asiacute como garantizarla disponibilidad de estos servicios atendiendo a las diferentes demandas decapacidad
La motivacioacuten de este trabajo surge de la oportunidad de desplegar las di-ferentes tareas o servicios de una forma maacutes eficiente gracias a la evolucioacuten entecnologiacuteas como la virtualizacioacuten almacenamiento distribuido o redes definidaspor software asiacute como la mejora y el abaratamiento de los enlaces de comunica-ciones que suponen un cambio de enfoque a la hora de disentildear la infraestructurade los sistemas de informacioacuten
En particular en este proyecto se va a entrar en detalle en herramientas cuyoobjetivo es optimizar los recursos y ademaacutes dar ciertas garantiacuteas de escalabili-dad disponibilidad y tolerancia a fallos De entre las soluciones que existen enla industria hemos seleccionado dos de coacutedigo abierto que alcanzan los objeti-vos definidos DCOS desarrollada por la empresa Mesosphere y basado en elproyecto Apache Mesos y Nomad creada por Hashicorp
En primer lugar se realizaraacute un anaacutelisis del funcionamiento de estas tecno-logiacuteas al que posteriormente seguiraacute el despliegue de casos de uso en la nube yfinalmente las conclusiones a las que se han llegado comparando el rendimientode ambas Con ello se pretende dar una perspectiva de la funcionalidad de estastecnologiacuteas y como encajan en la perspectiva actual dentro de las tecnologiacuteas dela informacioacuten
Palabras clave Cluacutester Gestor de recursos Planificador Compu-tacioacuten en la nube Apache Mesos HashiCorp Nomad MesosphereDCOS
iii
iv
Summary
Tech-savvy companies have a large amount of computational resources tohandle the services that support the business process Typically tasks are al-located in these computers in a static way which is inefficient due to the factthat they are not distributed according to the workload besides involving fur-ther maintenance work Among the responsibilities of Information Technologyprofessionals is efficiently managing these resources and providing some guaran-tees of availability of those services according to the different capacity demands
The motivation of this project comes from the opportunity of efficiently dis-tributing the different tasks or services of an enterprise thanks to the evolutionof technologies such as virtualization distributed storage or software defined net-works but also with the improvement and cost reduction of the communicationlinks a potential turning point in the approach of designing IT infrastructures
This project goes into more detail on tools which pursue resource optim-ization availability scalability and fault tolerance of services Amongst theexisting solutions in the industry two open source projects have been chosenboth achieving the predefined objectives DCOS developed by the companyMesosphere and based on the Apache Mesos project and Nomad developed byHashiCorp
Firstly the internals of these two technologies will be studied followed by adeployment of use cases in both of them in the cloud Lastly the conclusionsreached comparing their performance will be described By this it is intendedto provide a perspective of the functionality of these tools and how they fit inthe nowadays perspective on Information Technology
Keywords Cluster Resource Manager Cluster Scheduler CloudComputing Apache Mesos HashiCorp Nomad Mesosphere DCOS
v
vi
Iacutendice
Resumen III
Summary V
Iacutendice de figuras IX
1 Introduccioacuten y objetivos 1
11 Contexto 1
12 Objetivos 2
13 Estructura del documento 2
2 Cloud Computing 3
3 Nuevas cargas de trabajo 5
4 Gestioacuten de recursos Planificadores 8
41 Sistemas distribuidos 8
411 Clasificacioacuten 10
5 Herramientas 13
51 DCOS 14
511 Apache Mesos 15
512 Ejemplos de uso 18
52 Nomad 19
521 Protocolo de consenso Raft 20
vii
522 Protocolo gossip SWIM 23
523 Planificacioacuten 24
6 Casos de uso y despliegue 27
61 Aplicacioacuten Web 27
611 DCOS 28
612 Nomad 33
62 Servicio de integracioacuten continua 40
621 DevOps 40
622 Integracioacuten Continua 40
623 Jenkins con Nomad 42
624 Jenkins con DCOS 42
7 Escalando la infraestructura 43
71 Disentildeo 43
72 Implementacioacuten 44
8 Resultados y conclusiones 45
81 Comparacioacuten 45
82 Conclusiones 46
83 Objetivos conseguidos 46
84 Liacuteneas de investigacioacuten 47
viii
Iacutendice de figuras
1 Comparacioacuten Centro de datos - Computacioacuten en la nube 4
2 Arquitectura Docker 6
3 Planificador monoliacutetico 11
4 Planificador de dos niveles 11
5 Planificador de estado compartido 12
6 Planificador distribuido 12
7 Arquitectura DCOS 14
8 Servicios DCOS 15
9 Arquitectura de Apache Mesos 17
10 Arquitectura multi-regioacuten en Nomad 20
11 Equipos sin consenso ejecutando el protocolo RAFT 21
12 Un equipo pasa a estado candidato (RAFT) 22
13 Cambio en un registro (RAFT) 22
14 Aprobacioacuten del resto de equipos (RAFT) 23
15 Diagrama de tiempo del protocolo SWIM 24
16 Procedimiento de asignacioacuten en Nomad 25
17 Arquitectura aplicacioacuten web 28
18 Infraestructura en Azure 29
19 Arquitectura de la aplicacioacuten web en DCOS 32
20 Despliegue en Azure de Nomad+Consul 35
ix
1 Introduccioacuten y objetivos
11 Contexto
Las tecnologiacuteas de la informacioacuten y la comunicacioacuten estaacuten suponiendo uncambio draacutestico en la sociedad en 2007 comenzaron a aparecer los teleacutefonosinteligentes tal y como los conocemos y nueves antildeos despueacutes se empieza a con-cebir la idea de dar conectividad a todo dispositivo electroacutenico movimiento queha tomado el nombre de Internet de las cosas Para hacerse una idea de la rapi-dez y magnitud de esta evolucioacuten la consultora Excelacom1 ha estimado que enun minuto se realizan 24 millones de buacutesquedas en Google o se ven 278 millonesde viacutedeos en Youtube En una eacutepoca en la que los recursos tecnoloacutegicos crecenexponencialmente y los usuarios demandan mayor contenido y movilidad nocabe duda que las empresas deben adaptarse lo maacutes raacutepidamente posible a esteproceso de digitalizacioacuten movidas por las nuevas necesidades de las personas
Dado el gran volumen de informacioacuten a lo largo de estos antildeos la compu-tacioacuten y el almacenamiento estaacuten pasando de clientes locales a concentrarse engrandes centros de datos una tendencia que Google ha denominado ldquoWarehouse-scale computingrdquo en 2009[1] Este movimiento hacia la computacioacuten desde ser-vidor no solo viene de la necesidad de mejorar la experiencia de los usuariossino tambieacuten de facilitar la gestioacuten y configuracioacuten de los recursos asiacute como laubicuidad de acceso que permite
En 2006 Amazon lanza Amazon Web Services siendo uno de los pionerosen el mercado de los recursos virtuales ofreciendo capacidad de computacioacutencon un coste proporcional exclusivamente a los recursos utilizados Todo ellocambioacute la perspectiva de los modelos tradicionales de TI a la conocida comocomputacioacuten en la nube recursos informaacuteticos que antes suponiacutean barrerasde entrada en ciertos mercados han pasado a ser condicioacuten necesaria para laconstante evolucioacuten de la tecnologiacutea y la sociedad De hecho Cisco estima quepara el antildeo 2019 maacutes del 86 de las cargas de trabajo seraacuten procesadas porcentros de datos en la nube2
1httpwwwexcelacomcomresourcesblog2016-update-what-happens-in-one-internet-minute2httpwwwciscocomcenussolutionscollateralservice-provider
global-cloud-index-gciCloud_Index_White_Paperpdf
1
12 Objetivos
El propoacutesito de este proyecto es estudiar la viabilidad del uso de planifica-dores de recursos para aumentar la eficiencia de eacutestos y facilitar al desarrolladorel despliegue de aplicaciones de forma distribuida y asiacute ofrecer un servicio ca-racterizado por una alta disponibilidad y escalabilidad
A lo largo de este trabajo se han usado algunas de las herramientas quese estaacuten comenzando a desarrollar para hacer frente a este nuevo enfoque degestioacuten de infraestructuras de las tecnologiacuteas de la informacioacuten (en adelanteinfraestructuras TI) realizando pruebas de concepto sobre cada una de ellas
13 Estructura del documento
A continuacioacuten se detalla las secciones que componen este trabajo La es-tructura queda como sigue
Cloud computing Se entra en detalle en este nuevo modelo de negocio queha originado nuevos enfoques y disentildeos de las infraestructuras TI dentrode las organizaciones
Nuevas cargas de trabajo Se explican algunas tecnologiacuteas representativasque estaacuten suponiendo un desafiacuteo para los profesionales de TI a la horade planificar los recursos y que se ven beneficiadas por entornos de tipocloud
Gestioacuten de recursos Planificadores Estado del arte de las tecnologiacuteas degestioacuten de clusters y planificacioacuten de recursos
Herramientas Descripcioacuten detallada del funcionamiento y arquitectura de lasherramientas usadas a lo largo del proyecto
Casos de uso y despliegue Se describe el proceso de implementacioacuten de unaaplicacioacuten web y un servicio de integracioacuten continua con el software pro-puesto
Escalando la infraestructura Se propone un procedimiento con cierta inde-pendencia del proveedor cloud
Resultados y conclusiones Resume las ideas y hechos a los que se ha llegadoademaacutes de introducir liacuteneas de investigacioacuten futuras
2
2 Cloud Computing
El NIST (National Insitute of Standards and Technology) define este con-cepto como un modelo que permite un acceso ubicuo y bajo demanda de formaremota a un conjunto compartido de recursos de computacioacuten que pueden seraprovisionados y liberados con unos miacutenimos esfuerzos de gestioacuten por parte delproveedor del servicio3
Clasificacioacuten
La computacioacuten en la nube abarca una amplia variedad de servicios y enfo-ques por lo que en primer lugar se va a dar una clasificacioacuten para posterior-mente entrar maacutes en detalle Existen distintos modelos de nube atendiendo a lagobernabilidad de la infraestructura seguacuten el NIST
Nubes puacuteblicas Los servicios y recursos son ofertados de forma puacuteblica yson provistos por una organizacioacuten que los comercializa bajo demanda
Nube privada Los recursos son gestionados por una uacutenica organizacioacutenpara su propio uso
Nube comunitaria En este caso la infraestructura es administrada por unconjunto de organizaciones con objetivos comunes
Nube hiacutebrida Una combinacioacuten de las anteriores
A su vez los distintos servicios que ofrece se pueden clasificar atendiendo algrado de control del usuario
Servicios de software (Software as a Service SaaS) El proveedor se encargade toda la gestioacuten de la infraestructura y oferta aplicaciones a las cuales elcliente puede acceder de forma ubicua a traveacutes de diversos clientes comoun navegador web Por ejemplo Office 365 o Google docs
Servicios de plataforma (Platform as a Service PaaS) Modelo de distribu-cioacuten que ofrece la capacidad de desplegar aplicaciones desarrolladas por elcliente usando las herramientas y lenguajes de programacioacuten soportadaspor el proveedor pero sin la posibilidad de gestionar los recursos consu-midos En este caso el cliente solo tiene control sobre la propia aplicacioacuteny algunas configuraciones del entorno Es el caso de Heroku o Google AppEngine
3httpnvlpubsnistgovnistpubsLegacySPnistspecialpublication800-145pdf
3
Servicios de infraestructura (Infrastructure as a Service IaaS) Se ofertanrecursos de computacioacuten puros como procesamiento o almacenamientomediante una plataforma de virtualizacioacuten El cliente puede controlar elsistema operativo componentes de red y aplicaciones
Figura 1 Comparacioacuten Centro de datos - Computacioacuten en la nubeFuente httpsad-hocnet
De entre las numerosas ventajas que ofrece la computacioacuten en la nube se puededestacar su flexibilidad ya que permite aprovisionar recursos y adaptarlos deacuerdo a la demanda reduce el capital inmovilizado y su amortizacioacuten laubicuidad que permite su consumo desde cualquier parte con conexioacuten a la redy la seguridad y fiabilidad que ofrece el proveedor que normalmente cuenta conrecursos geograacuteficamente distribuidos frente a la gestioacuten y mantenimiento derecursos propios
4
3 Nuevas cargas de trabajo
Las organizaciones que cuentan con sus propios infraestructuras TI han co-menzado a adoptar un enfoque de nube privada para gestionar las tareas ofunciones informaacuteticas sobre las que se sustentan el negocio ya que una es-tructura virtualizada puede ofrecer ventajas con respecto a las adaptaciones decentros de datos tradicionales en los aacutembitos de rendimiento escalabilidad eincluso seguridad4
A su vez se han desarrollado nuevas tecnologiacuteas que suponen cargas detrabajo dinaacutemicas y con gran intensidad de consumo de datos para las empresasque se ven beneficiadas al desplegarlas en recursos virtualizados
Big data
Con la creciente aceptacioacuten de las tecnologiacuteas TIC por parte de la sociedadla cantidad de datos generados en la red es ingente Las profesionales de TI tienecomo objetivo extraer valor de eacutestos para por ejemplo prever las tendencias delmercado Sin embargo este incremento exponencial hace que su procesamientoy almacenamiento requiera de un sistema con gran escalabilidad dado el hechode que una sola maacutequina no puede proveer de la capacidad necesaria
Integracioacuten continua
Modelo informaacutetico que consiste en hacer integraciones automaacuteticas de unproyecto con cualquier cambio en el coacutedigo con el objetivo de detectar fallosde forma temprana Esto implica la compilacioacuten del coacutedigo y su ejecucioacuten enun entorno de pruebas automaacuteticamente un proceso que mediante tecnologiacuteasde virtualizacioacuten permiten simular entornos con eficiencia y rapidez Su imple-mentacioacuten en sistemas distribuidos permite tanto una mejor planificacioacuten comoun mejor rendimiento de los recursos
Arquitectura de microservicios
Enfoque para desarrollar aplicaciones software como un conjunto de serviciosautoacutenomos que se comunican entre siacute a diferencia de aproximaciones monoliacuteti-cas donde la loacutegica del servicio estaacute desarrollada como una unidad Un sistemadistribuido permite el despliegue de los componentes en distintas maacutequinas loque mejora tanto su escalabilidad como la tolerancia a fallos
4httpswwwakamaicomesesresourcespublic-private-cloudjsp
5
Docker
Proyecto de coacutedigo abierto que facilita y automatiza el despliegue de aplica-ciones al encapsular el entorno de trabajo en contenedores Linux una tecnologiacuteaque permite a un sistema fiacutesico ejecutar muacuteltiples instancias de sistemas opera-tivos aislados mediante entornos virtuales con sus propios espacios de procesosy redes pero compartiendo el nuacutecleo (kernel) con el equipo anfitrioacuten
En la figura 2 se compara la pila de una virtualizacioacuten tradicional con res-pecto a los contenedores no se simula el sistema operativo por lo que el procesoes mucho maacutes ligero
Docker se caracteriza por
Autosuficiencia Los contenedores cuentan con las libreriacuteas y configuracio-nes necesarias para ejecutarse de manera autoacutenoma al compartir el nuacutecleo
Portabilidad El hecho de que sean autosuficientes implica que es inde-pendiente del host es decir se puede desplegar en cualquier equipo quesoporte esta tecnologiacutea
Tamantildeo El peso de un contenedor es sustancialmente inferior a otrastecnologiacuteas de virtualizacioacuten
Figura 2 Arquitectura DockerFuente httpsdockercom
6
Los componentes fundamentales de esta herramienta son
Imaacutegenes Describen el entorno de base sobre el que ejecutar el contene-dor por ejemplo la imagen del sistema operativo Ubuntu Sobre eacutesta seconstruyen las aplicaciones particulares del usuario dando lugar a otraimagen
Contenedores Se crean a partir de las imaacutegenes y comprenden todo aquellonecesario para arrancar la aplicacioacuten decir su entorno de ejecucioacuten
bull Voluacutemenes Encargados de gestionar la persistencia de datos e inde-pendientes del ciclo de vida del contenedor
Registros Pueden ser puacuteblicos o privados y almacenan las imaacutegenes elregistro puacuteblico oficial de Docker es Docker Hub
Dadas estas caracteriacutesticas los profesionales TI estaacuten comenzando a adoptarDocker ya que facilita tanto los despliegues como el trabajo compartido en dis-tintos entornos Sin embargo esto requiere de un software que permita desplegarlos distintos contenedores de forma que puedan trabajar en conjunto procesoque se ha denominado orquestacioacuten de contenedores
7
4 Gestioacuten de recursos Planificadores
Para sacar el maacuteximo provecho a las tecnologiacuteas anteriormente descritaslo ideal es desplegarlas en sistemas distribuidos sin embargo esto aumenta lacomplejidad del propio despliegue asiacute como la necesidad de software especiali-zado para ello Se necesitan algoritmos de planificacioacuten que permitan obtener elmaacuteximo rendimiento de los recursos por un lado y dar ciertas garantiacuteas de quetodas las tareas y procesos se van a ejecuta por otro
41 Sistemas distribuidos
En primer lugar se definen los sistemas distribuidos o clusters como unconjunto de ordenadores conectados entre siacute cuyo objetivo es trabajar como unauacutenica instancia de gran capacidad5
Su clasificacioacuten variacutea de acuerdo a cada autor pero en general se puedendividir seguacuten su objetivo en alto rendimiento aquellos cuyo objetivos es proveerde gran capacidad de coacutemputo gracias al conjunto de los nodos y alta disponi-bilidad con los cuales se busca la fiabilidad del sistema mediante redundanciayo balanceo de carga
El intereacutes de este proyecto recae en los uacuteltimos ya que el objetivo es porun lado ofrecer al desarrollador un entorno donde desplegar sus aplicaciones deforma distribuida y por otro maximizar el rendimiento de los recursos
De forma general las caracteriacutesticas que se buscan son las siguientes
Elasticidad Adaptacioacuten a cargas dinaacutemicas de trabajo aumentando (o dis-minuyendo) recursos de manera automaacutetica de tal forma que la utilizacioacutensea lo maacutes cercana a la demanda
Disponibilidad Capacidad de un sistema para mantener el servicio fun-cional
Tolerancia a fallos Recuperacioacuten del servicio ante el fallo de un compo-nente
Balanceo de carga Compartir las tareas entre las diferentes maacutequinasredundadas evitando asiacute puntos de uacutenico fallo
5httpsenwikipediaorgwikiComputer_cluster
8
Los programas que se implementan en entornos distribuidos se caracterizanpor ejecutarse de forma concurrente en equipos independientes estar conectadospor una red que introduce fallos aleatorios y no compartir memoria ni reloj Estoimplica entre otras cosas que
Los nodos soacutelo tienen un acceso raacutepido a su memoria local por lo quecualquier informacioacuten relativa al estado global puede ser potencialmenteerroacutenea
Las maacutequinas pueden sufrir caiacutedas de forma aleatoria
El intercambio de informacioacuten puede fallar ya sea por error en transmisioacuteno por caiacuteda de los nodos
Estas dificultades se ponen de manifiesto en el teorema de CAP en cienciasde la computacioacuten el teorema de CAP que lanzado inicialmente como conjetu-ra en el antildeo 2000 por Eric Brewer (motivo por el cual al teorema se le conoceformalmente como teorema de Brewer) y posteriormente demostrado en el antildeo20026 establece que es imposible para un sistema de coacutemputo distribuido ga-rantizar simultaacuteneamente dos de las tres propiedades siguientes
Consistencia (Consistency) es decir que todos los nodos vean la mismainformacioacuten al mismo tiempo Se busca que un cambio en el sistema soacutelose ejecute satisfactoriamente si y soacutelo si se efectuacutea a todos las maacutequinasde tal forma que los datos entre ellos nunca difieren y la respuesta a unapeticioacuten sea la misma independientemente del nodo que la atienda
Disponibilidad (Availability) esto es la garantiacutea de que toda peticioacuten debeobtener una respuesta (servicio funcional) aunque exista inconsistenciaentre nodos
Tolerancia al particionado (Partition Tolerance) es decir que el sistemasiga funcionado a pesar de un fallo en la comunicacioacuten entre los equipos
Por todo lo expresado anteriormente conseguir un sistema distribuido capazde ofrecer procesamiento de forma transparente implica una arquitectura TIcompleja Se requieren de subsistemas y herramientas que permitan la cohesioacutenentre todos los nodos
Gestor de los recursos de las diferentes maacutequinas
Monitorizacioacuten tanto de los servicios activos como de la funcionalidad delsistema ademaacutes de poliacuteticas para recuperacioacuten de fallo
Protocolos de consenso que permitan a los nodos ser consistentes con elestado global del cluster
6urlhttpsgroupscsailmitedutdspapersGilbertBrewer2pdf
9
Herramientas de descubrimiento de servicios que permita la comunicacioacutenentre tareas distribuidas
Planificadores Encargados de distribuir las tareas y procesos en las dife-rentes maacutequinas asignaacutendole parte de su capacidad
Los planificadores del ingleacutes cluster schedulers son un componente funda-mental por lo que vamos a entrar un poco maacutes en detalle en ellos
Planificadores (Cluster Schedulers)
Es el software encargado de monitorizar los recursos usados por cada maacute-quina perteneciente a un cluster y distribuir la carga de trabajo entre ellas deacuerdo a un poliacutetica o reglas
Este tipo de herramientas comparten cierta terminologiacutea que es relevantedefinir
Tarea Unidad de trabajo computacional comprendida por una secuenciade instrucciones datos de entrada y recursos asociados Por ejemplo laejecucioacuten de un comando o el arranque de una base de datos
Nodo Cualquier maacutequina integrante de un cluster En una arquitecturamaestro-esclavo se definen dos roles
bull Cliente Agente Esclavo Aquellos ordenadores que se encargan deejecutar las tareas
bull Maestro Servidor Su objetivo es mantener el estado del cluster ygestionar sus recursos
411 Clasificacioacuten
A lo largo de los uacuteltimos antildeos se han desarrollado diferentes tipos de plani-ficadores[2]
Monoliacutetico
Un solo planificador que se encarga de distribuir todas las tareas entran-tes La mayoriacutea de los planificadores en computacioacuten de alto rendimiento asiacutecomo Borg desarrollado por Google son de este tipo En la figura 3 se pue-de observar de forma graacutefica el procedimiento siendo las cajas grises maacutequinaspertenecientes al cluster y los ciacuterculos las tareas a asignar
10
Figura 3 Planificador monoliacuteticoFuente httpswwwclcamacuk
Planificacioacuten de dos niveles
La mayoriacutea de los clusters ejecutan aplicaciones con distintas necesidadesdesde procesos casi instantaacuteneos hasta servicios persistenteslo que implica dis-tintas necesidades de recursos
Por ello la planificacioacuten a dos niveles distingue dos funciones la gestioacutende recursos (gestor) y la disposicioacuten de las tareas (planificador) Cada serviciotiene su propio planificador de tal manera que el gestor les ldquoofertardquo recursosde acuerdo a una poliacutetica y los planificadores se encargan de escoger la maacutesadecuada Esto permite que el proceso de distribucioacuten sea maacutes acorde con lasnecesidades de los diferentes servicios Apache Mesos que detallaremos maacutesadelante sigue este esquema
Como desventaja cabriacutea sentildealar que esta programacioacuten implica que los pla-nificadores pierden la vista general de la infraestructura y las tareas soacutelo puedenejecutarse con los recursos que les son ofrecidos lo que dificulta la implementa-cioacuten de prioridades de ejecucioacuten de tareas entre otras
Figura 4 Planificador de dos niveles
11
Planificacioacuten de estado compartido
Muacuteltiples reacuteplicas del estado del cluster se actualizan independientementepara cada planificador como se observa en la figura 5 cuando sucede un cambiode forma local el planificador se encarga de informar al resto
Ejemplo de este tipo son Omega la evolucioacuten de Borg por parte de GoogleMicrosoft Apollo y Nomad que usaremos para los casos de uso
De entre las desventajas se puede destacar el hecho de que en general losnodos trabajan con informacioacuten desactualizada lo que conlleva una degradacioacutendel rendimiento en situaciones de alta contienda
Figura 5 Planificador de estado compartido
Planificacioacuten distribuida
En este caso no existe coordinacioacuten entre los distintos planificadores Cadauno de ellos funciona con su propia vista del cluster Las tareas pueden serorganizadas por cualquiera de ellos y desplegadas en cualquier parte del clusteren base a la aleatoriedad y multiplexacioacuten estadiacutestica de los flujos de trabajosin ninguacuten control central
Figura 6 Planificador distribuido
12
5 Herramientas
En la industria comienzan a aparecer soluciones software de coacutedigo abiertoque aglutinan los servicios necesarios para gestionar la infraestructura TI de ma-nera maacutes eficaz El objetivo es doble se busca facilitar la gestioacuten de los recursosde computacioacuten para organizaciones con instalaciones propias mediante su usocon un enfoque cloud esto es desplegar aplicaciones a traveacutes de un conjuntode ordenadores de forma transparente y sin tener en cuenta la infraestructurasubyacente o aprovechar el maacuteximo rendimiento de la infraestructura de losproveedores cloud puacuteblicos de forma que se tiene el maacuteximo control sobre eacutestapero no se depende de las soluciones propietarias permitiendo asiacute despliegueshiacutebridos
Entre estas herramientas se pueden destacar
OpenStack Proyecto desarrollado por la fundacioacuten del mismo nombre paraproporcionar servicios de infraestructuras (IaaS) basado en componentesque se comunican a traveacutes de APIs El componente Magnum incluye mo-tores de orquestacioacuten de contenedores
Kubernetes Sistema de orquestacioacuten de contenedores Docker creado por Goo-gle
CoreOs Sistema operativo basado en Linux disentildeado para despliegues distri-buidos sobre contenedores incluyendo mecanismos de descubrimiento deservicio y comparticioacuten de configuracioacuten
Docker Swarm Herramienta nativa de orquestacioacuten de contenedores Docker
YARN Entorno de gestioacuten de recursos y aplicaciones distribuidas de Hadoopuna libreriacutea software de procesamiento de grandes conjuntos de datos
Como podemos observar existe un gran rango de opciones para gestionar lainfraestructura desde un bajo nivel como puede ser OpenStack hasta Kuberne-tes o Docker Swarm que ofrecen exclusivamente orquestacioacuten de contenedores
En este trabajo se ha optado por Mesosphere DCOS y HashiCorp Nomadque se encuentran en el teacutermino medio su objetivo es proporcionar serviciosde plataforma que permitan la coexistencia dediferentes cargas de trabajo en elcluster
13
51 DCOS
DCOS es un proyecto de coacutedigo abierto7 creado y desarrollado por la empre-sa Mesosphere Se describe como un sistema operativo distribuido que abstraelos recursos de un cluster (capacidad de procesamiento memoria) permite lagestioacuten de muacuteltiples ordenadores de forma transparente y simplifica la instala-cioacuten de aplicaciones distribuidas
Su arquitectura se puede comparar a la de Linux en teacuterminos de nuacutecleo(kernel) y espacio de usuario El primero consta de recursos protegidos a losque no puede acceder el usuario e involucra operaciones de bajo nivel comoasignacioacuten de recursos o aislamiento de procesos En el espacio de usuario seejecutan las aplicaciones y servicios de maacutes alto nivel
Siguiendo con este siacutemil el nuacutecleo de DCOS estaacute basado en Apache Mesosque se explicaraacute en un apartado posterior y el espacio de usuario que estaacute com-prendido por los componentes del sistema esto es las diferentes herramientasque en conjunto conforman DCOS y los servicios encargados de planificar yejecutar las aplicaciones y tareas del usuario
Figura 7 Arquitectura DCOSFuente httpsdcosio
De entre los componentes que conforman DCOS destacan
Admin Router Balanceador de carga central basado en NGINX que dis-pone un proxy entre todos los servicios en el puerto 80 permitiendo sugestioacuten mediante la interfaz graacutefica Ademaacutes se encarga de la autenticacioacutenpara acceder al panel de administracioacuten
Cosmos Gestor de paquetes de las aplicaciones
Diagnostics Se ejecuta en todos los nodos y se encarga de monitorizar elestado de los daemons que sustentan DCOS
7Desde abril de 2016 httpsmesospherecomblog20160419open-source-dcos
14
Exhibitor Gestiona y automatiza el despliegue de ZooKeper la herra-mienta que provee de configuracioacuten centralizada y registro de nombres
Marathon Equivale al proceso init de los sistemas tipo Unix esto es elprimer proceso en ejecucioacuten tras la carga del kernel y que genera los demaacutesprocesos Se encarga de arrancar y monitorizar las aplicaciones y servicios
Mesos-DNS Servicio de DNS interno que define el dominio mesos pa-ra nodos y tareas en el cluster es decir permite resolver nombres conindependencia de la direccioacuten fiacutesica
Minuteman Balanceador de carga integrado a nivel TCPUDP disponiblepara las propias aplicaciones
Por otra parte se definen como servicios a las diferentes aplicaciones dis-tribuidas que DCOS permite instalar en el cluster y que pueden haber sidodesarrollados por la misma empresa Mesosphere o por terceros por ejemploApache Spark Jenkins o Apache Hadoop En la figura 8 se muestra un diagramade los servicios disponibles incluyendo algunos de las aplicaciones distribuidasque soporta DCOS
Figura 8 Servicios DCOSFuente httpsdcosio
511 Apache Mesos
El nuacutecleo de DCOS estaacute basado en Apache Mesos un proyecto de coacutedigoabierto creado por la Universidad de California Berkeley y desarrollado actual-mente por la fundacioacuten Apache Se trata de un administrador de clusters queabstrae los recursos y los dispone para diferentes aplicaciones y entornos de tra-bajo distribuidos (frameworks) mediante una interfaz comuacuten En el momento deredaccioacuten de este proyecto Apache Mesos soportaba una variedad de entornosque abarcaba desde Big Data (Apache Spark Hadoop) hasta bases de datos(Cassandra Hypertable)
15
Arquitectura
Mesos se basa en la asignacioacuten de dos roles diferentes a los nodos
Maestros (Masters) Se encargan de la gestioacuten y reparticioacuten de los recursospara los diferentes entornos de trabajo mediante ldquoofertas de recursosrdquo deacuerdo a los disponibles y a la poliacutetica de asignacioacuten (planificacioacuten en dosniveles)
Esclavos (Slaves) Ordenadores donde se ejecutaraacuten las aplicaciones y cu-yos recursos son ofertados por los maestros
En el caso de fallo del maestro las tareas pueden seguir ejecutaacutendose perono se podraacute asignar nuevos recursos ni tareas por ello pueden existir varios enel cluster para configuraciones de alta disponibilidad pero soacutelo uno orquesta alos esclavos
Para la eleccioacuten del master liacuteder Mesos usa Apache ZooKeeper un proyectode software desarrollado por la misma fundacioacuten cuyo objetivo es proveer deun servicio de configuracioacuten centralizado y registro de nombres8
Por otra parte los entornos de trabajo son los programas que deciden final-mente queacute recursos se van a usar y se encargan de que los esclavos ejecuten lastareas Eacutestos se ejecutan sobre Mesos y constan de dos componentes
Planificador (Scheduler) Optimiza y decide los recursos a utilizar de losofertados informando a los Masters
Procesador (Executor) Ejecuta las aplicaciones o servicios en los esclavos
El objetivo final es conseguir una interfaz liviana tolerante a fallos paracualquier tipo de entorno de trabajo de tal manera que en los esclavos del clusterpuedan ejecutarse simultaacuteneamente tareas con necesidades y duracioacuten diferentesPara ello se basa en dos conceptos asignacioacuten y aislamiento de recursos
Asignacioacuten de recursos
En el cluster pueden coexistir entornos de trabajo con tareas de larga dura-cioacuten y con gran consumo de recursos con tareas cortas que los ocupan y liberancon rapidez El maestro integra un moacutedulo de asignacioacuten de recursos (allocationmodule) que se encarga del algoritmo de distribucioacuten
En el momento de escribir este proyecto estaban desarrollados dos moacutedulosuno mediante el cual el usuario puede asignar prioridades y otro que implementa
8httpszookeeperapacheorg
16
el algoritmo Dominant Resource Fairness9 a grandes rasgos se determina entodos los esclavos la tarea en ejecucioacuten que necesita maacutes recursos y se calcula laproporcioacuten del recurso de mayor peso con respecto al total por ejemplo si unatarea ocupa 2 GB de memoria con respecto a 10 GB totales que tiene el clusterse le asigna un dominant share del 20 la tarea se asignaraacute al nodo con menordominant share
Aislamiento de recursos
Para conseguir que tareas de diferentes entornos de trabajo y con distin-ta naturaleza se ejecuten simultaacuteneamente en un mismo nodo Mesos usa loscontenedores Linux (descritos en la seccioacuten 3)
Funcionamiento
La figura 9 muestra el esquema de la arquitectura de Apache Mesos conalta disponibilidad (tres maestros) y con dos entornos de trabajo ejecutaacutendo-se Hadoop que permite el almacenamiento y procesamiento de gran cantidadde datos para proyectos de big data y un sistema que implementa la interfazsistema de paso de mensajes MPI
Como se puede observar el sistema ZooKeeper elige a un solo maestro comoliacuteder y eacuteste orquesta el cluster comunicando los esclavos con los planificadoresde los diferentes entornos de trabajo Tambieacuten se puede observar como las tareasde los distintos entornos estaacuten distribuidas entre los tres esclavos disponibles
Figura 9 Arquitectura de Apache MesosFuente httpsmesosapacheorg
El proceso de asignacioacuten se realiza como sigue en primer lugar un usuariosolicita la ejecucioacuten de una tarea mediante la interfaz de cada entorno de traba-jo (interfaz graacutefica API HTTP ) De forma paralela un esclavo informa almaestro de los recursos que tiene libres En consecuencia eacuteste se lo notifica almoacutedulo de asignacioacuten que en funcioacuten de su configuracioacuten decide cuaacutento ofertar
9httpspeopleeecsberkeleyedu~aligpapersdrfpdf
17
y a queacute entorno de trabajo y enviacutea la oferta a los planificadores Eacutestos respondenal maestro con queacute recursos ha decidido usar para cada tarea Finalmente lastareas son enviadas al esclavo seleccionado el cual asigna los recursos indicadosal procesador (executor) quien finalmente las ejecuta
Cabriacutea pensar que esta metodologiacutea puede conducir a situaciones en lasque un entorno podriacutea quedarse con tareas sin ejecutarse a la espera de unaoferta satisfactoria para ello Mesos implementa un sistema de filtros medianteel cual los entornos especifican los requisitos miacutenimos que debe cumplir unaoferta por ejemplo se puede especificar en queacute nodos debe desplegarse la tareaEste sistema estaacute disentildeado asiacute con el objetivo de mantener lo maacutes transparenteposible esta herramientas de forma que acepte entornos de trabajo de distintasnaturalezas
512 Ejemplos de uso
Grandes empresas estaacuten usando Apache Mesos con eficacia de acuerdo a susnecesidades e infraestructuras Caben destacar
Ebay En el modelo de implementacioacuten continua en esta empresa10 cadadesarrollador cuenta con su propia instancia que se ejecuta en una maacutequinavirtual dedicada lo que ha conllevado un uso de los recursos poco eficiente Enuna prueba de concepto consiguieron realizar una herramienta de integracioacutencontinua distribuida basada en un cluster con Apache mesos y con el entornoMarathon y Jenkins
Apple Anuncioacute que el motor de su famosa herramienta de asistencia per-sonal para iPhones Siri estaacute desplegada sobre Apache Mesos11 Para ello handesarrollado su propio entorno para facilitar a los ingenieros a desplegar los ser-vicios que la herramienta necesita para resolver las peticiones de los usuarios
Twitter Desarrolloacute su propio entorno denominado Aurora y actualmentegestionan sus recursos y miden el coste de las tareas que los empleados usancon el objetivo de que sean conscientes del gasto que puede suponer un usoinadecuado de la infraestructura12
10httpwwwebaytechblogcom20140404delivering-ebays-ci-solution-with-apache-mesos-part-i11httpwwwbusinessinsidercomapple-siri-uses-apache-mesos-2015-812httpswwwlinuxcomNEWS4-UNIQUE-WAYS-UBER-TWITTER-PAYPAL-AND-HUBSPOT-USE-APACHE-MESOS
18
52 Nomad
Herramienta de coacutedigo abierto de gestioacuten de clusters creada y desarrolladapor Hashicorp13 que permite el despliegue de aplicaciones y procesos de formadistribuida
Las principales diferencias con Apache Mesos a grandes rasgos son
Arquitectura maacutes ligera Nomad soacutelo requiere de un fichero para funcionarejecutaacutendolo con las correspondientes configuraciones en todos los nodosrealiza las funciones de gestioacuten del cluster eleccioacuten de liacuteder planificacioacutende recursos y ejecucioacuten de las tareas
Centro de datos y regiones muacuteltiples Su arquitectura estaacute orientada afacilitar la gestioacuten de diferentes centros de datos geograacuteficamente distri-buidos
Entorno de ejecucioacuten Las tareas se definen y son interpretadas mediantecontroladores integrados en Nomad que se valen de los recursos y herra-mientas de los nodos clientes para ejecutarlas Esta integracioacuten dificultael desarrollo de controladores por parte de terceros a diferencia de Mesosque delega dicha responsabilidad en los entornos de trabajo externos alproyecto
Usa un planificador de estado compartido con respecto a la planificacioacutenen dos niveles de Mesos
Antes de entrar en maacutes detalle en la arquitectura es importante definir lossiguientes teacuterminos
Controlador (Driver) Software que se encarga de interpretar las definicionesde las tareas y ejecutarlas semejante a los procesadores de los entornosde trabajo de Mesos A la hora de redactar este proyecto Nomad contabacon controladores para contenedores Docker virtualizacioacuten de maacutequinasmediante el emulador QEMU aplicaciones java y archivos binarios
Grupo de trabajo (Task Group) Conjunto de tareas que se ejecutan en elmismo nodo cliente
Trabajo (Job) Conjunto loacutegico de tareas y grupos de trabajo que se despliegana la vez
Asignacioacuten (Allocation) Relacioacuten entre un grupo de trabajo y el cliente don-de se ejecuta
Evaluacioacuten (Evaluation) Proceso mediante el cual Nomad planifica y ges-tiona el registro o actualizaciones de los trabajos
13httpswwwhashicorpcom
19
Nomad sigue una arquitectura maestro-esclavo similar a la de Apache Mesosmuacuteltiples servidores acuerdan entre siacute un liacuteder que gestiona la planificacioacuten detareas en los clientes que soacutelo conocen sus asignaciones y las ejecutan
Todos los servidores participan paralelamente en tareas de planificacioacuten derecursos y asignacioacuten de tareas y ademaacutes entre ellos eligen un liacuteder que seencarga de la coordinacioacuten de la suscripcioacuten de los clientes al cluster y de lagestioacuten de las peticiones
Los clientes estaacuten configurados para comunicarse con el servidor usando lla-madas a procedimiento remoto (RPC por sus siglas en ingleacutes) que permite unordenador ejecutar coacutedigo en otra maacutequina Mediante esta tecnologiacutea los nodosclientes avisan de su estado e informa de sus asignaciones recursos y controla-dores disponibles
Existe la posibilidad de gestionar varios centros de datos agrupados en regio-nes eacutestas son independientes pero permite definir tareas o comprobar el estadode todas ellas desde cualquier punto A continuacioacuten se muestra una figura dela arquitectura a alto nivel de esta configuracioacuten
Figura 10 Arquitectura multi-regioacuten en NomadFuente httpswwwnomadprojectio
La herramienta se sustenta sobre tres protocolos fundamentales un protocolode consenso entre los servidores para compartir informacioacuten sobre su estado yel liacuteder un protocolo Gossip para la gestioacuten entre regiones y el planificador detareas
521 Protocolo de consenso Raft
El objetivo es obtener consistencia en un conjunto de nodos que comparteninformacioacuten es decir si un cliente realiza un cambio que todos los nodos veanla misma informacioacuten a la vez y ademaacutes sea tolerante a fallos Para ello se basaen el algoritmo Raft[13] que se detalla brevemente a continuacioacuten
20
Los nodos participantes en el algoritmo pueden estar en tres estados
Liacuteder (Leader) Todos los cambios que realicen en el cluster pasan por eacutel pri-mero
Seguidor (Follower) Nodo pasivo cuya responsabilidad es responder a laspeticiones del nodo liacuteder
Candidato (Candidate) Maacutequina que no ha encontrado liacuteder y solicita sueleccioacuten
Supongamos que tenemos cinco equipos que acaban de arrancar el protocoloEn la figura 11 se observan los nodos y sus respectivos registros a la derecha
Figura 11 Equipos sin consenso ejecutando el protocolo RAFTFuente httpsgithubcomongardieraftscope
Al comenzar todos los nodos son seguidores esperando recibir comunicacioacutende un nodo que actuacutee como liacuteder Cada nodo tiene un tiempo de espera aleatoriodespueacutes del cual si no es informado por un liacuteder pasa a estado candidato y pideel ldquovotordquo al resto de los participantes El algoritmo divide el tiempo en plazos uncandidato pasa a liacuteder si recibe la mayoriacutea de los votos en un plazo determinadoSe define mayoriacutea o cuoacuterum (quorum) comolceil
N2rceil
+ 1 (1)
donde N representa el nuacutemero de nodos
Para el ejemplo propuesto de 5 equipos se requieren de 3 votos Soacutelo losnodos que se encuentren en estado seguidor pueden votar una uacutenica vez a laprimera solicitud que reciba dentro de un plazo
Supoacutengase que el nodo denotado con S1 ha cumplido su tiempo de espera yrealiza la peticioacuten de voto (figura 12) A partir de este momento se pueden dartres casos
La maacutequina gana la eleccioacuten y pasa a ser liacuteder informando al resto
Otro servidor se establece como liacuteder en el mismo momento
Varios nodos pasan a ser candidatos por lo que ninguno consigue los votos
21
Figura 12 Un equipo pasa a estado candidato (RAFT)
Si un candidato recibe un aviso de un liacuteder en el mismo plazo el primeropasa a ser seguidor y se acaba la eleccioacuten de liacuteder
Por otro lado si un equipo candidato no recibe los votos en el plazo y agotasu tiempo de espera avanza al siguiente plazo y repite el proceso de votacioacutenLa tercera posibilidad puede conllevar a un estado indefinido ya que varioscandidatos pueden agotar su tiempo de espera al mismo tiempo y repartir losvotos Para solventarlo el algoritmo establece tiempos de espera aleatorios paralos candidatos
Siguiendo con el ejemplo propuesto el servidor S1 pasa a ser el liacuteder Cadacierto tiempo eacuteste debe realizar avisos a los nodos seguidores para no agotar sutiempo de espera
En este momento el cluster de servidores estaacute en ldquoconsensordquo y la informacioacutenen todos los nodos estaacute actualizada Un cambio en la informacioacuten inicia unproceso de replicacioacuten el liacuteder registra el cambio lo pasa al resto de nodos yuna vez eacutestos responden el cambio se hace efectivo
Supoacutengase que se realiza un cambio en los datos en la figura 13 en la partederecha se observa el cambio en el registro del servidor S1 que informa a losnodos seguidores En consecuencia los nodos registran el cambio y responden aS1
Figura 13 Cambio en un registro (RAFT)
Una vez el cuoacuterum (en el ejemplo tres equipos) informa al liacuteder de que
22
ha registrado el cambio el liacuteder lo hace efectivo en su sistema y notifica a losnodos que hacen lo mismo En la figura 14 el enviacuteo todaviacutea no ha llegado ala maacutequina S3 y se observa que no ha hecho efectivo el cambio (en el registroaparece punteado)
Figura 14 Aprobacioacuten del resto de equipos (RAFT)
Este protocolo funcionaraacute correctamente mientras exista un nuacutemero de nodosen funcionamiento igual o superior al cuoacuterum en el ejemplo propuesto elcuoacuterum es tres por lo que el sistema puede tolerar la caiacuteda de dos de los equipos
522 Protocolo gossip SWIM
Nomad permite la gestioacuten simultaacutenea de varios centros de datos reparti-dos en regiones geograacuteficamente separadas requiriendo de un protocolo ligeroque mantenga a los miembros actualizados sobre los participantes del conjun-to Para ello usa una ligera variante del protocolo SWIM[3] (Scalable Weakly-consistent Infection-style Process Group Membership Protocol) desarrollada porHashiCorp Estaacute clasificado como un protocolo de tipo gossip que debe su nom-bre a la semejanza con coacutemo se distribuye un rumor en una red social
SWIM se sustenta en dos caracteriacutesticas fundamentales la deteccioacuten de fallosy la distribucioacuten de la informacioacuten relativa a los miembros A continuacioacuten sedetalla el funcionamiento de ambos componentes
Deteccioacuten de fallos
Este componente tiene dos paraacutemetros el periodo de protocolo T y el nuacutemerode subgrupos de deteccioacuten de fallos k en los que se dividen los nodos Paracomprobar la comunicacioacuten entre dos maacutequinas usa la utilidad ping basadaen el protocolo ICMP La deteccioacuten de caiacuteda de un servidor sigue el siguientealgoritmo
Durante el periodo T cada miembro Mi de un subgrupo elige otro al azar Mjdel mismo subgrupo y le enviacutea un mensaje ping para comprobar su estado Enel caso de que se cumpla un tiempo de espera determinado por una estimacioacuten
23
del tiempo de ida y vuelta (RTT por sus siglas en ingleacutes) de la red y no hayarespuesta Mi le vuelve a enviar un mensaje ping indirectamente a traveacutes deun nuacutemero k de miembros escogidos aleatoriamente De no recibir ninguna res-puesta Mi establece que Mj ha sufrido un fallo y lo etiqueta como ldquosospechosordquoinformando al componente de distribucioacuten
Figura 15 Diagrama de tiempo del protocolo SWIMFuente httpswwwcscornelledu
Componente de distribucioacuten
Se encarga de informar de cualquier cambio en los miembros a todo el con-junto Los eventos de nodo caiacutedo y la unioacuten o disociacioacuten de un miembro setransmiten a todos los servidores para que actualicen sus lista Para distribuirla informacioacuten a todos los nodos se podriacutea usar el meacutetodo de multicast perosuele estar deshabilitado Por ello se utiliza una teacutecnica de transmisioacuten denomi-nada Piggybacking mediante la cual se adjunta a los propios mensajes PINGy ACK del algoritmo la informacioacuten a distribuir reduciendo asiacute la congestioacutenen la red
523 Planificacioacuten
Proceso encargado de distribuir las tareas entre los nodos clientes de acuerdoa su estado
El planificador de Nomad estaacute basado en las publicaciones de Google sobresus herramientas de gestioacuten de clusters Borg y Omega14 y entiende los trabajosdescritos por el usuario como un estado deseado es decir su despliegue en unamaacutequina cliente de forma correcta y los clientes como el estado actual esto eslo que se encuentra en ejecucioacuten El registro actualizacioacuten o cancelacioacuten de un
14httpresearchgooglecompubspub43438html
24
trabajo asiacute como el fallo de un nodo cliente implican un cambio de estado atramitar por el sistema lo que se define como evaluacioacuten (evaluation) Esto uacutelti-mo supone comparar el estado actual (clientes) con el estado deseado (conjuntode trabajos registrados) y enviarlos a los planificadores correspondientes que seencargaraacuten de asignar las tareas a los nodos clientes
Figura 16 Procedimiento de asignacioacuten en NomadFuente httpswwwnomadprojectio
En la figura 16 se observa el flujo de trabajo en el que las distintas evalua-ciones se encolan en el evaluation broker que se ejecuta en el servidor liacuteder ygestiona las evaluaciones pendientes asignaacutendoles prioridades
A continuacioacuten los nodos servidores ejecutan los scheduling workers queprocesan las evaluaciones llamando a los distintos planificadores que generanun plan de asignacioacuten esto es un conjunto de relaciones entre las tareas y losnodos clientes donde se ejecutaraacuten Este proceso se divide en dos fases primerose descartan aquellos clientes que no cumplan los requisitos y posteriormentese asigna una calificacioacuten al resto Se selecciona el nodo con mayor puntuacioacuteny se encola el plan en el gestor que se ejecuta en el servidor liacuteder Existen tresplanificadores de acuerdo al tipo de trabajo
Service Incluye aquellos trabajos que estaacuten destinados a ejecutarse en un pe-riacuteodo largo de tiempo Para realizar las asignaciones el planificador evaluacuteala mayor parte de los nodos y usa una versioacuten del algoritmo Best fit in-fluenciada por el trabajo de Google en su herramienta Borg Se trata deun algoritmo de planificacioacuten que sacrifica tiempo a cambio de maximizarel rendimiento de los clientes asignando la tarea a la maacutequina que tengala mayor carga de trabajo con el objetivo de reducir equipos en funciona-
25
miento
Batch Tareas que incluyen listas de comandos en general de menor duracioacuteny que no requieren interaccioacuten con el usuario Se vale del algoritmo deSparrow desarrollado por la universidad de Berkeley15 para limitar losnodos clientes a evaluar
System Trabajos destinados a ejecutarse en todos los nodos incluso los que seunen al cluster posteriormente
Core Mantenimiento interno de Nomad
Una vez se ha realizado el proceso de planificacioacuten el nodo liacuteder lo registra enla cola de planes (plan queue) que se encarga de asignarles prioridad y manejarcondiciones de carrera es decir que no accedan a los recursos de los clientes sincontrol y evitar que eacutestos superen su capacidad
La maacutequina liacuteder del conjunto puede de este modo aceptar una asignacioacuteny ser ejecutada por los clientes o por el contrario rechazaacutersela al planificadorlo que implicariacutea realizar un plan parcial o totalmente nuevo
Finalmente el estado de las evaluaciones se actualizan y los clientes soninformados de las asignaciones ejecutaacutendose las tareas
15httppeopleeecsberkeleyedu~keopublicationssosp13-final17pdf
26
6 Casos de uso y despliegue
Con el objetivo de mostrar las posibles utilidades que este tipo de sistemaspueden tener en las infraestructuras TI actuales se han desplegado las dos he-rramientas en la nube Microsoft Azure usando su servicio cloud de instancias demaacutequinas virtuales Linux para simular un conjunto de ordenadores conectadosentre siacute por una red LAN Sobre ellas se ha implementado dos casos de usouna aplicacioacuten web con una arquitectura con cierta orientacioacuten a microserviciosy un sistema de integracioacuten continua
El coacutedigo y todos los ficheros de configuracioacuten se pueden encontrar en elrepositorio del proyecto en GitHub16
61 Aplicacioacuten Web
Se busca simular el proceso de adaptacioacuten de una solucioacuten web para su des-pliegue en un sistema distribuido con las herramientas anteriormente descritascon el objetivo de aumentar tanto su escalabilidad como disponibilidad medianteredundancia
Se ha partido de una aplicacioacuten ya existente17 un servicio de almacenamien-to y reproduccioacuten de canciones A grandes rasgos este servicio permite crearusuarios subir canciones con sus respectivas portadas tener playlists propias yescuchar las canciones a traveacutes de un navegador web
La solucioacuten estaacute dividida en 4 partes (figura 17)
Una vista web con la loacutegica
Un almacenamiento conectado en red (NAS por sus siglas en ingleacutes)
Una API REST para gestionar las peticiones al almacenamiento
Base de datos NoSQL basada en MongoDB
La nueva tendencia de los proyectos web es su implementacioacuten en contene-dores Docker ya que facilitan su portabilidad y ofrecen un procedimiento dedespliegue raacutepido sobre todo a la hora de desarrollar y realizar pruebas en en-tornos de produccioacuten simulados Por ello en este caso se va a hacer uso de los
16httpsgithubcomAntonioAlfrzCloud-Orchestrators17httpsgithubcomsonsoleslpCDPSfy
27
motores de orquestacioacuten de contenedores de ambas herramientas Marathon enDCOS y el controlador Docker en el caso de Nomad
Figura 17 Arquitectura aplicacioacuten web
A continuacioacuten vamos detallar el despliegue en ambas herramientas de es-ta solucioacuten y observar tanto queacute dificultades se encuentran como que ventajasofrecen El objetivo final es adaptar el proyecto modificaacutendolo lo menos posiblecon objeto de analizar la capacidad de estas herramientas para desplegar cual-quier aplicacioacuten sin que eso conlleve la modificacioacuten de la arquitectura de eacutestaes decir que no sea dependiente del entorno
611 DCOS
Se ha descrito DCOS como una herramienta que se despliega sobre un con-junto de ordenadores y que permite instalar gestionar el despliegue de sistemasdistribuidos
Microsoft Azure cuenta con una plantilla para desplegar en su servicio cloudun cluster de maacutequinas virtuales con DCOS ya instalado que cuenta con
Maacutequinas maestras (1 3 o 5 a seleccionar por el usuario) configuradascomo un conjunto de disponibilidad esto eso Azure da ciertas garantiacuteasde que al menos una maacutequina estaraacute en funcionamiento
Maacutequinas agentes Por motivos de seguridad se distinguen dos roles
bull Nodos privados solo accesibles desde la red interna y configuradoscomo un conjunto de escala un recurso de Azure para gestionar ydesplegar maacutequinas con configuraciones ideacutenticas para permitir unraacutepido escalado
bull Un equipo conectado accesible desde Internet a travntildees de un balan-ceador de carga puacuteblico y situado en una subred externa
28
Dos balanceadores de carga
bull La interfaz puacuteblica del cluster que se conecta con el cliente puacuteblicobull Acceso a los equipos maestros para el administrador que soacutelo permiteconexioacuten mediante SSH y credenciales
Almacenamiento para todas las maacutequinas
Configuraciones necesarias de red y seguridad
En la figura 18 se observa un diagrama de la infraestructura
Figura 18 Infraestructura en Azure
El primer obstaacuteculo es la persistencia de estado de la aplicacioacuten que seconsigue gracias a una base de datos no relacional basada en MongoDB asiacutecomo el almacenamiento de las canciones Para implementarla tenemos variasposibilidades
Montar un sistema externo de almacenamiento conectado en red en todoslos agentes donde se ejecuten las tareas de esta manera si una tarea pasade un nodo a otro por cualquier motivo puede tener acceso a los mismosficheros (opcioacuten del caso de uso original)
Implementar un sistema de ficheros distribuidos en los agentes
Usar los servicios de almacenamiento de las nubes puacuteblicas
Aprovechar el sistema de voluacutemenes persistentes de Apache Mesos Eacutestepermite reservar recursos de un agente de forma que al arrancar una tarease crea un volumen independiente del ciclo de vida de eacutesta con ello esosrecursos donde se ha almacenado la informacioacuten pueden volver a ofrecerseal mismo entorno de tal manera que otra tarea pueda acceder a ella
DCOS aprovecha este sistema de voluacutemenes persistentes y permite instalarbases de datos distribuidas como ArangoDB o Apache Cassandra sin embargoesto implicariacutea modificar todo el coacutedigo referente al modelo de la base de datos
29
Por motivos de eficiencia y latencia asiacute como de una mayor gobernabilidadde los datos la mejor opcioacuten es usar el recurso de voluacutemenes persistentes queofrece Apache Mesos ya que de esta manera se gestionariacutea la aplicacioacuten completamediante una uacutenica herramienta Sin embargo esto implica que la informacioacutense encuentra exclusivamente en el agente donde se haya ejecutado la tarea y porlo tanto se sigue requiriendo de software externo para distribuir la informacioacutenpara que se accesible para todos los agentes A la hora de realizar este proyectose encontraba en desarrollo Flocker una solucioacuten desarrollada por ClusterHQque permite compartir los voluacutemenes de Docker a traveacutes de un cluster quesi bien es compatible con el planificador de Mesos el proyecto se encontrabatodaviacutea en fases tempranas de desarrollo y los sistemas de almacenamiento quesoporta quedaban fuera del aacutembito de este trabajo
Por todo ello dado que las maacutequinas se han desplegado en la nube puacuteblicade Azure se decidioacute usar su servicio de almacenamiento de objetos para lascanciones y otra maacutequina para desplegar MongoDB y asiacute mantener el modelode datos original de la aplicacioacuten La diferencia del almacenamiento de obje-tos con respecto a nivel de fichero es que el primero no tiene jerarquiacutea paraorganizar los archivos eacutestos se guardan como objetos (con sus metadatos) enun mismo espacio soacutelo diferenciaacutendose por un identificador uacutenico esto implicaentre otras cosas que se puede acceder a un fichero dado uacutenicamente su IDindependientemente de la localizacioacuten fiacutesica de eacuteste facilitando pues la gestioacuteny el desarrollo
El coacutedigo del proyecto se ha modificado en los siguientes apartados
Las direcciones de la base de datos y los balanceadores de carga asiacute comosus puertos estaban originalmente fijos Se han configurado como variablesde entorno para facilitar el descubrimiento del servicio y hacer transpa-rente la aplicacioacuten al entorno de despliegue
La API REST se ha adaptado al almacenamiento en Azure en vez de enlocal
Estas modificaciones no suponen un cambio sustancial pero permiten separala persistencia de las tareas ejecutadas por DCOS lo que facilita en granmedida su ejecucioacuten al ser totalmente sin estado y ademaacutes implican tenerlos datos bajo un mayor control
Para la orquestacioacuten de contenedores se va a usar el entorno Marathondesarrollado tambieacuten por Mesosphere Eacuteste se puede usar a traveacutes de una interfazgraacutefica la interfaz de liacutenea de comandos (en lo que sigue CLI por sus siglas eningleacutes) de DCOS o con su API HTTP
Primero se han publicado la imaacutegenes de los contenedores que encapsulanla interfaz web y la api de la aplicacioacuten en el repositorio puacuteblico DockerHub
Los despliegues en este entorno se describen mediante ficheros JSON en losque se detalla entre otras opciones la imagen del contenedor los puertos a usar
30
los recursos que debe ocupar en un nodo o las instrucciones de monitorizacioacuten
Para el servicio de descubrimiento DCOS ofrece la posibilidad de asignardirecciones IP virtuales (VIP por sus siglas en ingleacutes) a tareas que se compartenen todos los nodos DCOS lleva integrado un balanceador de carga a nivel TCP(el componente denominado Minuteman) que balancea entre las direccionesvirtuales de las tareas y todas las instancias de eacutestas a lo largo del cluster Estoes necesario por dos motivos equilibrar la carga de los equipos con el fin deevitar un punto de uacutenico fallo mediante redundancia y evitar la contienda dedirecciones al ejecutar las tareas en puertos aleatorios
Este balanceador de carga estaacute basado en el trabajo de Michael Mitzenma-cher The Power of Two Choices in Randomized Load Balancing18 A grandesrasgos el algoritmo mantiene una media moacutevil exponencial de latencias paracada destino (backend) ademaacutes de las caiacutedas consecutivas Si un destino noresponde a una negociacioacuten en tres pasos (three way handshake) de forma con-secutiva en un periodo inferior a 5 ms se considera caiacutedo El algoritmo iterasobre los destinos disponibles en base a su histoacuterico de fallos y escoge dos deforma aleatoria de los cuales coge el de mejor meacutetrica
Las direcciones virtuales soacutelo se pueden resolver dentro del cluster porello para implementar la interfaz puacuteblica de la aplicacioacuten esto es el balancea-dor de carga de la interfaz web usaremos un paquete de DCOS denominadomarathon-lb un balanceador basado en HAProxy y adaptado por MesosphereEn este caso equilibra la carga de todas instancias de las tareas ejecutadas porel entorno Marathon por sus etiquetas y permite ademaacutes definir como puntode entrada muacuteltiples hosts virtuales definidos por sus nombres completos dedominio (FQDN por sus siglas en ingleacutes) en nuestro caso la interfaz puacuteblicadel balanceador de Azure para los agentes
Por motivos de seguridad todas las tareas se ejecutan en los agentes privadoses decir los que son exclusivamente accesibles desde la red interna Por su partemarathon-lb se ejecuta en el agente puacuteblico que cuenta con IP puacuteblica y lospuertos 80 (HTTP) y 8080 abiertos de forma que la aplicacioacuten sea accesibledesde Internet Esto es posible debido a que Apache Mesos permite reservarrecursos mediante roles asignados a nodos para un uso especiacutefico De esta formala arquitectura vista desde la aplicacioacuten quedariacutea como en la figura 19
18httpswwweecsharvardedu~michaelmpostscriptstpds2001pdf
31
Figura 19 Arquitectura de la aplicacioacuten web en DCOS
Ejecucioacuten
A la hora de desplegar la aplicacioacuten DCOS puede gestionarse medianteuna interfaz graacutefica o una interfaz de liacutenea de comandos La primera se accedea traveacutes de un navegador web en el puerto 80 (HTTP) y permite instalar losentornos disponibles observar el estado de los nodos y las tareas que se estaacutenejecutando y los ficheros de registros que eacutestas generan
La CLI permite el control desde un nodo o una maacutequina remota (suponiendoque los maestros tienen IP puacuteblica y el puerto 80 abierto) ya que DCOS tieneun sistema de autorizacioacuten que permite tener una interfaz puacuteblica con ciertasgarantiacuteas de seguridad
Por su parte cada entorno de trabajo puede ser controlado por la CLI peroademaacutes cuenta con sus propias interfaces Marathon expone una API HTTPen el puerto 8080 de la direccioacuten puacuteblica de los maestros del cluster asiacute comootra interfaz graacutefica Para desplegar un contenedor se podriacutea usar la CLI
$ dcos marathon app add lt f i l e j songt
O la API HTTP
$ cu r l minusX POST http lt ip_maestro gt8080v2apps minusd ltf i l e jsongt minusH Contentminustype app l i c a t i o n j son
32
612 Nomad
La arquitectura de Nomad es maacutes sencilla ya que solo requiere de un ficheroejecutable en todos los nodos para funcionar Si DCOS es la base de instala-cioacuten de entornos de terceros Nomad integra todas las funcionalidades baacutesicasesto es gestor de recursos planificador y ejecutor en los nodos cliente Estaherramienta cuenta con un menor tiempo de desarrollo y en el momento deescribir este documento cuenta exclusivamente con los siguientes controladoresen comparacioacuten con los entornos de DCOS
Motor Docker es decir funcioacuten de orquestacioacuten de contenedores
Ejecucioacuten de archivos binarios como comandos de Shell
Ejecucioacuten de aplicaciones Java
Virtualizacioacuten de maacutequinas mediante tecnologiacutea QEMU
Todos ellos necesitan que la tecnologiacutea subyacente esteacute instalada en las maacute-quinas clientes (Docker Java QEMU) Actualmente no permite el registro decontroladores por parte de terceros aunque estaacute planificado en un futuro ofreceruna interfaz para su desarrollo
Nomad no cuenta con el servicio de descubrimiento sin embargo puede inte-grarse con la herramienta Consul desarrollada por la misma empresa Por otrolado para el balanceo de carga usaremos un contenedor Docker con HAProxyuna herramienta de coacutedigo abierto que ofrece tanto servicios de proxy como debalanceador y cuyos ficheros de configuracioacuten completaremos con el proyectoConsul Template19
Consul
Consul sigue la misma arquitectura que Nomad es decir un nodo servidorque orquesta un conjunto de maacutequinas clientes y permite a los procesos que seejecutan en los equipos definirlos como servicios ofreciendo diversas caracteriacutes-ticas entorno a estos de los cuales vamos a usar dos
Descubrimiento de servicio Las maacutequinas clientes publican en el cataacutelogode servicios las tareas en ejecucioacuten y Consul les asigna nombres de dominioaccesibles por todos los miembros del cluster a traveacutes de la interfaz DNSincluida en esta herramientaConsul se integra con Nomad de forma que todas las tareas que se ejecu-ten en la segunda son automaacuteticamente publicados como servicios de laprimera de esta manera no hace falta conocer la direccioacuten de la maacutequinacliente donde se esteacute ejecutando el proceso ya que se puede acceder a eacutela traveacutes de su nombre de dominio de forma transparente Por ejemplo si
19[httpsgithubcomhashicorpconsul-template]
33
ejecutamos una tarea con ID web en el puerto 8080 se puede acceder aella en la direccioacuten webserviceconsul8080Para que las direcciones propias de Consul las resuelva su propio DNS y noel que esteacute asignado por defecto en la maacutequina usaremos la herramientadnsmasq20 que permite especificar la direccioacuten de un servidor DNS paraconsultas de direcciones especiacuteficas
Monitorizacioacuten Permite realizar comprobaciones del servicio y seguir su esta-do Aprovecharemos esta funcionalidad tanto para definir el propio procesode Nomad como servicio de Consul como las tareas desplegadas
HAProxy + Consul Template
HAProxy es una solucioacuten versaacutetil de coacutedigo abierto que ofrece solucionesde balanceo de carga y proxy Existen otras herramientas en el mercado comoNGINX o ldirectord sin embargo HAProxy suponiacutea una solucioacuten sencilla deconfigurar para mostrar el caso de uso
El uso de estas herramientas se debe a dos motivos para que no existacontienda con respecto a los puertos de los clientes usados por las tareas eacutestos sevan a asignar de forma dinaacutemica lo que en principio implicariacutea que la aplicacioacutendeberiacutea realizar consultas DNS de tipo SRV (que incluye puertos) a la interfazde Consul y balancear la carga entre tareas por redundancia y capacidad
Como la direccioacuten IP y puerto son variables cada vez que las tareas seactualicen o se reasignen es necesario volver a configurar HAProxy de formamanual Por ello HashiCorp ha desarrollado un programa denominado Con-sul Template que realiza peticiones sucesivas a la interfaz HTTP de Consul delas direcciones fiacutesicas de un servicio y reinicia automaacuteticamente el proceso deHAProxy Asiacute definiendo estas tareas como servicios Consul podremos tantomonitorizarlas como escalar las tareas dinaacutemicamente sin necesidad de cambiarel balanceador A partir del contenedor Docker oficial de HAProxy se ha desa-rrollado otro con la configuracioacuten baacutesica y con Consul Template para desplegarlocomo una tarea en Nomad
Despliegue
Se ha usado el mismo coacutedigo que en el apartado anterior con la persistenciaen el servicio de almacenamiento de Azure Desde la perspectiva del hardwarese implementaraacute la misma infraestructura que en el caso de DCOS (figura 18)estos es definiremos dos tipos de maacutequinas clientes un agente que se conectaraacutecon el balanceador de carga con nombre de dominio puacuteblico y donde se desple-garaacute el balanceador de carga de la vista web y agentes privados no accesiblesdesde fuera del cluster y donde se ejecutaraacuten el resto de tareas en la red inter-na La principal diferencia radica en las tareas que ejecutan HAproxy y ConsulTemplate que sustituye a las direcciones IP virtuales que ofrece DCOS
20httpwwwthekelleysorgukdnsmasqdochtml
34
Figura 20 Despliegue en Azure de Nomad+Consul
Cabe matizar que los balanceadores basados en HAProxy se implementanpor necesidad de la aplicacioacuten para el descubrimiento del servicio a diferenciade los de Azure que se implementan por motivos de seguridad y escalabilidaddel cluster en siacute
Configuracioacuten Nomad
Los ficheros de configuracioacuten de las maacutequinas maacutester y cliente son similaresy comparten la mayoriacutea de las opciones como por ejemplo el nombre del nodoo la interfaz de red donde escucha Nomad las peticiones Sus opciones son engeneral auto-explicativas sin embargo existen dos detalles que matizar
El proceso de Nomad escucha las peticiones tanto de los protocolos deconsenso como del usuario a traveacutes de una interfaz de red que se debeindicar en el fichero de configuracioacuten
En el caso de los clientes se deben indicar las direcciones de los servidoresdel cluster sin embargo se trata de un sistema dinaacutemico en el que losnodos pueden sufrir errores y cambiar de direccioacuten Por ello se ha definidoNomad como un servicio de Consul y asiacute poder definir la direccioacuten de losservidores como un nombre de dominio no por su direccioacuten fiacutesica que elservidor DNS de Consul se encargaraacute de resolver
Por defecto Nomad usa los siguientes puertos
API HTTP 4646 Peticiones HTTP y recepcioacuten de oacuterdenes mediante laliacutenea de comandos
RPC 4647 Protocolo de consenso entre los nodos del cluster
Serf 4648 Protocolo de gossip entre los servidores de los centros de datosgobernados por Nomad
35
Los dos uacuteltimos deben ser interfaces alcanzables por otros nodos sin embargo laAPI HTTP por motivos de seguridad deberiacutea ser local ya que en caso contrariocualquier persona con acceso a ella tiene el control sobre la herramienta Eacutestasolo deberiacutea estar accesible en un servidor o gestionarlo mediante una terminalSSH por ejemplo En este trabajo al ser una prueba de concepto se ha abiertoen todos los nodos
Trabajos de Nomad
Las tareas se detallan en ficheros con formato HashiCorp Configuration Lan-guage un derivado del formato JSON creado por la empresa que le da nombrecompatible con eacuteste y que permite comentarios
En estos ficheros se puede definir
La regioacuten y el centro de datos donde se ejecutaraacute (Nomad permite lagestioacuten de centros de datos geograacuteficamente distribuidos en regiones)
La poliacutetica de actualizacioacuten de la tarea
Grupo de tareas esto es que se ejecutaraacuten en el mismo nodo
El nuacutemero de grupos a ejecutarescalar asiacute como los liacutemite que debencumplir los nodos asignados
La poliacutetica de reinicio ante fallo o error
Tareas El controlador su configuracioacuten los paraacutemetros del servicio aso-ciado a registrar en Consul asiacute como los recursos que consume (puertosmemoria)
En nuestro caso usamos sobre todo el controlador Docker esto eso orques-tacioacuten de contenedores en los nodos clientes y tres de sus opciones
Imagen del contenedor Se han subido todas las imaacutegenes del proyecto a Doc-ker Hub donde por defecto se busca la imagen
Puertos Los puertos a usar por el contenedor que pueden ser estaacuteticos asigna-dos por el usuario o dinaacutemicos siendo Nomad el que se encarga de mapearun puerto libre del nodo cliente al expuesto por el contenedor
Servidores DNS Como usamos la interfaz DNS de Consul como descubri-miento de servicio se debe configurar el contenedor para que use cualquiernodo del cluster como servidor DNS
Configuracioacuten Consul
Al ser desarrolladas por la misma empresa los ficheros de configuracioacuten deConsul y Nomad comparten muchas opciones Consul tambieacuten acepta peticionesa traveacutes de una interfaz de red siendo los puertos usados por defecto
36
RPC 8300 8400 Maneja la peticiones del resto de nodos y usuarios
Serf 8301 8302 Protocolo gossip
HTTP API 8500
HTTPS API Desactivada por defecto
Interfaz DNS 8600
Se debe asignar a los protocolos internos del cluster esto es RPC y Serf unainterfaz alcanzable por los nodos y por el contrarioasignar a los dos uacuteltimos ala interfaz de loopback por motivos de seguridad
Cabe destacar que Consul tambieacuten cuenta con una interfaz graacutefica que per-mite ver el estado de los equipos y los servicios registrados y que se encuentra enel mismo puerto que la API HTTP en la direccioacuten httpIP_EQUIPO8500ui
Ejecucioacuten
Tanto Nomad como Consul requieren de la ejecucioacuten de un fichero en todoslos nodos integrantes del cluster Como prueba de concepto se ha decidido usardos servidores para ambos aunque cabe matizar que es un nuacutemero ineficienteya que la caiacuteda de uno de ellos supondriacutea la peacuterdida del cuoacuterum y por tantodel consenso del cluster
En primer lugar se arrancan los servidores que son los encargados de ejecu-tar el protocolo de consenso y gestionar el cluster y a continuacioacuten los clientesque no tienen praacutecticamente estado y dependen de los servidores
En el caso de Consul se debe indicar el directorio donde se guardan losficheros que describen los servicios asiacute como el archivo que especifica el resto delas opciones
1 Se inicia el primer servidor en uno de los equipos
$ consu l agent minuscon f i gminusd i r e t c consu l d s e r v i c e s minuscon f i gminus f i l e consu l_server j son
2 Los siguientes equipos deben unirse al anterior por lo que antildeadimos elargumento join con la direccioacuten del primer servidor Para el caso de otrosservidores
$ consu l agent minuscon f i gminusd i r e t c consu l d s e r v i c e s minuscon f i gminus f i l e consu l_server j son minus j o i n ltIP_servidor1gt
37
Una vez los servidores han alcanzado el consenso y elegido un liacuteder en losclientes
$ consu l agent minuscon f i gminusd i r e t c consu l d s e r v i c e s minuscon f i gminus f i l e c on su l_c l i en t j son minus j o i n ltIP_cualquierServ idorgt
El proceso para iniciar Nomad es igual y los comandos similares sin embargoya no es necesario indicar una direccioacuten IP fija en los equipos sino el nombre dedominio del servicio de Nomad registrado por Consul En el primer servidor
$ nomad agent minusc on f i g nomad_server j son
Y el resto de equipos (con su fichero de configuracioacuten correspondiente)$ nomad agent minusc on f i g nomad_server j son minus j o i n nomad s e r v i c e consu l
Por uacuteltimo para desplegar la aplicacioacuten web se han escrito tres ficherosque detallan las tareas de la interfaz web API y los balanceadores de cargaMediante la CLI
$ nomad run minusaddress=http lt ip_c lus te r gt4646 lt f i l e hclgt
O mediante la API HTTP de Nomad$ cu r l minusX POST minusd ltf i l e hclgthttp lt ip_c lus te r gt4646 jobltjob_namegt
Ansible
Como se puede comprobar con el aumento del nuacutemero de equipos pasa aser inviable manejar todos los nodos a traveacutes de terminal Ademaacutes como seha comentado con anterioridad Nomad requiere que en los nodos clientes es-teacuten instalados las herramientas que soporten las tareas por ejemplo el motorde Docker Por ello para facilitar tanto el arranque como la instalacioacuten de lasdependencias vamos a usar Ansible una herramienta de coacutedigo abierto desarro-llada en Python que permite gestionar configuraciones aprovisionar recursosdespliegue de aplicaciones de forma automaacutetica
A grandes rasgos esta herramienta funciona mediante ficheros en formatoYAML denominados play-books que describen un conjunto de pasos a ejecutaren una lista de equipos remotos Estos pasos son ejecutados por moacutedulos inde-pendientes a traveacutes de SSH es decir en cualquier ordenador con conexioacuten a los
38
hosts dado su contrasentildea o clave puacuteblica puede arrancar el script y realizariacutealos pasos de forma remota gestionando el cluster desde un solo equipo
Se han desarrollado guiones para lo siguiente
Descarga de los binarios de Nomad y Consul en todos los nodos copiade los ficheros de configuracioacuten baacutesicos y modificarlos de acuerdo a cadanodo (nombre del equipo direccioacuten IP)
Instalacioacuten de las dependencias
Arranque de Nomad y Consul
Ansible extiende su funcionalidad a traveacutes de moacutedulos independientes que per-miten por ejemplo instalar paquetes mediante herramientas de gestioacuten de pa-quetes (APT yum) aprovisionar automaacuteticamente maacutequinas virtuales de Ama-zon EC2
Algunas opciones de los ficheros de configuracioacuten de Nomad y Consul sondependientes del nodo particular por ejemplo la interfaz de red Para estetrabajo se ha realizado un moacutedulo para modificar los ficheros de configuracioacutende forma automaacutetica En el repositorio del proyecto se encuentra una carpetadonde se encuentran todos los ficheros necesarios para desplegar un clustertotalmente funcional solo requiere de una liacutenea de terminal con Ansible
$ ans ib l eminusplaybook minus i hos t s minusk ltssh_passgt minusu ltnode_usergt s i t e yml
39
62 Servicio de integracioacuten continua
Se ha implementado un sistema de integracioacuten continua que permite ejecu-tar tareas de compilacioacuten y pruebas de forma distribuida aumentando asiacute elrendimiento de los equipos En primer lugar se detallaraacute los motivos por los quepuede resultar beneficioso para las empresas una implementacioacuten de este tipo alo que seguiraacute los detalles del despliegue
621 DevOps
Metodologiacutea que defiende la comunicacioacuten y colaboracioacuten entre desarrolla-dores de software y los profesionales de operaciones a lo largo de todo el ciclo devida de una aplicacioacuten Estaacute muy relacionado con el desarrollo aacutegil de softwareesto es un enfoque para los proyectos que defiende el desarrollo iterativo e in-cremental donde los requisitos y soluciones evolucionan con el tiempo seguacuten lanecesidad del proyecto DevOps extiende esta filosofiacutea a todas los componentesde un servicio incluyendo sistemas y operaciones
Se trata de un concepto que cada organizacioacuten o empresa adapta a suspropias necesidades y procesos de negocio en este proyecto nos vamos a centraren la integracioacuten continua una praacutectica fundamental tanto del desarrollo aacutegilcomo de esta filosofiacutea
622 Integracioacuten Continua
Se define como una praacutectica de desarrollo software donde los miembros delequipo ponen en comuacuten su trabajo frecuentemente al menos una vez al diacutea21Cada integracioacuten se verifica con una compilacioacuten automaacutetica que incluye laejecucioacuten de pruebas para detectar errores de integracioacuten tan pronto como seaposible
Desde el punto de vista operativo esto supone automatizar la configuracioacutende equipos o el despliegue de maacutequinas virtuales donde compilar el proyecto yejecutar las pruebas y posteriormente eliminarlas Este flujo de trabajo se vebeneficiado en entornos distribuidos ya que el objetivo del desarrollador es com-probar el resultado de las pruebas raacutepidamente sin preocuparse del despliegueo los propios equipos
Para esta prueba de concepto vamos a usar Jenkins un servidor de integra-cioacuten continua escrito en Java que nos permite definir trabajos que contendraacutenla descripcioacuten tanto del entorno como su ejecucioacuten
Este sigue una estructura maestro-esclavo muy similar al de los gestores declusters usados en este proyecto el maestro contiene toda la loacutegica del servicio
21httpmartinfowlercomarticlescontinuousIntegrationhtml
40
trabajos autenticacioacuten y los esclavos son los encargados de la ejecucioacuten ensiacute Jenkins tiene varias viacuteas para aprovisionar los uacuteltimos
Mediante SSH
Interfaz graacutefica
Desarrollar un script propio
Ejecucioacuten de un fichero java
La ventaja de usar planificadores es que el despliegue de esclavos es dinaacutemicoes decir no tener una maacutequina especiacuteficamente configurada para ello DCOS yNomad se encargaraacuten de configurar estos despliegues en sus maacutequinas y poste-riormente eliminarlos Para ello se ha usado la uacuteltima opcioacuten definiendo tareasque descarguen el fichero java Con todo ello se consigue un entorno de inte-gracioacuten continua eficiente que ademaacutes permite la ejecucioacuten de otros servicios deforma independiente
Jenkins permite la creacioacuten de plugins que extienden sus funcionalidadesTanto Nomad22 como Apache Mesos cuentan con uno que permite su integra-cioacuten
Para esta prueba se va a usar el mismo proyecto que para el caso de usode orquestacioacuten de contenedores la aplicacioacuten web al que se le ha antildeadido untest para comprobar que se conecta correctamente a la base de datos medianteMocha un framework de Nodejs Por otro lado se antildeade el plugin de git ya queel coacutedigo se obtiene de GitHub el repositorio remoto de control de versiones delproyecto
El proceso general de ejecucioacuten seriacutea como sigue
1 Se ejecuta el maestro de Jenkins como tarea Docker partiendo de la imagenoficial
2 Al arrancar un trabajo se manda una tarea a los planificadores que laasignaraacuten a un nodo cliente Esta tarea consiste en la descarga del ficherode configuracioacuten Java y arrancarlo configurando el equipo como un clientede Jenkins temporalmente
3 Jenkins ejecuta el trabajo en el nuevo cliente en este caso iniciar la apli-cacioacuten web iniciar las pruebas y generar un informe
4 Se elimina el cliente
A continuacioacuten se detallan los matices de cada herramienta a la hora de imple-mentar este servicio
22Desarrollado por Ivo Verberk httpwwwivoverberknl
41
623 Jenkins con Nomad
El plugin permite la ejecucioacuten del fichero Java mediante dos controladorescontenedores Docker y Java En este proyecto nos hemos decantado por el pri-mero ya que nos ahorra instalar la maacutequina virtual de java en todos los nodoscliente Por ello se ha construido un contenedor base con Java para la ejecucioacutendel fichero de configuracioacuten y Nodejs para lanzar la aplicacioacuten web
El plugin se configura con la direccioacuten IP del cluster y el contenedor queejecuta el esclavo Jenkins Por su parte el trabajo en Jenkins se define conel repositorio en GitHub donde se aloja el coacutedigo del proyecto a probar y loscomandos a ejecutar en este caso npm update y npm test
624 Jenkins con DCOS
En el caso de DCOS su sistema de paquetes incluye Jenkins por lo queal instalarlo ya se tiene la configuracioacuten de Mesos totalmente funcional Sinembargo para ejecutar la aplicacioacuten en particular y las pruebas se requiere deNodejs en los equipos esclavos por ello debemos antildeadir un plugin de Jenkinsque permite instalar este entorno antes de ejecutar el trabajo Una vez hechoesto soacutelo queda definir la tarea igual que en el caso anterior
Cabe destacar que Mesosphere tambieacuten ha desarrollado un plugin que per-mite hacer despliegues en Marathon de tal manera que permitiriacutea con cadacommit del coacutedigo compilar la imagen del contenedor Docker y desplegarlaautomaacuteticamente aunque en este proyecto no se ha hecho pruebas de esta fun-cionalidad
42
7 Escalando la infraestructura
Uno de los factores clave que se busca a la hora de implementar sistemasdistribuidos es el poder escalar la infraestructura de forma maacutes sencilla estoes detectar que las maacutequinas estaacuten alcanzando el liacutemite de su capacidad yaumentar eacutesta ya sea mejorando sus caracteriacutesticas teacutecnicas o antildeadiendo maacutesnodos al cluster
El coacutedigo y todos los ficheros de configuracioacuten de esta seccioacuten tambieacuten sepueden encontrar en el repositorio del proyecto en GitHub23
71 Disentildeo
Microsoft Azure permite organizar los servicios cloud de forma loacutegica a traveacutesde grupos de recursos y asiacute poder crear o eliminar eacutestos en conjunto parauna aplicacioacuten determinada (por ejemplo una aplicacioacuten web suele requerir demaacutequinas virtuales bases de datos almacenamiento) Ademaacutes dispone dela opcioacuten de crear plantillas en formato JSON que permite al desarrolladordefinir los recursos y su interrelacioacuten para desplegar de forma automaacutetica unainfraestructura TI en la nube
Azure tambieacuten ofrece la posibilidad de monitorizar el estado de las maacutequinasvirtuales a traveacutes de extensiones lo que permite configurar el escalado automaacute-tico al alcanzar cierto liacutemite definido por el operador Eacutesta es a priori la formaen que deberiacutea implementarse hablando en teacuterminos de eficiencia sin embargoesta aproximacioacuten es totalmente dependiente de la plataforma es decir no sepuede extrapolar a otro proveedor o sobre recursos propios sin realizar un nue-vo disentildeo En este proyecto las tareas que son ejecutadas por estos equipos notienen estado ya que todo lo relativo a la persistencia lo hemos asignado fueradel cluster esto permite escalar la plataforma a traveacutes de otra aproximaciones
Las plantillas aceptan una serie de variables a indicar por el usuario entreotras los conjuntos de escala para definir los nodos aceptan una variable quedefine el nuacutemero de maacutequinas que los componen Por otro lado Azure ofreceuna API REST y kits de desarrollo software (SDK por sus siglas en ingleacutes) quepermiten su despliegue de forma programaacutetica Aprovechando estas facilidadesen este proyecto se va a aproximar la escalabilidad con el sucesivo desplieguede la infraestructura de forma automaacutetica se monitorizan los equipos y si sedetecta una maacutequina excesivamente cargada se aumenta el nuacutemero de equiposen la plantilla y se vuelve a desplegar
23httpsgithubcomAntonioAlfrzCloud-Orchestrators
43
En este proyecto se han disentildeado las plantillas para desplegar la arquitec-tura necesaria tanto de Nomad como de DCOS En el caso de la primera eldespliegue es maacutes descriptivo ya que incluye maacutequinas virtuales grupos de se-guridad redes En el caso de DCOS Azure cuenta con un servicio especiacuteficopara clusters gobernados por DCOS denominado Azure Container Service queincluye los componentes necesarios y la instalacioacuten ya realizada
72 Implementacioacuten
En primer lugar para monitorizar el estado de los equipos se va a usar laherramienta Nagios un sistema que permite controlar el estado del hardwarey los servicios de un equipo Se trata de una herramienta muy completa de laque se va a usar su capacidad para ejecutar comandos (plugins) en los nodospara detectar picos de carga generar alertas y ejecutar programas para estoseventos
Se ha desplegado una maacutequina virtual con esta herramienta en ambos siste-mas y se ha instalado una extensioacuten de Nagios (Nagios Remote Plugin Executor)en todos los nodos que permite ejecutar comprobaciones remotamente en con-creto para esta prueba de concepto medir el nivel de saturacioacuten de la unidadcentral de procesamiento (CPU por sus siglas del ingleacutes) Cuando sucede uncambio de estado de una maacutequina esto es cuando este paraacutemetro supera el liacutemi-te definido por el operador Nagios permite actuar en consecuencia ejecutandoprogramas por ello se ha desarrollado un script que ejecuta lo siguiente
Un programa desarrollado en Python con el SDK de Azure que modificalas plantillas y despliega los recursos
Un guioacuten de Ansible para instalar todos los componentes necesarios en lasnuevas maacutequinas y arrancar de nuevo el cluster y las aplicaciones
44
8 Resultados y conclusiones
En este uacuteltimo apartado se da una visioacuten global del proyecto asiacute como a lasconclusiones maacutes importantes a las que se ha llegado y posibles temas futurosde desarrollo
81 Comparacioacuten
Ambas herramientas ofrecen las funcionalidades para gestionar los recursoseficientemente ofreciendo a los desarrolladores una plataforma donde desplegarsus aplicaciones de forma distribuida independientemente de los equipos fiacutesicosy el hardware que las soporten
DCOS es una herramienta que en un comienzo fue privativa pero cuyos res-ponsables la empresa Mesosphere decidieron publicar una versioacuten de coacutedigoEacutesta nos permite gestionar un cluster de una forma sencilla y usable ademaacutes decomplementarlo con otras herramientas como el balanceador de carga integradoo la autenticacioacuten de usuarios ademaacutes estaacute basada en Apache Mesos un pro-yecto de relativa madurez y con el soporte de la Apache Software FoundationDe forma resumida DCOS ofrece muchas posibilidades y servicios a cambiode una arquitectura e instalacioacuten maacutes compleja
Por su parte HashiCorp con menor tiempo de desarrollo ha conseguidouna herramienta muy sencilla de desplegar que ademaacutes cumple con todas lasfuncionalidades baacutesicas ejecutando un simple binario en cada nodo se puededesplegar un gestor de clusters totalmente funcional Sin embargo no cuentacon todas las posibilidades de Mesos (Nomad cuenta con menos controladoresque entornos posibles de Mesos) ni con los antildeadidos de DCOS lo que implicael uso de otras herramientas para complementar el servicio (Consul HAProxy)
De entre las dificultades encontradas al usar estas herramientas y desplegaraplicaciones sobre ellas se puede destacar la depuracioacuten en ocasiones se desco-noce si un error viene de la propia herramienta de la aplicacioacuten desplegada o delequipo fiacutesico si no se cuenta con un sistema de procesamiento de registro unose puede encontrar con muacuteltiples terminales abiertas inspeccionando numerososficheros de registro buscando posibles errores Ademaacutes no dejan de ser solucio-nes que para usar eficientemente se debe conocer parte de su funcionamientoy sintaxis a la hora de describir la tareas lo que supone un esfuerzo antildeadido yaque cada una tiene sus particularidades y liacutemites
45
82 Conclusiones
En una sociedad cada vez maacutes digital las empresas deben adaptarse a unmercado cuya demanda de contenido no deja de crecer Las nuevas arquitecturascomo microservicios asiacute como la gran cantidad de datos generada implica queuna mejor gestioacuten de los recursos y la rapidez para desplegar o escalar solucionesdando valor al cliente lo maacutes raacutepido posible es uno de los objetivos de todas lasempresas de base tecnoloacutegica
Las ventajas que ofrecen los planificadores con aplicaciones distribuidas sonnumerosas sin ir maacutes lejos empresas tan punteras como Google llevan maacutesde 10 antildeos orquestando contenedores24 Por un lado permiten aumentar elrendimiento de los equipos propios y por otro implementar un servicio comoplataforma para despliegues distribuidos sobre cualquier conjunto hardware deesta forma se provee un servicio similar al de la nube puacuteblica pero con laprincipal diferencia de que se elimina la independencia con el proveedor (vendorlock-in) esto es las aplicaciones no tienen limitaciones impuestas por eacuteste talescomo lenguaje de programacioacuten o herramientas y permite despliegues hiacutebridosentre recursos propios y la nube
83 Objetivos conseguidos
Implementacioacuten de los planificadores propuestos en la nube Se ha en-tendido y detallado el funcionamiento de estas herramientas y se hanimplementado en el servicio de infraestructura de Microsoft Azure
Despliegue de aplicaciones y servicios distribuidos Servicios que se usanactualmente en la industria del desarrollo software asiacute como una aplica-cioacuten web con una arquitectura moderna han sido desplegados de formadistribuida en los equipos cumpliendo con la funcionalidad esperada ade-maacutes de consiguiendo una alta disponibilidad
Aproximacioacuten de arquitectura escalable Se ha hecho una aproximacioacutende infraestructura escalable de forma que sea parcialmente extrapolable aotros proveedores
24httpwwwnextplatformcom20160322decade-container-control-google
46
84 Liacuteneas de investigacioacuten
Siguiendo con la materia de este proyecto se presentan posibles liacuteneas deinvestigacioacuten
Analizar el despliegue con estas herramientas de aplicaciones de Big Datay comparar la eficiencia con respecto a soluciones especializadas
Analizar el rendimiento de los algoritmos de planificacioacuten antes pruebasde estreacutes y situaciones de alta contienda
Comparar el uso de estas herramientas con las praacutecticas actuales de laindustria o implementacioacuten en un sistema de produccioacuten real
47
Referencias
[1] LA Barroso y U Houmllzle laquoThe Datacenter as a Computer An Introduc-tion to the Design of Warehouse-Scale Machinesraquo En Morgan amp ClaypoolPublishers ()
[2] Systems Research Group ndash NetOS (University of Cambridge) The evolu-tion of cluster scheduler architectures 2016 url httpswwwclcamacukresearchsrgnetoscamsasblog2016-03-09-scheduler-architectureshtml
[3] A Das I Gupta y A Motivala SWIM Scalable Weakly-consistent Infection-style Process Group Membership Protocol Inf teacutec Dept of ComputerScience Cornell University url https www cs cornell edu ~asdasresearchdsn02-swimpdf
[4] D Dubhashi y A Das Mastering Mesos PACKT Publishing mayo de2016
[5] The Apache Software Foundation Apache Mesos documentation urlhttpsmesosapacheorg
[6] David Greenberg Building Applications on Mesos OrsquoReilly Media 2016[7] Armand Grillet Comparison of Container Schedulers Inf teacutec Technische
Universitaumlt Berlin[8] HashiCorp Consul documentation url httpswwwconsulio[9] HashiCorp Nomad documentation url httpsdcosio[10] Dan C Marinescu Cloud computing theory and practice Morgan Kauf-
mann 2013[11] Mesosphere DCOS documentation url httpswwwnomadproject
io[12] Microsoft Azure documentation url httpsazuremicrosoftcom
es-esdocumentation[13] D Ongaro y J Ousterhout In Search of an Understandable Consensus
Algorithm Inf teacutec Stanford University url httpsraftgithubioraftpdf
[14] Fei Teng laquoRessource allocation and schelduling models for cloud compu-tingraquo Tesis de mtriacutea Ecole Centrale Paris 2011
[15] A Williams y col Automation and Orchestration with Docker and Contai-ners A Comprehensive Overview of the Docker and Container Ecosystem3 The New Stack 2016
48
- Resumen
- Summary
- Iacutendice de figuras
- Introduccioacuten y objetivos
-
- Contexto
- Objetivos
- Estructura del documento
-
- Cloud Computing
- Nuevas cargas de trabajo
- Gestioacuten de recursos Planificadores
-
- Sistemas distribuidos
-
- Clasificacioacuten
-
- Herramientas
-
- DCOS
-
- Apache Mesos
- Ejemplos de uso
-
- Nomad
-
- Protocolo de consenso Raft
- Protocolo gossip SWIM
- Planificacioacuten
-
- Casos de uso y despliegue
-
- Aplicacioacuten Web
-
- DCOS
- Nomad
-
- Servicio de integracioacuten continua
-
- DevOps
- Integracioacuten Continua
- Jenkins con Nomad
- Jenkins con DCOS
-
- Escalando la infraestructura
-
- Disentildeo
- Implementacioacuten
-
- Resultados y conclusiones
-
- Comparacioacuten
- Conclusiones
- Objetivos conseguidos
- Liacuteneas de investigacioacuten
-
Resumen
Las empresas punteras en tecnologiacutea e innovacioacuten cuentan con numerososrecursos de computacioacuten para llevar a cabo los diversos servicios que sustentanel proceso de negocio En general a estos equipos se les asignan de forma es-taacutetica las distintas tareas lo que conlleva un uso ineficiente al no distribuirseacorde con la carga de trabajo ademaacutes del trabajo de mantenimiento que con-lleva De entre las responsabilidades de los profesionales de las tecnologiacuteas dela informacioacuten estaacute gestionar eficientemente estos recursos asiacute como garantizarla disponibilidad de estos servicios atendiendo a las diferentes demandas decapacidad
La motivacioacuten de este trabajo surge de la oportunidad de desplegar las di-ferentes tareas o servicios de una forma maacutes eficiente gracias a la evolucioacuten entecnologiacuteas como la virtualizacioacuten almacenamiento distribuido o redes definidaspor software asiacute como la mejora y el abaratamiento de los enlaces de comunica-ciones que suponen un cambio de enfoque a la hora de disentildear la infraestructurade los sistemas de informacioacuten
En particular en este proyecto se va a entrar en detalle en herramientas cuyoobjetivo es optimizar los recursos y ademaacutes dar ciertas garantiacuteas de escalabili-dad disponibilidad y tolerancia a fallos De entre las soluciones que existen enla industria hemos seleccionado dos de coacutedigo abierto que alcanzan los objeti-vos definidos DCOS desarrollada por la empresa Mesosphere y basado en elproyecto Apache Mesos y Nomad creada por Hashicorp
En primer lugar se realizaraacute un anaacutelisis del funcionamiento de estas tecno-logiacuteas al que posteriormente seguiraacute el despliegue de casos de uso en la nube yfinalmente las conclusiones a las que se han llegado comparando el rendimientode ambas Con ello se pretende dar una perspectiva de la funcionalidad de estastecnologiacuteas y como encajan en la perspectiva actual dentro de las tecnologiacuteas dela informacioacuten
Palabras clave Cluacutester Gestor de recursos Planificador Compu-tacioacuten en la nube Apache Mesos HashiCorp Nomad MesosphereDCOS
iii
iv
Summary
Tech-savvy companies have a large amount of computational resources tohandle the services that support the business process Typically tasks are al-located in these computers in a static way which is inefficient due to the factthat they are not distributed according to the workload besides involving fur-ther maintenance work Among the responsibilities of Information Technologyprofessionals is efficiently managing these resources and providing some guaran-tees of availability of those services according to the different capacity demands
The motivation of this project comes from the opportunity of efficiently dis-tributing the different tasks or services of an enterprise thanks to the evolutionof technologies such as virtualization distributed storage or software defined net-works but also with the improvement and cost reduction of the communicationlinks a potential turning point in the approach of designing IT infrastructures
This project goes into more detail on tools which pursue resource optim-ization availability scalability and fault tolerance of services Amongst theexisting solutions in the industry two open source projects have been chosenboth achieving the predefined objectives DCOS developed by the companyMesosphere and based on the Apache Mesos project and Nomad developed byHashiCorp
Firstly the internals of these two technologies will be studied followed by adeployment of use cases in both of them in the cloud Lastly the conclusionsreached comparing their performance will be described By this it is intendedto provide a perspective of the functionality of these tools and how they fit inthe nowadays perspective on Information Technology
Keywords Cluster Resource Manager Cluster Scheduler CloudComputing Apache Mesos HashiCorp Nomad Mesosphere DCOS
v
vi
Iacutendice
Resumen III
Summary V
Iacutendice de figuras IX
1 Introduccioacuten y objetivos 1
11 Contexto 1
12 Objetivos 2
13 Estructura del documento 2
2 Cloud Computing 3
3 Nuevas cargas de trabajo 5
4 Gestioacuten de recursos Planificadores 8
41 Sistemas distribuidos 8
411 Clasificacioacuten 10
5 Herramientas 13
51 DCOS 14
511 Apache Mesos 15
512 Ejemplos de uso 18
52 Nomad 19
521 Protocolo de consenso Raft 20
vii
522 Protocolo gossip SWIM 23
523 Planificacioacuten 24
6 Casos de uso y despliegue 27
61 Aplicacioacuten Web 27
611 DCOS 28
612 Nomad 33
62 Servicio de integracioacuten continua 40
621 DevOps 40
622 Integracioacuten Continua 40
623 Jenkins con Nomad 42
624 Jenkins con DCOS 42
7 Escalando la infraestructura 43
71 Disentildeo 43
72 Implementacioacuten 44
8 Resultados y conclusiones 45
81 Comparacioacuten 45
82 Conclusiones 46
83 Objetivos conseguidos 46
84 Liacuteneas de investigacioacuten 47
viii
Iacutendice de figuras
1 Comparacioacuten Centro de datos - Computacioacuten en la nube 4
2 Arquitectura Docker 6
3 Planificador monoliacutetico 11
4 Planificador de dos niveles 11
5 Planificador de estado compartido 12
6 Planificador distribuido 12
7 Arquitectura DCOS 14
8 Servicios DCOS 15
9 Arquitectura de Apache Mesos 17
10 Arquitectura multi-regioacuten en Nomad 20
11 Equipos sin consenso ejecutando el protocolo RAFT 21
12 Un equipo pasa a estado candidato (RAFT) 22
13 Cambio en un registro (RAFT) 22
14 Aprobacioacuten del resto de equipos (RAFT) 23
15 Diagrama de tiempo del protocolo SWIM 24
16 Procedimiento de asignacioacuten en Nomad 25
17 Arquitectura aplicacioacuten web 28
18 Infraestructura en Azure 29
19 Arquitectura de la aplicacioacuten web en DCOS 32
20 Despliegue en Azure de Nomad+Consul 35
ix
1 Introduccioacuten y objetivos
11 Contexto
Las tecnologiacuteas de la informacioacuten y la comunicacioacuten estaacuten suponiendo uncambio draacutestico en la sociedad en 2007 comenzaron a aparecer los teleacutefonosinteligentes tal y como los conocemos y nueves antildeos despueacutes se empieza a con-cebir la idea de dar conectividad a todo dispositivo electroacutenico movimiento queha tomado el nombre de Internet de las cosas Para hacerse una idea de la rapi-dez y magnitud de esta evolucioacuten la consultora Excelacom1 ha estimado que enun minuto se realizan 24 millones de buacutesquedas en Google o se ven 278 millonesde viacutedeos en Youtube En una eacutepoca en la que los recursos tecnoloacutegicos crecenexponencialmente y los usuarios demandan mayor contenido y movilidad nocabe duda que las empresas deben adaptarse lo maacutes raacutepidamente posible a esteproceso de digitalizacioacuten movidas por las nuevas necesidades de las personas
Dado el gran volumen de informacioacuten a lo largo de estos antildeos la compu-tacioacuten y el almacenamiento estaacuten pasando de clientes locales a concentrarse engrandes centros de datos una tendencia que Google ha denominado ldquoWarehouse-scale computingrdquo en 2009[1] Este movimiento hacia la computacioacuten desde ser-vidor no solo viene de la necesidad de mejorar la experiencia de los usuariossino tambieacuten de facilitar la gestioacuten y configuracioacuten de los recursos asiacute como laubicuidad de acceso que permite
En 2006 Amazon lanza Amazon Web Services siendo uno de los pionerosen el mercado de los recursos virtuales ofreciendo capacidad de computacioacutencon un coste proporcional exclusivamente a los recursos utilizados Todo ellocambioacute la perspectiva de los modelos tradicionales de TI a la conocida comocomputacioacuten en la nube recursos informaacuteticos que antes suponiacutean barrerasde entrada en ciertos mercados han pasado a ser condicioacuten necesaria para laconstante evolucioacuten de la tecnologiacutea y la sociedad De hecho Cisco estima quepara el antildeo 2019 maacutes del 86 de las cargas de trabajo seraacuten procesadas porcentros de datos en la nube2
1httpwwwexcelacomcomresourcesblog2016-update-what-happens-in-one-internet-minute2httpwwwciscocomcenussolutionscollateralservice-provider
global-cloud-index-gciCloud_Index_White_Paperpdf
1
12 Objetivos
El propoacutesito de este proyecto es estudiar la viabilidad del uso de planifica-dores de recursos para aumentar la eficiencia de eacutestos y facilitar al desarrolladorel despliegue de aplicaciones de forma distribuida y asiacute ofrecer un servicio ca-racterizado por una alta disponibilidad y escalabilidad
A lo largo de este trabajo se han usado algunas de las herramientas quese estaacuten comenzando a desarrollar para hacer frente a este nuevo enfoque degestioacuten de infraestructuras de las tecnologiacuteas de la informacioacuten (en adelanteinfraestructuras TI) realizando pruebas de concepto sobre cada una de ellas
13 Estructura del documento
A continuacioacuten se detalla las secciones que componen este trabajo La es-tructura queda como sigue
Cloud computing Se entra en detalle en este nuevo modelo de negocio queha originado nuevos enfoques y disentildeos de las infraestructuras TI dentrode las organizaciones
Nuevas cargas de trabajo Se explican algunas tecnologiacuteas representativasque estaacuten suponiendo un desafiacuteo para los profesionales de TI a la horade planificar los recursos y que se ven beneficiadas por entornos de tipocloud
Gestioacuten de recursos Planificadores Estado del arte de las tecnologiacuteas degestioacuten de clusters y planificacioacuten de recursos
Herramientas Descripcioacuten detallada del funcionamiento y arquitectura de lasherramientas usadas a lo largo del proyecto
Casos de uso y despliegue Se describe el proceso de implementacioacuten de unaaplicacioacuten web y un servicio de integracioacuten continua con el software pro-puesto
Escalando la infraestructura Se propone un procedimiento con cierta inde-pendencia del proveedor cloud
Resultados y conclusiones Resume las ideas y hechos a los que se ha llegadoademaacutes de introducir liacuteneas de investigacioacuten futuras
2
2 Cloud Computing
El NIST (National Insitute of Standards and Technology) define este con-cepto como un modelo que permite un acceso ubicuo y bajo demanda de formaremota a un conjunto compartido de recursos de computacioacuten que pueden seraprovisionados y liberados con unos miacutenimos esfuerzos de gestioacuten por parte delproveedor del servicio3
Clasificacioacuten
La computacioacuten en la nube abarca una amplia variedad de servicios y enfo-ques por lo que en primer lugar se va a dar una clasificacioacuten para posterior-mente entrar maacutes en detalle Existen distintos modelos de nube atendiendo a lagobernabilidad de la infraestructura seguacuten el NIST
Nubes puacuteblicas Los servicios y recursos son ofertados de forma puacuteblica yson provistos por una organizacioacuten que los comercializa bajo demanda
Nube privada Los recursos son gestionados por una uacutenica organizacioacutenpara su propio uso
Nube comunitaria En este caso la infraestructura es administrada por unconjunto de organizaciones con objetivos comunes
Nube hiacutebrida Una combinacioacuten de las anteriores
A su vez los distintos servicios que ofrece se pueden clasificar atendiendo algrado de control del usuario
Servicios de software (Software as a Service SaaS) El proveedor se encargade toda la gestioacuten de la infraestructura y oferta aplicaciones a las cuales elcliente puede acceder de forma ubicua a traveacutes de diversos clientes comoun navegador web Por ejemplo Office 365 o Google docs
Servicios de plataforma (Platform as a Service PaaS) Modelo de distribu-cioacuten que ofrece la capacidad de desplegar aplicaciones desarrolladas por elcliente usando las herramientas y lenguajes de programacioacuten soportadaspor el proveedor pero sin la posibilidad de gestionar los recursos consu-midos En este caso el cliente solo tiene control sobre la propia aplicacioacuteny algunas configuraciones del entorno Es el caso de Heroku o Google AppEngine
3httpnvlpubsnistgovnistpubsLegacySPnistspecialpublication800-145pdf
3
Servicios de infraestructura (Infrastructure as a Service IaaS) Se ofertanrecursos de computacioacuten puros como procesamiento o almacenamientomediante una plataforma de virtualizacioacuten El cliente puede controlar elsistema operativo componentes de red y aplicaciones
Figura 1 Comparacioacuten Centro de datos - Computacioacuten en la nubeFuente httpsad-hocnet
De entre las numerosas ventajas que ofrece la computacioacuten en la nube se puededestacar su flexibilidad ya que permite aprovisionar recursos y adaptarlos deacuerdo a la demanda reduce el capital inmovilizado y su amortizacioacuten laubicuidad que permite su consumo desde cualquier parte con conexioacuten a la redy la seguridad y fiabilidad que ofrece el proveedor que normalmente cuenta conrecursos geograacuteficamente distribuidos frente a la gestioacuten y mantenimiento derecursos propios
4
3 Nuevas cargas de trabajo
Las organizaciones que cuentan con sus propios infraestructuras TI han co-menzado a adoptar un enfoque de nube privada para gestionar las tareas ofunciones informaacuteticas sobre las que se sustentan el negocio ya que una es-tructura virtualizada puede ofrecer ventajas con respecto a las adaptaciones decentros de datos tradicionales en los aacutembitos de rendimiento escalabilidad eincluso seguridad4
A su vez se han desarrollado nuevas tecnologiacuteas que suponen cargas detrabajo dinaacutemicas y con gran intensidad de consumo de datos para las empresasque se ven beneficiadas al desplegarlas en recursos virtualizados
Big data
Con la creciente aceptacioacuten de las tecnologiacuteas TIC por parte de la sociedadla cantidad de datos generados en la red es ingente Las profesionales de TI tienecomo objetivo extraer valor de eacutestos para por ejemplo prever las tendencias delmercado Sin embargo este incremento exponencial hace que su procesamientoy almacenamiento requiera de un sistema con gran escalabilidad dado el hechode que una sola maacutequina no puede proveer de la capacidad necesaria
Integracioacuten continua
Modelo informaacutetico que consiste en hacer integraciones automaacuteticas de unproyecto con cualquier cambio en el coacutedigo con el objetivo de detectar fallosde forma temprana Esto implica la compilacioacuten del coacutedigo y su ejecucioacuten enun entorno de pruebas automaacuteticamente un proceso que mediante tecnologiacuteasde virtualizacioacuten permiten simular entornos con eficiencia y rapidez Su imple-mentacioacuten en sistemas distribuidos permite tanto una mejor planificacioacuten comoun mejor rendimiento de los recursos
Arquitectura de microservicios
Enfoque para desarrollar aplicaciones software como un conjunto de serviciosautoacutenomos que se comunican entre siacute a diferencia de aproximaciones monoliacuteti-cas donde la loacutegica del servicio estaacute desarrollada como una unidad Un sistemadistribuido permite el despliegue de los componentes en distintas maacutequinas loque mejora tanto su escalabilidad como la tolerancia a fallos
4httpswwwakamaicomesesresourcespublic-private-cloudjsp
5
Docker
Proyecto de coacutedigo abierto que facilita y automatiza el despliegue de aplica-ciones al encapsular el entorno de trabajo en contenedores Linux una tecnologiacuteaque permite a un sistema fiacutesico ejecutar muacuteltiples instancias de sistemas opera-tivos aislados mediante entornos virtuales con sus propios espacios de procesosy redes pero compartiendo el nuacutecleo (kernel) con el equipo anfitrioacuten
En la figura 2 se compara la pila de una virtualizacioacuten tradicional con res-pecto a los contenedores no se simula el sistema operativo por lo que el procesoes mucho maacutes ligero
Docker se caracteriza por
Autosuficiencia Los contenedores cuentan con las libreriacuteas y configuracio-nes necesarias para ejecutarse de manera autoacutenoma al compartir el nuacutecleo
Portabilidad El hecho de que sean autosuficientes implica que es inde-pendiente del host es decir se puede desplegar en cualquier equipo quesoporte esta tecnologiacutea
Tamantildeo El peso de un contenedor es sustancialmente inferior a otrastecnologiacuteas de virtualizacioacuten
Figura 2 Arquitectura DockerFuente httpsdockercom
6
Los componentes fundamentales de esta herramienta son
Imaacutegenes Describen el entorno de base sobre el que ejecutar el contene-dor por ejemplo la imagen del sistema operativo Ubuntu Sobre eacutesta seconstruyen las aplicaciones particulares del usuario dando lugar a otraimagen
Contenedores Se crean a partir de las imaacutegenes y comprenden todo aquellonecesario para arrancar la aplicacioacuten decir su entorno de ejecucioacuten
bull Voluacutemenes Encargados de gestionar la persistencia de datos e inde-pendientes del ciclo de vida del contenedor
Registros Pueden ser puacuteblicos o privados y almacenan las imaacutegenes elregistro puacuteblico oficial de Docker es Docker Hub
Dadas estas caracteriacutesticas los profesionales TI estaacuten comenzando a adoptarDocker ya que facilita tanto los despliegues como el trabajo compartido en dis-tintos entornos Sin embargo esto requiere de un software que permita desplegarlos distintos contenedores de forma que puedan trabajar en conjunto procesoque se ha denominado orquestacioacuten de contenedores
7
4 Gestioacuten de recursos Planificadores
Para sacar el maacuteximo provecho a las tecnologiacuteas anteriormente descritaslo ideal es desplegarlas en sistemas distribuidos sin embargo esto aumenta lacomplejidad del propio despliegue asiacute como la necesidad de software especiali-zado para ello Se necesitan algoritmos de planificacioacuten que permitan obtener elmaacuteximo rendimiento de los recursos por un lado y dar ciertas garantiacuteas de quetodas las tareas y procesos se van a ejecuta por otro
41 Sistemas distribuidos
En primer lugar se definen los sistemas distribuidos o clusters como unconjunto de ordenadores conectados entre siacute cuyo objetivo es trabajar como unauacutenica instancia de gran capacidad5
Su clasificacioacuten variacutea de acuerdo a cada autor pero en general se puedendividir seguacuten su objetivo en alto rendimiento aquellos cuyo objetivos es proveerde gran capacidad de coacutemputo gracias al conjunto de los nodos y alta disponi-bilidad con los cuales se busca la fiabilidad del sistema mediante redundanciayo balanceo de carga
El intereacutes de este proyecto recae en los uacuteltimos ya que el objetivo es porun lado ofrecer al desarrollador un entorno donde desplegar sus aplicaciones deforma distribuida y por otro maximizar el rendimiento de los recursos
De forma general las caracteriacutesticas que se buscan son las siguientes
Elasticidad Adaptacioacuten a cargas dinaacutemicas de trabajo aumentando (o dis-minuyendo) recursos de manera automaacutetica de tal forma que la utilizacioacutensea lo maacutes cercana a la demanda
Disponibilidad Capacidad de un sistema para mantener el servicio fun-cional
Tolerancia a fallos Recuperacioacuten del servicio ante el fallo de un compo-nente
Balanceo de carga Compartir las tareas entre las diferentes maacutequinasredundadas evitando asiacute puntos de uacutenico fallo
5httpsenwikipediaorgwikiComputer_cluster
8
Los programas que se implementan en entornos distribuidos se caracterizanpor ejecutarse de forma concurrente en equipos independientes estar conectadospor una red que introduce fallos aleatorios y no compartir memoria ni reloj Estoimplica entre otras cosas que
Los nodos soacutelo tienen un acceso raacutepido a su memoria local por lo quecualquier informacioacuten relativa al estado global puede ser potencialmenteerroacutenea
Las maacutequinas pueden sufrir caiacutedas de forma aleatoria
El intercambio de informacioacuten puede fallar ya sea por error en transmisioacuteno por caiacuteda de los nodos
Estas dificultades se ponen de manifiesto en el teorema de CAP en cienciasde la computacioacuten el teorema de CAP que lanzado inicialmente como conjetu-ra en el antildeo 2000 por Eric Brewer (motivo por el cual al teorema se le conoceformalmente como teorema de Brewer) y posteriormente demostrado en el antildeo20026 establece que es imposible para un sistema de coacutemputo distribuido ga-rantizar simultaacuteneamente dos de las tres propiedades siguientes
Consistencia (Consistency) es decir que todos los nodos vean la mismainformacioacuten al mismo tiempo Se busca que un cambio en el sistema soacutelose ejecute satisfactoriamente si y soacutelo si se efectuacutea a todos las maacutequinasde tal forma que los datos entre ellos nunca difieren y la respuesta a unapeticioacuten sea la misma independientemente del nodo que la atienda
Disponibilidad (Availability) esto es la garantiacutea de que toda peticioacuten debeobtener una respuesta (servicio funcional) aunque exista inconsistenciaentre nodos
Tolerancia al particionado (Partition Tolerance) es decir que el sistemasiga funcionado a pesar de un fallo en la comunicacioacuten entre los equipos
Por todo lo expresado anteriormente conseguir un sistema distribuido capazde ofrecer procesamiento de forma transparente implica una arquitectura TIcompleja Se requieren de subsistemas y herramientas que permitan la cohesioacutenentre todos los nodos
Gestor de los recursos de las diferentes maacutequinas
Monitorizacioacuten tanto de los servicios activos como de la funcionalidad delsistema ademaacutes de poliacuteticas para recuperacioacuten de fallo
Protocolos de consenso que permitan a los nodos ser consistentes con elestado global del cluster
6urlhttpsgroupscsailmitedutdspapersGilbertBrewer2pdf
9
Herramientas de descubrimiento de servicios que permita la comunicacioacutenentre tareas distribuidas
Planificadores Encargados de distribuir las tareas y procesos en las dife-rentes maacutequinas asignaacutendole parte de su capacidad
Los planificadores del ingleacutes cluster schedulers son un componente funda-mental por lo que vamos a entrar un poco maacutes en detalle en ellos
Planificadores (Cluster Schedulers)
Es el software encargado de monitorizar los recursos usados por cada maacute-quina perteneciente a un cluster y distribuir la carga de trabajo entre ellas deacuerdo a un poliacutetica o reglas
Este tipo de herramientas comparten cierta terminologiacutea que es relevantedefinir
Tarea Unidad de trabajo computacional comprendida por una secuenciade instrucciones datos de entrada y recursos asociados Por ejemplo laejecucioacuten de un comando o el arranque de una base de datos
Nodo Cualquier maacutequina integrante de un cluster En una arquitecturamaestro-esclavo se definen dos roles
bull Cliente Agente Esclavo Aquellos ordenadores que se encargan deejecutar las tareas
bull Maestro Servidor Su objetivo es mantener el estado del cluster ygestionar sus recursos
411 Clasificacioacuten
A lo largo de los uacuteltimos antildeos se han desarrollado diferentes tipos de plani-ficadores[2]
Monoliacutetico
Un solo planificador que se encarga de distribuir todas las tareas entran-tes La mayoriacutea de los planificadores en computacioacuten de alto rendimiento asiacutecomo Borg desarrollado por Google son de este tipo En la figura 3 se pue-de observar de forma graacutefica el procedimiento siendo las cajas grises maacutequinaspertenecientes al cluster y los ciacuterculos las tareas a asignar
10
Figura 3 Planificador monoliacuteticoFuente httpswwwclcamacuk
Planificacioacuten de dos niveles
La mayoriacutea de los clusters ejecutan aplicaciones con distintas necesidadesdesde procesos casi instantaacuteneos hasta servicios persistenteslo que implica dis-tintas necesidades de recursos
Por ello la planificacioacuten a dos niveles distingue dos funciones la gestioacutende recursos (gestor) y la disposicioacuten de las tareas (planificador) Cada serviciotiene su propio planificador de tal manera que el gestor les ldquoofertardquo recursosde acuerdo a una poliacutetica y los planificadores se encargan de escoger la maacutesadecuada Esto permite que el proceso de distribucioacuten sea maacutes acorde con lasnecesidades de los diferentes servicios Apache Mesos que detallaremos maacutesadelante sigue este esquema
Como desventaja cabriacutea sentildealar que esta programacioacuten implica que los pla-nificadores pierden la vista general de la infraestructura y las tareas soacutelo puedenejecutarse con los recursos que les son ofrecidos lo que dificulta la implementa-cioacuten de prioridades de ejecucioacuten de tareas entre otras
Figura 4 Planificador de dos niveles
11
Planificacioacuten de estado compartido
Muacuteltiples reacuteplicas del estado del cluster se actualizan independientementepara cada planificador como se observa en la figura 5 cuando sucede un cambiode forma local el planificador se encarga de informar al resto
Ejemplo de este tipo son Omega la evolucioacuten de Borg por parte de GoogleMicrosoft Apollo y Nomad que usaremos para los casos de uso
De entre las desventajas se puede destacar el hecho de que en general losnodos trabajan con informacioacuten desactualizada lo que conlleva una degradacioacutendel rendimiento en situaciones de alta contienda
Figura 5 Planificador de estado compartido
Planificacioacuten distribuida
En este caso no existe coordinacioacuten entre los distintos planificadores Cadauno de ellos funciona con su propia vista del cluster Las tareas pueden serorganizadas por cualquiera de ellos y desplegadas en cualquier parte del clusteren base a la aleatoriedad y multiplexacioacuten estadiacutestica de los flujos de trabajosin ninguacuten control central
Figura 6 Planificador distribuido
12
5 Herramientas
En la industria comienzan a aparecer soluciones software de coacutedigo abiertoque aglutinan los servicios necesarios para gestionar la infraestructura TI de ma-nera maacutes eficaz El objetivo es doble se busca facilitar la gestioacuten de los recursosde computacioacuten para organizaciones con instalaciones propias mediante su usocon un enfoque cloud esto es desplegar aplicaciones a traveacutes de un conjuntode ordenadores de forma transparente y sin tener en cuenta la infraestructurasubyacente o aprovechar el maacuteximo rendimiento de la infraestructura de losproveedores cloud puacuteblicos de forma que se tiene el maacuteximo control sobre eacutestapero no se depende de las soluciones propietarias permitiendo asiacute despliegueshiacutebridos
Entre estas herramientas se pueden destacar
OpenStack Proyecto desarrollado por la fundacioacuten del mismo nombre paraproporcionar servicios de infraestructuras (IaaS) basado en componentesque se comunican a traveacutes de APIs El componente Magnum incluye mo-tores de orquestacioacuten de contenedores
Kubernetes Sistema de orquestacioacuten de contenedores Docker creado por Goo-gle
CoreOs Sistema operativo basado en Linux disentildeado para despliegues distri-buidos sobre contenedores incluyendo mecanismos de descubrimiento deservicio y comparticioacuten de configuracioacuten
Docker Swarm Herramienta nativa de orquestacioacuten de contenedores Docker
YARN Entorno de gestioacuten de recursos y aplicaciones distribuidas de Hadoopuna libreriacutea software de procesamiento de grandes conjuntos de datos
Como podemos observar existe un gran rango de opciones para gestionar lainfraestructura desde un bajo nivel como puede ser OpenStack hasta Kuberne-tes o Docker Swarm que ofrecen exclusivamente orquestacioacuten de contenedores
En este trabajo se ha optado por Mesosphere DCOS y HashiCorp Nomadque se encuentran en el teacutermino medio su objetivo es proporcionar serviciosde plataforma que permitan la coexistencia dediferentes cargas de trabajo en elcluster
13
51 DCOS
DCOS es un proyecto de coacutedigo abierto7 creado y desarrollado por la empre-sa Mesosphere Se describe como un sistema operativo distribuido que abstraelos recursos de un cluster (capacidad de procesamiento memoria) permite lagestioacuten de muacuteltiples ordenadores de forma transparente y simplifica la instala-cioacuten de aplicaciones distribuidas
Su arquitectura se puede comparar a la de Linux en teacuterminos de nuacutecleo(kernel) y espacio de usuario El primero consta de recursos protegidos a losque no puede acceder el usuario e involucra operaciones de bajo nivel comoasignacioacuten de recursos o aislamiento de procesos En el espacio de usuario seejecutan las aplicaciones y servicios de maacutes alto nivel
Siguiendo con este siacutemil el nuacutecleo de DCOS estaacute basado en Apache Mesosque se explicaraacute en un apartado posterior y el espacio de usuario que estaacute com-prendido por los componentes del sistema esto es las diferentes herramientasque en conjunto conforman DCOS y los servicios encargados de planificar yejecutar las aplicaciones y tareas del usuario
Figura 7 Arquitectura DCOSFuente httpsdcosio
De entre los componentes que conforman DCOS destacan
Admin Router Balanceador de carga central basado en NGINX que dis-pone un proxy entre todos los servicios en el puerto 80 permitiendo sugestioacuten mediante la interfaz graacutefica Ademaacutes se encarga de la autenticacioacutenpara acceder al panel de administracioacuten
Cosmos Gestor de paquetes de las aplicaciones
Diagnostics Se ejecuta en todos los nodos y se encarga de monitorizar elestado de los daemons que sustentan DCOS
7Desde abril de 2016 httpsmesospherecomblog20160419open-source-dcos
14
Exhibitor Gestiona y automatiza el despliegue de ZooKeper la herra-mienta que provee de configuracioacuten centralizada y registro de nombres
Marathon Equivale al proceso init de los sistemas tipo Unix esto es elprimer proceso en ejecucioacuten tras la carga del kernel y que genera los demaacutesprocesos Se encarga de arrancar y monitorizar las aplicaciones y servicios
Mesos-DNS Servicio de DNS interno que define el dominio mesos pa-ra nodos y tareas en el cluster es decir permite resolver nombres conindependencia de la direccioacuten fiacutesica
Minuteman Balanceador de carga integrado a nivel TCPUDP disponiblepara las propias aplicaciones
Por otra parte se definen como servicios a las diferentes aplicaciones dis-tribuidas que DCOS permite instalar en el cluster y que pueden haber sidodesarrollados por la misma empresa Mesosphere o por terceros por ejemploApache Spark Jenkins o Apache Hadoop En la figura 8 se muestra un diagramade los servicios disponibles incluyendo algunos de las aplicaciones distribuidasque soporta DCOS
Figura 8 Servicios DCOSFuente httpsdcosio
511 Apache Mesos
El nuacutecleo de DCOS estaacute basado en Apache Mesos un proyecto de coacutedigoabierto creado por la Universidad de California Berkeley y desarrollado actual-mente por la fundacioacuten Apache Se trata de un administrador de clusters queabstrae los recursos y los dispone para diferentes aplicaciones y entornos de tra-bajo distribuidos (frameworks) mediante una interfaz comuacuten En el momento deredaccioacuten de este proyecto Apache Mesos soportaba una variedad de entornosque abarcaba desde Big Data (Apache Spark Hadoop) hasta bases de datos(Cassandra Hypertable)
15
Arquitectura
Mesos se basa en la asignacioacuten de dos roles diferentes a los nodos
Maestros (Masters) Se encargan de la gestioacuten y reparticioacuten de los recursospara los diferentes entornos de trabajo mediante ldquoofertas de recursosrdquo deacuerdo a los disponibles y a la poliacutetica de asignacioacuten (planificacioacuten en dosniveles)
Esclavos (Slaves) Ordenadores donde se ejecutaraacuten las aplicaciones y cu-yos recursos son ofertados por los maestros
En el caso de fallo del maestro las tareas pueden seguir ejecutaacutendose perono se podraacute asignar nuevos recursos ni tareas por ello pueden existir varios enel cluster para configuraciones de alta disponibilidad pero soacutelo uno orquesta alos esclavos
Para la eleccioacuten del master liacuteder Mesos usa Apache ZooKeeper un proyectode software desarrollado por la misma fundacioacuten cuyo objetivo es proveer deun servicio de configuracioacuten centralizado y registro de nombres8
Por otra parte los entornos de trabajo son los programas que deciden final-mente queacute recursos se van a usar y se encargan de que los esclavos ejecuten lastareas Eacutestos se ejecutan sobre Mesos y constan de dos componentes
Planificador (Scheduler) Optimiza y decide los recursos a utilizar de losofertados informando a los Masters
Procesador (Executor) Ejecuta las aplicaciones o servicios en los esclavos
El objetivo final es conseguir una interfaz liviana tolerante a fallos paracualquier tipo de entorno de trabajo de tal manera que en los esclavos del clusterpuedan ejecutarse simultaacuteneamente tareas con necesidades y duracioacuten diferentesPara ello se basa en dos conceptos asignacioacuten y aislamiento de recursos
Asignacioacuten de recursos
En el cluster pueden coexistir entornos de trabajo con tareas de larga dura-cioacuten y con gran consumo de recursos con tareas cortas que los ocupan y liberancon rapidez El maestro integra un moacutedulo de asignacioacuten de recursos (allocationmodule) que se encarga del algoritmo de distribucioacuten
En el momento de escribir este proyecto estaban desarrollados dos moacutedulosuno mediante el cual el usuario puede asignar prioridades y otro que implementa
8httpszookeeperapacheorg
16
el algoritmo Dominant Resource Fairness9 a grandes rasgos se determina entodos los esclavos la tarea en ejecucioacuten que necesita maacutes recursos y se calcula laproporcioacuten del recurso de mayor peso con respecto al total por ejemplo si unatarea ocupa 2 GB de memoria con respecto a 10 GB totales que tiene el clusterse le asigna un dominant share del 20 la tarea se asignaraacute al nodo con menordominant share
Aislamiento de recursos
Para conseguir que tareas de diferentes entornos de trabajo y con distin-ta naturaleza se ejecuten simultaacuteneamente en un mismo nodo Mesos usa loscontenedores Linux (descritos en la seccioacuten 3)
Funcionamiento
La figura 9 muestra el esquema de la arquitectura de Apache Mesos conalta disponibilidad (tres maestros) y con dos entornos de trabajo ejecutaacutendo-se Hadoop que permite el almacenamiento y procesamiento de gran cantidadde datos para proyectos de big data y un sistema que implementa la interfazsistema de paso de mensajes MPI
Como se puede observar el sistema ZooKeeper elige a un solo maestro comoliacuteder y eacuteste orquesta el cluster comunicando los esclavos con los planificadoresde los diferentes entornos de trabajo Tambieacuten se puede observar como las tareasde los distintos entornos estaacuten distribuidas entre los tres esclavos disponibles
Figura 9 Arquitectura de Apache MesosFuente httpsmesosapacheorg
El proceso de asignacioacuten se realiza como sigue en primer lugar un usuariosolicita la ejecucioacuten de una tarea mediante la interfaz de cada entorno de traba-jo (interfaz graacutefica API HTTP ) De forma paralela un esclavo informa almaestro de los recursos que tiene libres En consecuencia eacuteste se lo notifica almoacutedulo de asignacioacuten que en funcioacuten de su configuracioacuten decide cuaacutento ofertar
9httpspeopleeecsberkeleyedu~aligpapersdrfpdf
17
y a queacute entorno de trabajo y enviacutea la oferta a los planificadores Eacutestos respondenal maestro con queacute recursos ha decidido usar para cada tarea Finalmente lastareas son enviadas al esclavo seleccionado el cual asigna los recursos indicadosal procesador (executor) quien finalmente las ejecuta
Cabriacutea pensar que esta metodologiacutea puede conducir a situaciones en lasque un entorno podriacutea quedarse con tareas sin ejecutarse a la espera de unaoferta satisfactoria para ello Mesos implementa un sistema de filtros medianteel cual los entornos especifican los requisitos miacutenimos que debe cumplir unaoferta por ejemplo se puede especificar en queacute nodos debe desplegarse la tareaEste sistema estaacute disentildeado asiacute con el objetivo de mantener lo maacutes transparenteposible esta herramientas de forma que acepte entornos de trabajo de distintasnaturalezas
512 Ejemplos de uso
Grandes empresas estaacuten usando Apache Mesos con eficacia de acuerdo a susnecesidades e infraestructuras Caben destacar
Ebay En el modelo de implementacioacuten continua en esta empresa10 cadadesarrollador cuenta con su propia instancia que se ejecuta en una maacutequinavirtual dedicada lo que ha conllevado un uso de los recursos poco eficiente Enuna prueba de concepto consiguieron realizar una herramienta de integracioacutencontinua distribuida basada en un cluster con Apache mesos y con el entornoMarathon y Jenkins
Apple Anuncioacute que el motor de su famosa herramienta de asistencia per-sonal para iPhones Siri estaacute desplegada sobre Apache Mesos11 Para ello handesarrollado su propio entorno para facilitar a los ingenieros a desplegar los ser-vicios que la herramienta necesita para resolver las peticiones de los usuarios
Twitter Desarrolloacute su propio entorno denominado Aurora y actualmentegestionan sus recursos y miden el coste de las tareas que los empleados usancon el objetivo de que sean conscientes del gasto que puede suponer un usoinadecuado de la infraestructura12
10httpwwwebaytechblogcom20140404delivering-ebays-ci-solution-with-apache-mesos-part-i11httpwwwbusinessinsidercomapple-siri-uses-apache-mesos-2015-812httpswwwlinuxcomNEWS4-UNIQUE-WAYS-UBER-TWITTER-PAYPAL-AND-HUBSPOT-USE-APACHE-MESOS
18
52 Nomad
Herramienta de coacutedigo abierto de gestioacuten de clusters creada y desarrolladapor Hashicorp13 que permite el despliegue de aplicaciones y procesos de formadistribuida
Las principales diferencias con Apache Mesos a grandes rasgos son
Arquitectura maacutes ligera Nomad soacutelo requiere de un fichero para funcionarejecutaacutendolo con las correspondientes configuraciones en todos los nodosrealiza las funciones de gestioacuten del cluster eleccioacuten de liacuteder planificacioacutende recursos y ejecucioacuten de las tareas
Centro de datos y regiones muacuteltiples Su arquitectura estaacute orientada afacilitar la gestioacuten de diferentes centros de datos geograacuteficamente distri-buidos
Entorno de ejecucioacuten Las tareas se definen y son interpretadas mediantecontroladores integrados en Nomad que se valen de los recursos y herra-mientas de los nodos clientes para ejecutarlas Esta integracioacuten dificultael desarrollo de controladores por parte de terceros a diferencia de Mesosque delega dicha responsabilidad en los entornos de trabajo externos alproyecto
Usa un planificador de estado compartido con respecto a la planificacioacutenen dos niveles de Mesos
Antes de entrar en maacutes detalle en la arquitectura es importante definir lossiguientes teacuterminos
Controlador (Driver) Software que se encarga de interpretar las definicionesde las tareas y ejecutarlas semejante a los procesadores de los entornosde trabajo de Mesos A la hora de redactar este proyecto Nomad contabacon controladores para contenedores Docker virtualizacioacuten de maacutequinasmediante el emulador QEMU aplicaciones java y archivos binarios
Grupo de trabajo (Task Group) Conjunto de tareas que se ejecutan en elmismo nodo cliente
Trabajo (Job) Conjunto loacutegico de tareas y grupos de trabajo que se despliegana la vez
Asignacioacuten (Allocation) Relacioacuten entre un grupo de trabajo y el cliente don-de se ejecuta
Evaluacioacuten (Evaluation) Proceso mediante el cual Nomad planifica y ges-tiona el registro o actualizaciones de los trabajos
13httpswwwhashicorpcom
19
Nomad sigue una arquitectura maestro-esclavo similar a la de Apache Mesosmuacuteltiples servidores acuerdan entre siacute un liacuteder que gestiona la planificacioacuten detareas en los clientes que soacutelo conocen sus asignaciones y las ejecutan
Todos los servidores participan paralelamente en tareas de planificacioacuten derecursos y asignacioacuten de tareas y ademaacutes entre ellos eligen un liacuteder que seencarga de la coordinacioacuten de la suscripcioacuten de los clientes al cluster y de lagestioacuten de las peticiones
Los clientes estaacuten configurados para comunicarse con el servidor usando lla-madas a procedimiento remoto (RPC por sus siglas en ingleacutes) que permite unordenador ejecutar coacutedigo en otra maacutequina Mediante esta tecnologiacutea los nodosclientes avisan de su estado e informa de sus asignaciones recursos y controla-dores disponibles
Existe la posibilidad de gestionar varios centros de datos agrupados en regio-nes eacutestas son independientes pero permite definir tareas o comprobar el estadode todas ellas desde cualquier punto A continuacioacuten se muestra una figura dela arquitectura a alto nivel de esta configuracioacuten
Figura 10 Arquitectura multi-regioacuten en NomadFuente httpswwwnomadprojectio
La herramienta se sustenta sobre tres protocolos fundamentales un protocolode consenso entre los servidores para compartir informacioacuten sobre su estado yel liacuteder un protocolo Gossip para la gestioacuten entre regiones y el planificador detareas
521 Protocolo de consenso Raft
El objetivo es obtener consistencia en un conjunto de nodos que comparteninformacioacuten es decir si un cliente realiza un cambio que todos los nodos veanla misma informacioacuten a la vez y ademaacutes sea tolerante a fallos Para ello se basaen el algoritmo Raft[13] que se detalla brevemente a continuacioacuten
20
Los nodos participantes en el algoritmo pueden estar en tres estados
Liacuteder (Leader) Todos los cambios que realicen en el cluster pasan por eacutel pri-mero
Seguidor (Follower) Nodo pasivo cuya responsabilidad es responder a laspeticiones del nodo liacuteder
Candidato (Candidate) Maacutequina que no ha encontrado liacuteder y solicita sueleccioacuten
Supongamos que tenemos cinco equipos que acaban de arrancar el protocoloEn la figura 11 se observan los nodos y sus respectivos registros a la derecha
Figura 11 Equipos sin consenso ejecutando el protocolo RAFTFuente httpsgithubcomongardieraftscope
Al comenzar todos los nodos son seguidores esperando recibir comunicacioacutende un nodo que actuacutee como liacuteder Cada nodo tiene un tiempo de espera aleatoriodespueacutes del cual si no es informado por un liacuteder pasa a estado candidato y pideel ldquovotordquo al resto de los participantes El algoritmo divide el tiempo en plazos uncandidato pasa a liacuteder si recibe la mayoriacutea de los votos en un plazo determinadoSe define mayoriacutea o cuoacuterum (quorum) comolceil
N2rceil
+ 1 (1)
donde N representa el nuacutemero de nodos
Para el ejemplo propuesto de 5 equipos se requieren de 3 votos Soacutelo losnodos que se encuentren en estado seguidor pueden votar una uacutenica vez a laprimera solicitud que reciba dentro de un plazo
Supoacutengase que el nodo denotado con S1 ha cumplido su tiempo de espera yrealiza la peticioacuten de voto (figura 12) A partir de este momento se pueden dartres casos
La maacutequina gana la eleccioacuten y pasa a ser liacuteder informando al resto
Otro servidor se establece como liacuteder en el mismo momento
Varios nodos pasan a ser candidatos por lo que ninguno consigue los votos
21
Figura 12 Un equipo pasa a estado candidato (RAFT)
Si un candidato recibe un aviso de un liacuteder en el mismo plazo el primeropasa a ser seguidor y se acaba la eleccioacuten de liacuteder
Por otro lado si un equipo candidato no recibe los votos en el plazo y agotasu tiempo de espera avanza al siguiente plazo y repite el proceso de votacioacutenLa tercera posibilidad puede conllevar a un estado indefinido ya que varioscandidatos pueden agotar su tiempo de espera al mismo tiempo y repartir losvotos Para solventarlo el algoritmo establece tiempos de espera aleatorios paralos candidatos
Siguiendo con el ejemplo propuesto el servidor S1 pasa a ser el liacuteder Cadacierto tiempo eacuteste debe realizar avisos a los nodos seguidores para no agotar sutiempo de espera
En este momento el cluster de servidores estaacute en ldquoconsensordquo y la informacioacutenen todos los nodos estaacute actualizada Un cambio en la informacioacuten inicia unproceso de replicacioacuten el liacuteder registra el cambio lo pasa al resto de nodos yuna vez eacutestos responden el cambio se hace efectivo
Supoacutengase que se realiza un cambio en los datos en la figura 13 en la partederecha se observa el cambio en el registro del servidor S1 que informa a losnodos seguidores En consecuencia los nodos registran el cambio y responden aS1
Figura 13 Cambio en un registro (RAFT)
Una vez el cuoacuterum (en el ejemplo tres equipos) informa al liacuteder de que
22
ha registrado el cambio el liacuteder lo hace efectivo en su sistema y notifica a losnodos que hacen lo mismo En la figura 14 el enviacuteo todaviacutea no ha llegado ala maacutequina S3 y se observa que no ha hecho efectivo el cambio (en el registroaparece punteado)
Figura 14 Aprobacioacuten del resto de equipos (RAFT)
Este protocolo funcionaraacute correctamente mientras exista un nuacutemero de nodosen funcionamiento igual o superior al cuoacuterum en el ejemplo propuesto elcuoacuterum es tres por lo que el sistema puede tolerar la caiacuteda de dos de los equipos
522 Protocolo gossip SWIM
Nomad permite la gestioacuten simultaacutenea de varios centros de datos reparti-dos en regiones geograacuteficamente separadas requiriendo de un protocolo ligeroque mantenga a los miembros actualizados sobre los participantes del conjun-to Para ello usa una ligera variante del protocolo SWIM[3] (Scalable Weakly-consistent Infection-style Process Group Membership Protocol) desarrollada porHashiCorp Estaacute clasificado como un protocolo de tipo gossip que debe su nom-bre a la semejanza con coacutemo se distribuye un rumor en una red social
SWIM se sustenta en dos caracteriacutesticas fundamentales la deteccioacuten de fallosy la distribucioacuten de la informacioacuten relativa a los miembros A continuacioacuten sedetalla el funcionamiento de ambos componentes
Deteccioacuten de fallos
Este componente tiene dos paraacutemetros el periodo de protocolo T y el nuacutemerode subgrupos de deteccioacuten de fallos k en los que se dividen los nodos Paracomprobar la comunicacioacuten entre dos maacutequinas usa la utilidad ping basadaen el protocolo ICMP La deteccioacuten de caiacuteda de un servidor sigue el siguientealgoritmo
Durante el periodo T cada miembro Mi de un subgrupo elige otro al azar Mjdel mismo subgrupo y le enviacutea un mensaje ping para comprobar su estado Enel caso de que se cumpla un tiempo de espera determinado por una estimacioacuten
23
del tiempo de ida y vuelta (RTT por sus siglas en ingleacutes) de la red y no hayarespuesta Mi le vuelve a enviar un mensaje ping indirectamente a traveacutes deun nuacutemero k de miembros escogidos aleatoriamente De no recibir ninguna res-puesta Mi establece que Mj ha sufrido un fallo y lo etiqueta como ldquosospechosordquoinformando al componente de distribucioacuten
Figura 15 Diagrama de tiempo del protocolo SWIMFuente httpswwwcscornelledu
Componente de distribucioacuten
Se encarga de informar de cualquier cambio en los miembros a todo el con-junto Los eventos de nodo caiacutedo y la unioacuten o disociacioacuten de un miembro setransmiten a todos los servidores para que actualicen sus lista Para distribuirla informacioacuten a todos los nodos se podriacutea usar el meacutetodo de multicast perosuele estar deshabilitado Por ello se utiliza una teacutecnica de transmisioacuten denomi-nada Piggybacking mediante la cual se adjunta a los propios mensajes PINGy ACK del algoritmo la informacioacuten a distribuir reduciendo asiacute la congestioacutenen la red
523 Planificacioacuten
Proceso encargado de distribuir las tareas entre los nodos clientes de acuerdoa su estado
El planificador de Nomad estaacute basado en las publicaciones de Google sobresus herramientas de gestioacuten de clusters Borg y Omega14 y entiende los trabajosdescritos por el usuario como un estado deseado es decir su despliegue en unamaacutequina cliente de forma correcta y los clientes como el estado actual esto eslo que se encuentra en ejecucioacuten El registro actualizacioacuten o cancelacioacuten de un
14httpresearchgooglecompubspub43438html
24
trabajo asiacute como el fallo de un nodo cliente implican un cambio de estado atramitar por el sistema lo que se define como evaluacioacuten (evaluation) Esto uacutelti-mo supone comparar el estado actual (clientes) con el estado deseado (conjuntode trabajos registrados) y enviarlos a los planificadores correspondientes que seencargaraacuten de asignar las tareas a los nodos clientes
Figura 16 Procedimiento de asignacioacuten en NomadFuente httpswwwnomadprojectio
En la figura 16 se observa el flujo de trabajo en el que las distintas evalua-ciones se encolan en el evaluation broker que se ejecuta en el servidor liacuteder ygestiona las evaluaciones pendientes asignaacutendoles prioridades
A continuacioacuten los nodos servidores ejecutan los scheduling workers queprocesan las evaluaciones llamando a los distintos planificadores que generanun plan de asignacioacuten esto es un conjunto de relaciones entre las tareas y losnodos clientes donde se ejecutaraacuten Este proceso se divide en dos fases primerose descartan aquellos clientes que no cumplan los requisitos y posteriormentese asigna una calificacioacuten al resto Se selecciona el nodo con mayor puntuacioacuteny se encola el plan en el gestor que se ejecuta en el servidor liacuteder Existen tresplanificadores de acuerdo al tipo de trabajo
Service Incluye aquellos trabajos que estaacuten destinados a ejecutarse en un pe-riacuteodo largo de tiempo Para realizar las asignaciones el planificador evaluacuteala mayor parte de los nodos y usa una versioacuten del algoritmo Best fit in-fluenciada por el trabajo de Google en su herramienta Borg Se trata deun algoritmo de planificacioacuten que sacrifica tiempo a cambio de maximizarel rendimiento de los clientes asignando la tarea a la maacutequina que tengala mayor carga de trabajo con el objetivo de reducir equipos en funciona-
25
miento
Batch Tareas que incluyen listas de comandos en general de menor duracioacuteny que no requieren interaccioacuten con el usuario Se vale del algoritmo deSparrow desarrollado por la universidad de Berkeley15 para limitar losnodos clientes a evaluar
System Trabajos destinados a ejecutarse en todos los nodos incluso los que seunen al cluster posteriormente
Core Mantenimiento interno de Nomad
Una vez se ha realizado el proceso de planificacioacuten el nodo liacuteder lo registra enla cola de planes (plan queue) que se encarga de asignarles prioridad y manejarcondiciones de carrera es decir que no accedan a los recursos de los clientes sincontrol y evitar que eacutestos superen su capacidad
La maacutequina liacuteder del conjunto puede de este modo aceptar una asignacioacuteny ser ejecutada por los clientes o por el contrario rechazaacutersela al planificadorlo que implicariacutea realizar un plan parcial o totalmente nuevo
Finalmente el estado de las evaluaciones se actualizan y los clientes soninformados de las asignaciones ejecutaacutendose las tareas
15httppeopleeecsberkeleyedu~keopublicationssosp13-final17pdf
26
6 Casos de uso y despliegue
Con el objetivo de mostrar las posibles utilidades que este tipo de sistemaspueden tener en las infraestructuras TI actuales se han desplegado las dos he-rramientas en la nube Microsoft Azure usando su servicio cloud de instancias demaacutequinas virtuales Linux para simular un conjunto de ordenadores conectadosentre siacute por una red LAN Sobre ellas se ha implementado dos casos de usouna aplicacioacuten web con una arquitectura con cierta orientacioacuten a microserviciosy un sistema de integracioacuten continua
El coacutedigo y todos los ficheros de configuracioacuten se pueden encontrar en elrepositorio del proyecto en GitHub16
61 Aplicacioacuten Web
Se busca simular el proceso de adaptacioacuten de una solucioacuten web para su des-pliegue en un sistema distribuido con las herramientas anteriormente descritascon el objetivo de aumentar tanto su escalabilidad como disponibilidad medianteredundancia
Se ha partido de una aplicacioacuten ya existente17 un servicio de almacenamien-to y reproduccioacuten de canciones A grandes rasgos este servicio permite crearusuarios subir canciones con sus respectivas portadas tener playlists propias yescuchar las canciones a traveacutes de un navegador web
La solucioacuten estaacute dividida en 4 partes (figura 17)
Una vista web con la loacutegica
Un almacenamiento conectado en red (NAS por sus siglas en ingleacutes)
Una API REST para gestionar las peticiones al almacenamiento
Base de datos NoSQL basada en MongoDB
La nueva tendencia de los proyectos web es su implementacioacuten en contene-dores Docker ya que facilitan su portabilidad y ofrecen un procedimiento dedespliegue raacutepido sobre todo a la hora de desarrollar y realizar pruebas en en-tornos de produccioacuten simulados Por ello en este caso se va a hacer uso de los
16httpsgithubcomAntonioAlfrzCloud-Orchestrators17httpsgithubcomsonsoleslpCDPSfy
27
motores de orquestacioacuten de contenedores de ambas herramientas Marathon enDCOS y el controlador Docker en el caso de Nomad
Figura 17 Arquitectura aplicacioacuten web
A continuacioacuten vamos detallar el despliegue en ambas herramientas de es-ta solucioacuten y observar tanto queacute dificultades se encuentran como que ventajasofrecen El objetivo final es adaptar el proyecto modificaacutendolo lo menos posiblecon objeto de analizar la capacidad de estas herramientas para desplegar cual-quier aplicacioacuten sin que eso conlleve la modificacioacuten de la arquitectura de eacutestaes decir que no sea dependiente del entorno
611 DCOS
Se ha descrito DCOS como una herramienta que se despliega sobre un con-junto de ordenadores y que permite instalar gestionar el despliegue de sistemasdistribuidos
Microsoft Azure cuenta con una plantilla para desplegar en su servicio cloudun cluster de maacutequinas virtuales con DCOS ya instalado que cuenta con
Maacutequinas maestras (1 3 o 5 a seleccionar por el usuario) configuradascomo un conjunto de disponibilidad esto eso Azure da ciertas garantiacuteasde que al menos una maacutequina estaraacute en funcionamiento
Maacutequinas agentes Por motivos de seguridad se distinguen dos roles
bull Nodos privados solo accesibles desde la red interna y configuradoscomo un conjunto de escala un recurso de Azure para gestionar ydesplegar maacutequinas con configuraciones ideacutenticas para permitir unraacutepido escalado
bull Un equipo conectado accesible desde Internet a travntildees de un balan-ceador de carga puacuteblico y situado en una subred externa
28
Dos balanceadores de carga
bull La interfaz puacuteblica del cluster que se conecta con el cliente puacuteblicobull Acceso a los equipos maestros para el administrador que soacutelo permiteconexioacuten mediante SSH y credenciales
Almacenamiento para todas las maacutequinas
Configuraciones necesarias de red y seguridad
En la figura 18 se observa un diagrama de la infraestructura
Figura 18 Infraestructura en Azure
El primer obstaacuteculo es la persistencia de estado de la aplicacioacuten que seconsigue gracias a una base de datos no relacional basada en MongoDB asiacutecomo el almacenamiento de las canciones Para implementarla tenemos variasposibilidades
Montar un sistema externo de almacenamiento conectado en red en todoslos agentes donde se ejecuten las tareas de esta manera si una tarea pasade un nodo a otro por cualquier motivo puede tener acceso a los mismosficheros (opcioacuten del caso de uso original)
Implementar un sistema de ficheros distribuidos en los agentes
Usar los servicios de almacenamiento de las nubes puacuteblicas
Aprovechar el sistema de voluacutemenes persistentes de Apache Mesos Eacutestepermite reservar recursos de un agente de forma que al arrancar una tarease crea un volumen independiente del ciclo de vida de eacutesta con ello esosrecursos donde se ha almacenado la informacioacuten pueden volver a ofrecerseal mismo entorno de tal manera que otra tarea pueda acceder a ella
DCOS aprovecha este sistema de voluacutemenes persistentes y permite instalarbases de datos distribuidas como ArangoDB o Apache Cassandra sin embargoesto implicariacutea modificar todo el coacutedigo referente al modelo de la base de datos
29
Por motivos de eficiencia y latencia asiacute como de una mayor gobernabilidadde los datos la mejor opcioacuten es usar el recurso de voluacutemenes persistentes queofrece Apache Mesos ya que de esta manera se gestionariacutea la aplicacioacuten completamediante una uacutenica herramienta Sin embargo esto implica que la informacioacutense encuentra exclusivamente en el agente donde se haya ejecutado la tarea y porlo tanto se sigue requiriendo de software externo para distribuir la informacioacutenpara que se accesible para todos los agentes A la hora de realizar este proyectose encontraba en desarrollo Flocker una solucioacuten desarrollada por ClusterHQque permite compartir los voluacutemenes de Docker a traveacutes de un cluster quesi bien es compatible con el planificador de Mesos el proyecto se encontrabatodaviacutea en fases tempranas de desarrollo y los sistemas de almacenamiento quesoporta quedaban fuera del aacutembito de este trabajo
Por todo ello dado que las maacutequinas se han desplegado en la nube puacuteblicade Azure se decidioacute usar su servicio de almacenamiento de objetos para lascanciones y otra maacutequina para desplegar MongoDB y asiacute mantener el modelode datos original de la aplicacioacuten La diferencia del almacenamiento de obje-tos con respecto a nivel de fichero es que el primero no tiene jerarquiacutea paraorganizar los archivos eacutestos se guardan como objetos (con sus metadatos) enun mismo espacio soacutelo diferenciaacutendose por un identificador uacutenico esto implicaentre otras cosas que se puede acceder a un fichero dado uacutenicamente su IDindependientemente de la localizacioacuten fiacutesica de eacuteste facilitando pues la gestioacuteny el desarrollo
El coacutedigo del proyecto se ha modificado en los siguientes apartados
Las direcciones de la base de datos y los balanceadores de carga asiacute comosus puertos estaban originalmente fijos Se han configurado como variablesde entorno para facilitar el descubrimiento del servicio y hacer transpa-rente la aplicacioacuten al entorno de despliegue
La API REST se ha adaptado al almacenamiento en Azure en vez de enlocal
Estas modificaciones no suponen un cambio sustancial pero permiten separala persistencia de las tareas ejecutadas por DCOS lo que facilita en granmedida su ejecucioacuten al ser totalmente sin estado y ademaacutes implican tenerlos datos bajo un mayor control
Para la orquestacioacuten de contenedores se va a usar el entorno Marathondesarrollado tambieacuten por Mesosphere Eacuteste se puede usar a traveacutes de una interfazgraacutefica la interfaz de liacutenea de comandos (en lo que sigue CLI por sus siglas eningleacutes) de DCOS o con su API HTTP
Primero se han publicado la imaacutegenes de los contenedores que encapsulanla interfaz web y la api de la aplicacioacuten en el repositorio puacuteblico DockerHub
Los despliegues en este entorno se describen mediante ficheros JSON en losque se detalla entre otras opciones la imagen del contenedor los puertos a usar
30
los recursos que debe ocupar en un nodo o las instrucciones de monitorizacioacuten
Para el servicio de descubrimiento DCOS ofrece la posibilidad de asignardirecciones IP virtuales (VIP por sus siglas en ingleacutes) a tareas que se compartenen todos los nodos DCOS lleva integrado un balanceador de carga a nivel TCP(el componente denominado Minuteman) que balancea entre las direccionesvirtuales de las tareas y todas las instancias de eacutestas a lo largo del cluster Estoes necesario por dos motivos equilibrar la carga de los equipos con el fin deevitar un punto de uacutenico fallo mediante redundancia y evitar la contienda dedirecciones al ejecutar las tareas en puertos aleatorios
Este balanceador de carga estaacute basado en el trabajo de Michael Mitzenma-cher The Power of Two Choices in Randomized Load Balancing18 A grandesrasgos el algoritmo mantiene una media moacutevil exponencial de latencias paracada destino (backend) ademaacutes de las caiacutedas consecutivas Si un destino noresponde a una negociacioacuten en tres pasos (three way handshake) de forma con-secutiva en un periodo inferior a 5 ms se considera caiacutedo El algoritmo iterasobre los destinos disponibles en base a su histoacuterico de fallos y escoge dos deforma aleatoria de los cuales coge el de mejor meacutetrica
Las direcciones virtuales soacutelo se pueden resolver dentro del cluster porello para implementar la interfaz puacuteblica de la aplicacioacuten esto es el balancea-dor de carga de la interfaz web usaremos un paquete de DCOS denominadomarathon-lb un balanceador basado en HAProxy y adaptado por MesosphereEn este caso equilibra la carga de todas instancias de las tareas ejecutadas porel entorno Marathon por sus etiquetas y permite ademaacutes definir como puntode entrada muacuteltiples hosts virtuales definidos por sus nombres completos dedominio (FQDN por sus siglas en ingleacutes) en nuestro caso la interfaz puacuteblicadel balanceador de Azure para los agentes
Por motivos de seguridad todas las tareas se ejecutan en los agentes privadoses decir los que son exclusivamente accesibles desde la red interna Por su partemarathon-lb se ejecuta en el agente puacuteblico que cuenta con IP puacuteblica y lospuertos 80 (HTTP) y 8080 abiertos de forma que la aplicacioacuten sea accesibledesde Internet Esto es posible debido a que Apache Mesos permite reservarrecursos mediante roles asignados a nodos para un uso especiacutefico De esta formala arquitectura vista desde la aplicacioacuten quedariacutea como en la figura 19
18httpswwweecsharvardedu~michaelmpostscriptstpds2001pdf
31
Figura 19 Arquitectura de la aplicacioacuten web en DCOS
Ejecucioacuten
A la hora de desplegar la aplicacioacuten DCOS puede gestionarse medianteuna interfaz graacutefica o una interfaz de liacutenea de comandos La primera se accedea traveacutes de un navegador web en el puerto 80 (HTTP) y permite instalar losentornos disponibles observar el estado de los nodos y las tareas que se estaacutenejecutando y los ficheros de registros que eacutestas generan
La CLI permite el control desde un nodo o una maacutequina remota (suponiendoque los maestros tienen IP puacuteblica y el puerto 80 abierto) ya que DCOS tieneun sistema de autorizacioacuten que permite tener una interfaz puacuteblica con ciertasgarantiacuteas de seguridad
Por su parte cada entorno de trabajo puede ser controlado por la CLI peroademaacutes cuenta con sus propias interfaces Marathon expone una API HTTPen el puerto 8080 de la direccioacuten puacuteblica de los maestros del cluster asiacute comootra interfaz graacutefica Para desplegar un contenedor se podriacutea usar la CLI
$ dcos marathon app add lt f i l e j songt
O la API HTTP
$ cu r l minusX POST http lt ip_maestro gt8080v2apps minusd ltf i l e jsongt minusH Contentminustype app l i c a t i o n j son
32
612 Nomad
La arquitectura de Nomad es maacutes sencilla ya que solo requiere de un ficheroejecutable en todos los nodos para funcionar Si DCOS es la base de instala-cioacuten de entornos de terceros Nomad integra todas las funcionalidades baacutesicasesto es gestor de recursos planificador y ejecutor en los nodos cliente Estaherramienta cuenta con un menor tiempo de desarrollo y en el momento deescribir este documento cuenta exclusivamente con los siguientes controladoresen comparacioacuten con los entornos de DCOS
Motor Docker es decir funcioacuten de orquestacioacuten de contenedores
Ejecucioacuten de archivos binarios como comandos de Shell
Ejecucioacuten de aplicaciones Java
Virtualizacioacuten de maacutequinas mediante tecnologiacutea QEMU
Todos ellos necesitan que la tecnologiacutea subyacente esteacute instalada en las maacute-quinas clientes (Docker Java QEMU) Actualmente no permite el registro decontroladores por parte de terceros aunque estaacute planificado en un futuro ofreceruna interfaz para su desarrollo
Nomad no cuenta con el servicio de descubrimiento sin embargo puede inte-grarse con la herramienta Consul desarrollada por la misma empresa Por otrolado para el balanceo de carga usaremos un contenedor Docker con HAProxyuna herramienta de coacutedigo abierto que ofrece tanto servicios de proxy como debalanceador y cuyos ficheros de configuracioacuten completaremos con el proyectoConsul Template19
Consul
Consul sigue la misma arquitectura que Nomad es decir un nodo servidorque orquesta un conjunto de maacutequinas clientes y permite a los procesos que seejecutan en los equipos definirlos como servicios ofreciendo diversas caracteriacutes-ticas entorno a estos de los cuales vamos a usar dos
Descubrimiento de servicio Las maacutequinas clientes publican en el cataacutelogode servicios las tareas en ejecucioacuten y Consul les asigna nombres de dominioaccesibles por todos los miembros del cluster a traveacutes de la interfaz DNSincluida en esta herramientaConsul se integra con Nomad de forma que todas las tareas que se ejecu-ten en la segunda son automaacuteticamente publicados como servicios de laprimera de esta manera no hace falta conocer la direccioacuten de la maacutequinacliente donde se esteacute ejecutando el proceso ya que se puede acceder a eacutela traveacutes de su nombre de dominio de forma transparente Por ejemplo si
19[httpsgithubcomhashicorpconsul-template]
33
ejecutamos una tarea con ID web en el puerto 8080 se puede acceder aella en la direccioacuten webserviceconsul8080Para que las direcciones propias de Consul las resuelva su propio DNS y noel que esteacute asignado por defecto en la maacutequina usaremos la herramientadnsmasq20 que permite especificar la direccioacuten de un servidor DNS paraconsultas de direcciones especiacuteficas
Monitorizacioacuten Permite realizar comprobaciones del servicio y seguir su esta-do Aprovecharemos esta funcionalidad tanto para definir el propio procesode Nomad como servicio de Consul como las tareas desplegadas
HAProxy + Consul Template
HAProxy es una solucioacuten versaacutetil de coacutedigo abierto que ofrece solucionesde balanceo de carga y proxy Existen otras herramientas en el mercado comoNGINX o ldirectord sin embargo HAProxy suponiacutea una solucioacuten sencilla deconfigurar para mostrar el caso de uso
El uso de estas herramientas se debe a dos motivos para que no existacontienda con respecto a los puertos de los clientes usados por las tareas eacutestos sevan a asignar de forma dinaacutemica lo que en principio implicariacutea que la aplicacioacutendeberiacutea realizar consultas DNS de tipo SRV (que incluye puertos) a la interfazde Consul y balancear la carga entre tareas por redundancia y capacidad
Como la direccioacuten IP y puerto son variables cada vez que las tareas seactualicen o se reasignen es necesario volver a configurar HAProxy de formamanual Por ello HashiCorp ha desarrollado un programa denominado Con-sul Template que realiza peticiones sucesivas a la interfaz HTTP de Consul delas direcciones fiacutesicas de un servicio y reinicia automaacuteticamente el proceso deHAProxy Asiacute definiendo estas tareas como servicios Consul podremos tantomonitorizarlas como escalar las tareas dinaacutemicamente sin necesidad de cambiarel balanceador A partir del contenedor Docker oficial de HAProxy se ha desa-rrollado otro con la configuracioacuten baacutesica y con Consul Template para desplegarlocomo una tarea en Nomad
Despliegue
Se ha usado el mismo coacutedigo que en el apartado anterior con la persistenciaen el servicio de almacenamiento de Azure Desde la perspectiva del hardwarese implementaraacute la misma infraestructura que en el caso de DCOS (figura 18)estos es definiremos dos tipos de maacutequinas clientes un agente que se conectaraacutecon el balanceador de carga con nombre de dominio puacuteblico y donde se desple-garaacute el balanceador de carga de la vista web y agentes privados no accesiblesdesde fuera del cluster y donde se ejecutaraacuten el resto de tareas en la red inter-na La principal diferencia radica en las tareas que ejecutan HAproxy y ConsulTemplate que sustituye a las direcciones IP virtuales que ofrece DCOS
20httpwwwthekelleysorgukdnsmasqdochtml
34
Figura 20 Despliegue en Azure de Nomad+Consul
Cabe matizar que los balanceadores basados en HAProxy se implementanpor necesidad de la aplicacioacuten para el descubrimiento del servicio a diferenciade los de Azure que se implementan por motivos de seguridad y escalabilidaddel cluster en siacute
Configuracioacuten Nomad
Los ficheros de configuracioacuten de las maacutequinas maacutester y cliente son similaresy comparten la mayoriacutea de las opciones como por ejemplo el nombre del nodoo la interfaz de red donde escucha Nomad las peticiones Sus opciones son engeneral auto-explicativas sin embargo existen dos detalles que matizar
El proceso de Nomad escucha las peticiones tanto de los protocolos deconsenso como del usuario a traveacutes de una interfaz de red que se debeindicar en el fichero de configuracioacuten
En el caso de los clientes se deben indicar las direcciones de los servidoresdel cluster sin embargo se trata de un sistema dinaacutemico en el que losnodos pueden sufrir errores y cambiar de direccioacuten Por ello se ha definidoNomad como un servicio de Consul y asiacute poder definir la direccioacuten de losservidores como un nombre de dominio no por su direccioacuten fiacutesica que elservidor DNS de Consul se encargaraacute de resolver
Por defecto Nomad usa los siguientes puertos
API HTTP 4646 Peticiones HTTP y recepcioacuten de oacuterdenes mediante laliacutenea de comandos
RPC 4647 Protocolo de consenso entre los nodos del cluster
Serf 4648 Protocolo de gossip entre los servidores de los centros de datosgobernados por Nomad
35
Los dos uacuteltimos deben ser interfaces alcanzables por otros nodos sin embargo laAPI HTTP por motivos de seguridad deberiacutea ser local ya que en caso contrariocualquier persona con acceso a ella tiene el control sobre la herramienta Eacutestasolo deberiacutea estar accesible en un servidor o gestionarlo mediante una terminalSSH por ejemplo En este trabajo al ser una prueba de concepto se ha abiertoen todos los nodos
Trabajos de Nomad
Las tareas se detallan en ficheros con formato HashiCorp Configuration Lan-guage un derivado del formato JSON creado por la empresa que le da nombrecompatible con eacuteste y que permite comentarios
En estos ficheros se puede definir
La regioacuten y el centro de datos donde se ejecutaraacute (Nomad permite lagestioacuten de centros de datos geograacuteficamente distribuidos en regiones)
La poliacutetica de actualizacioacuten de la tarea
Grupo de tareas esto es que se ejecutaraacuten en el mismo nodo
El nuacutemero de grupos a ejecutarescalar asiacute como los liacutemite que debencumplir los nodos asignados
La poliacutetica de reinicio ante fallo o error
Tareas El controlador su configuracioacuten los paraacutemetros del servicio aso-ciado a registrar en Consul asiacute como los recursos que consume (puertosmemoria)
En nuestro caso usamos sobre todo el controlador Docker esto eso orques-tacioacuten de contenedores en los nodos clientes y tres de sus opciones
Imagen del contenedor Se han subido todas las imaacutegenes del proyecto a Doc-ker Hub donde por defecto se busca la imagen
Puertos Los puertos a usar por el contenedor que pueden ser estaacuteticos asigna-dos por el usuario o dinaacutemicos siendo Nomad el que se encarga de mapearun puerto libre del nodo cliente al expuesto por el contenedor
Servidores DNS Como usamos la interfaz DNS de Consul como descubri-miento de servicio se debe configurar el contenedor para que use cualquiernodo del cluster como servidor DNS
Configuracioacuten Consul
Al ser desarrolladas por la misma empresa los ficheros de configuracioacuten deConsul y Nomad comparten muchas opciones Consul tambieacuten acepta peticionesa traveacutes de una interfaz de red siendo los puertos usados por defecto
36
RPC 8300 8400 Maneja la peticiones del resto de nodos y usuarios
Serf 8301 8302 Protocolo gossip
HTTP API 8500
HTTPS API Desactivada por defecto
Interfaz DNS 8600
Se debe asignar a los protocolos internos del cluster esto es RPC y Serf unainterfaz alcanzable por los nodos y por el contrarioasignar a los dos uacuteltimos ala interfaz de loopback por motivos de seguridad
Cabe destacar que Consul tambieacuten cuenta con una interfaz graacutefica que per-mite ver el estado de los equipos y los servicios registrados y que se encuentra enel mismo puerto que la API HTTP en la direccioacuten httpIP_EQUIPO8500ui
Ejecucioacuten
Tanto Nomad como Consul requieren de la ejecucioacuten de un fichero en todoslos nodos integrantes del cluster Como prueba de concepto se ha decidido usardos servidores para ambos aunque cabe matizar que es un nuacutemero ineficienteya que la caiacuteda de uno de ellos supondriacutea la peacuterdida del cuoacuterum y por tantodel consenso del cluster
En primer lugar se arrancan los servidores que son los encargados de ejecu-tar el protocolo de consenso y gestionar el cluster y a continuacioacuten los clientesque no tienen praacutecticamente estado y dependen de los servidores
En el caso de Consul se debe indicar el directorio donde se guardan losficheros que describen los servicios asiacute como el archivo que especifica el resto delas opciones
1 Se inicia el primer servidor en uno de los equipos
$ consu l agent minuscon f i gminusd i r e t c consu l d s e r v i c e s minuscon f i gminus f i l e consu l_server j son
2 Los siguientes equipos deben unirse al anterior por lo que antildeadimos elargumento join con la direccioacuten del primer servidor Para el caso de otrosservidores
$ consu l agent minuscon f i gminusd i r e t c consu l d s e r v i c e s minuscon f i gminus f i l e consu l_server j son minus j o i n ltIP_servidor1gt
37
Una vez los servidores han alcanzado el consenso y elegido un liacuteder en losclientes
$ consu l agent minuscon f i gminusd i r e t c consu l d s e r v i c e s minuscon f i gminus f i l e c on su l_c l i en t j son minus j o i n ltIP_cualquierServ idorgt
El proceso para iniciar Nomad es igual y los comandos similares sin embargoya no es necesario indicar una direccioacuten IP fija en los equipos sino el nombre dedominio del servicio de Nomad registrado por Consul En el primer servidor
$ nomad agent minusc on f i g nomad_server j son
Y el resto de equipos (con su fichero de configuracioacuten correspondiente)$ nomad agent minusc on f i g nomad_server j son minus j o i n nomad s e r v i c e consu l
Por uacuteltimo para desplegar la aplicacioacuten web se han escrito tres ficherosque detallan las tareas de la interfaz web API y los balanceadores de cargaMediante la CLI
$ nomad run minusaddress=http lt ip_c lus te r gt4646 lt f i l e hclgt
O mediante la API HTTP de Nomad$ cu r l minusX POST minusd ltf i l e hclgthttp lt ip_c lus te r gt4646 jobltjob_namegt
Ansible
Como se puede comprobar con el aumento del nuacutemero de equipos pasa aser inviable manejar todos los nodos a traveacutes de terminal Ademaacutes como seha comentado con anterioridad Nomad requiere que en los nodos clientes es-teacuten instalados las herramientas que soporten las tareas por ejemplo el motorde Docker Por ello para facilitar tanto el arranque como la instalacioacuten de lasdependencias vamos a usar Ansible una herramienta de coacutedigo abierto desarro-llada en Python que permite gestionar configuraciones aprovisionar recursosdespliegue de aplicaciones de forma automaacutetica
A grandes rasgos esta herramienta funciona mediante ficheros en formatoYAML denominados play-books que describen un conjunto de pasos a ejecutaren una lista de equipos remotos Estos pasos son ejecutados por moacutedulos inde-pendientes a traveacutes de SSH es decir en cualquier ordenador con conexioacuten a los
38
hosts dado su contrasentildea o clave puacuteblica puede arrancar el script y realizariacutealos pasos de forma remota gestionando el cluster desde un solo equipo
Se han desarrollado guiones para lo siguiente
Descarga de los binarios de Nomad y Consul en todos los nodos copiade los ficheros de configuracioacuten baacutesicos y modificarlos de acuerdo a cadanodo (nombre del equipo direccioacuten IP)
Instalacioacuten de las dependencias
Arranque de Nomad y Consul
Ansible extiende su funcionalidad a traveacutes de moacutedulos independientes que per-miten por ejemplo instalar paquetes mediante herramientas de gestioacuten de pa-quetes (APT yum) aprovisionar automaacuteticamente maacutequinas virtuales de Ama-zon EC2
Algunas opciones de los ficheros de configuracioacuten de Nomad y Consul sondependientes del nodo particular por ejemplo la interfaz de red Para estetrabajo se ha realizado un moacutedulo para modificar los ficheros de configuracioacutende forma automaacutetica En el repositorio del proyecto se encuentra una carpetadonde se encuentran todos los ficheros necesarios para desplegar un clustertotalmente funcional solo requiere de una liacutenea de terminal con Ansible
$ ans ib l eminusplaybook minus i hos t s minusk ltssh_passgt minusu ltnode_usergt s i t e yml
39
62 Servicio de integracioacuten continua
Se ha implementado un sistema de integracioacuten continua que permite ejecu-tar tareas de compilacioacuten y pruebas de forma distribuida aumentando asiacute elrendimiento de los equipos En primer lugar se detallaraacute los motivos por los quepuede resultar beneficioso para las empresas una implementacioacuten de este tipo alo que seguiraacute los detalles del despliegue
621 DevOps
Metodologiacutea que defiende la comunicacioacuten y colaboracioacuten entre desarrolla-dores de software y los profesionales de operaciones a lo largo de todo el ciclo devida de una aplicacioacuten Estaacute muy relacionado con el desarrollo aacutegil de softwareesto es un enfoque para los proyectos que defiende el desarrollo iterativo e in-cremental donde los requisitos y soluciones evolucionan con el tiempo seguacuten lanecesidad del proyecto DevOps extiende esta filosofiacutea a todas los componentesde un servicio incluyendo sistemas y operaciones
Se trata de un concepto que cada organizacioacuten o empresa adapta a suspropias necesidades y procesos de negocio en este proyecto nos vamos a centraren la integracioacuten continua una praacutectica fundamental tanto del desarrollo aacutegilcomo de esta filosofiacutea
622 Integracioacuten Continua
Se define como una praacutectica de desarrollo software donde los miembros delequipo ponen en comuacuten su trabajo frecuentemente al menos una vez al diacutea21Cada integracioacuten se verifica con una compilacioacuten automaacutetica que incluye laejecucioacuten de pruebas para detectar errores de integracioacuten tan pronto como seaposible
Desde el punto de vista operativo esto supone automatizar la configuracioacutende equipos o el despliegue de maacutequinas virtuales donde compilar el proyecto yejecutar las pruebas y posteriormente eliminarlas Este flujo de trabajo se vebeneficiado en entornos distribuidos ya que el objetivo del desarrollador es com-probar el resultado de las pruebas raacutepidamente sin preocuparse del despliegueo los propios equipos
Para esta prueba de concepto vamos a usar Jenkins un servidor de integra-cioacuten continua escrito en Java que nos permite definir trabajos que contendraacutenla descripcioacuten tanto del entorno como su ejecucioacuten
Este sigue una estructura maestro-esclavo muy similar al de los gestores declusters usados en este proyecto el maestro contiene toda la loacutegica del servicio
21httpmartinfowlercomarticlescontinuousIntegrationhtml
40
trabajos autenticacioacuten y los esclavos son los encargados de la ejecucioacuten ensiacute Jenkins tiene varias viacuteas para aprovisionar los uacuteltimos
Mediante SSH
Interfaz graacutefica
Desarrollar un script propio
Ejecucioacuten de un fichero java
La ventaja de usar planificadores es que el despliegue de esclavos es dinaacutemicoes decir no tener una maacutequina especiacuteficamente configurada para ello DCOS yNomad se encargaraacuten de configurar estos despliegues en sus maacutequinas y poste-riormente eliminarlos Para ello se ha usado la uacuteltima opcioacuten definiendo tareasque descarguen el fichero java Con todo ello se consigue un entorno de inte-gracioacuten continua eficiente que ademaacutes permite la ejecucioacuten de otros servicios deforma independiente
Jenkins permite la creacioacuten de plugins que extienden sus funcionalidadesTanto Nomad22 como Apache Mesos cuentan con uno que permite su integra-cioacuten
Para esta prueba se va a usar el mismo proyecto que para el caso de usode orquestacioacuten de contenedores la aplicacioacuten web al que se le ha antildeadido untest para comprobar que se conecta correctamente a la base de datos medianteMocha un framework de Nodejs Por otro lado se antildeade el plugin de git ya queel coacutedigo se obtiene de GitHub el repositorio remoto de control de versiones delproyecto
El proceso general de ejecucioacuten seriacutea como sigue
1 Se ejecuta el maestro de Jenkins como tarea Docker partiendo de la imagenoficial
2 Al arrancar un trabajo se manda una tarea a los planificadores que laasignaraacuten a un nodo cliente Esta tarea consiste en la descarga del ficherode configuracioacuten Java y arrancarlo configurando el equipo como un clientede Jenkins temporalmente
3 Jenkins ejecuta el trabajo en el nuevo cliente en este caso iniciar la apli-cacioacuten web iniciar las pruebas y generar un informe
4 Se elimina el cliente
A continuacioacuten se detallan los matices de cada herramienta a la hora de imple-mentar este servicio
22Desarrollado por Ivo Verberk httpwwwivoverberknl
41
623 Jenkins con Nomad
El plugin permite la ejecucioacuten del fichero Java mediante dos controladorescontenedores Docker y Java En este proyecto nos hemos decantado por el pri-mero ya que nos ahorra instalar la maacutequina virtual de java en todos los nodoscliente Por ello se ha construido un contenedor base con Java para la ejecucioacutendel fichero de configuracioacuten y Nodejs para lanzar la aplicacioacuten web
El plugin se configura con la direccioacuten IP del cluster y el contenedor queejecuta el esclavo Jenkins Por su parte el trabajo en Jenkins se define conel repositorio en GitHub donde se aloja el coacutedigo del proyecto a probar y loscomandos a ejecutar en este caso npm update y npm test
624 Jenkins con DCOS
En el caso de DCOS su sistema de paquetes incluye Jenkins por lo queal instalarlo ya se tiene la configuracioacuten de Mesos totalmente funcional Sinembargo para ejecutar la aplicacioacuten en particular y las pruebas se requiere deNodejs en los equipos esclavos por ello debemos antildeadir un plugin de Jenkinsque permite instalar este entorno antes de ejecutar el trabajo Una vez hechoesto soacutelo queda definir la tarea igual que en el caso anterior
Cabe destacar que Mesosphere tambieacuten ha desarrollado un plugin que per-mite hacer despliegues en Marathon de tal manera que permitiriacutea con cadacommit del coacutedigo compilar la imagen del contenedor Docker y desplegarlaautomaacuteticamente aunque en este proyecto no se ha hecho pruebas de esta fun-cionalidad
42
7 Escalando la infraestructura
Uno de los factores clave que se busca a la hora de implementar sistemasdistribuidos es el poder escalar la infraestructura de forma maacutes sencilla estoes detectar que las maacutequinas estaacuten alcanzando el liacutemite de su capacidad yaumentar eacutesta ya sea mejorando sus caracteriacutesticas teacutecnicas o antildeadiendo maacutesnodos al cluster
El coacutedigo y todos los ficheros de configuracioacuten de esta seccioacuten tambieacuten sepueden encontrar en el repositorio del proyecto en GitHub23
71 Disentildeo
Microsoft Azure permite organizar los servicios cloud de forma loacutegica a traveacutesde grupos de recursos y asiacute poder crear o eliminar eacutestos en conjunto parauna aplicacioacuten determinada (por ejemplo una aplicacioacuten web suele requerir demaacutequinas virtuales bases de datos almacenamiento) Ademaacutes dispone dela opcioacuten de crear plantillas en formato JSON que permite al desarrolladordefinir los recursos y su interrelacioacuten para desplegar de forma automaacutetica unainfraestructura TI en la nube
Azure tambieacuten ofrece la posibilidad de monitorizar el estado de las maacutequinasvirtuales a traveacutes de extensiones lo que permite configurar el escalado automaacute-tico al alcanzar cierto liacutemite definido por el operador Eacutesta es a priori la formaen que deberiacutea implementarse hablando en teacuterminos de eficiencia sin embargoesta aproximacioacuten es totalmente dependiente de la plataforma es decir no sepuede extrapolar a otro proveedor o sobre recursos propios sin realizar un nue-vo disentildeo En este proyecto las tareas que son ejecutadas por estos equipos notienen estado ya que todo lo relativo a la persistencia lo hemos asignado fueradel cluster esto permite escalar la plataforma a traveacutes de otra aproximaciones
Las plantillas aceptan una serie de variables a indicar por el usuario entreotras los conjuntos de escala para definir los nodos aceptan una variable quedefine el nuacutemero de maacutequinas que los componen Por otro lado Azure ofreceuna API REST y kits de desarrollo software (SDK por sus siglas en ingleacutes) quepermiten su despliegue de forma programaacutetica Aprovechando estas facilidadesen este proyecto se va a aproximar la escalabilidad con el sucesivo desplieguede la infraestructura de forma automaacutetica se monitorizan los equipos y si sedetecta una maacutequina excesivamente cargada se aumenta el nuacutemero de equiposen la plantilla y se vuelve a desplegar
23httpsgithubcomAntonioAlfrzCloud-Orchestrators
43
En este proyecto se han disentildeado las plantillas para desplegar la arquitec-tura necesaria tanto de Nomad como de DCOS En el caso de la primera eldespliegue es maacutes descriptivo ya que incluye maacutequinas virtuales grupos de se-guridad redes En el caso de DCOS Azure cuenta con un servicio especiacuteficopara clusters gobernados por DCOS denominado Azure Container Service queincluye los componentes necesarios y la instalacioacuten ya realizada
72 Implementacioacuten
En primer lugar para monitorizar el estado de los equipos se va a usar laherramienta Nagios un sistema que permite controlar el estado del hardwarey los servicios de un equipo Se trata de una herramienta muy completa de laque se va a usar su capacidad para ejecutar comandos (plugins) en los nodospara detectar picos de carga generar alertas y ejecutar programas para estoseventos
Se ha desplegado una maacutequina virtual con esta herramienta en ambos siste-mas y se ha instalado una extensioacuten de Nagios (Nagios Remote Plugin Executor)en todos los nodos que permite ejecutar comprobaciones remotamente en con-creto para esta prueba de concepto medir el nivel de saturacioacuten de la unidadcentral de procesamiento (CPU por sus siglas del ingleacutes) Cuando sucede uncambio de estado de una maacutequina esto es cuando este paraacutemetro supera el liacutemi-te definido por el operador Nagios permite actuar en consecuencia ejecutandoprogramas por ello se ha desarrollado un script que ejecuta lo siguiente
Un programa desarrollado en Python con el SDK de Azure que modificalas plantillas y despliega los recursos
Un guioacuten de Ansible para instalar todos los componentes necesarios en lasnuevas maacutequinas y arrancar de nuevo el cluster y las aplicaciones
44
8 Resultados y conclusiones
En este uacuteltimo apartado se da una visioacuten global del proyecto asiacute como a lasconclusiones maacutes importantes a las que se ha llegado y posibles temas futurosde desarrollo
81 Comparacioacuten
Ambas herramientas ofrecen las funcionalidades para gestionar los recursoseficientemente ofreciendo a los desarrolladores una plataforma donde desplegarsus aplicaciones de forma distribuida independientemente de los equipos fiacutesicosy el hardware que las soporten
DCOS es una herramienta que en un comienzo fue privativa pero cuyos res-ponsables la empresa Mesosphere decidieron publicar una versioacuten de coacutedigoEacutesta nos permite gestionar un cluster de una forma sencilla y usable ademaacutes decomplementarlo con otras herramientas como el balanceador de carga integradoo la autenticacioacuten de usuarios ademaacutes estaacute basada en Apache Mesos un pro-yecto de relativa madurez y con el soporte de la Apache Software FoundationDe forma resumida DCOS ofrece muchas posibilidades y servicios a cambiode una arquitectura e instalacioacuten maacutes compleja
Por su parte HashiCorp con menor tiempo de desarrollo ha conseguidouna herramienta muy sencilla de desplegar que ademaacutes cumple con todas lasfuncionalidades baacutesicas ejecutando un simple binario en cada nodo se puededesplegar un gestor de clusters totalmente funcional Sin embargo no cuentacon todas las posibilidades de Mesos (Nomad cuenta con menos controladoresque entornos posibles de Mesos) ni con los antildeadidos de DCOS lo que implicael uso de otras herramientas para complementar el servicio (Consul HAProxy)
De entre las dificultades encontradas al usar estas herramientas y desplegaraplicaciones sobre ellas se puede destacar la depuracioacuten en ocasiones se desco-noce si un error viene de la propia herramienta de la aplicacioacuten desplegada o delequipo fiacutesico si no se cuenta con un sistema de procesamiento de registro unose puede encontrar con muacuteltiples terminales abiertas inspeccionando numerososficheros de registro buscando posibles errores Ademaacutes no dejan de ser solucio-nes que para usar eficientemente se debe conocer parte de su funcionamientoy sintaxis a la hora de describir la tareas lo que supone un esfuerzo antildeadido yaque cada una tiene sus particularidades y liacutemites
45
82 Conclusiones
En una sociedad cada vez maacutes digital las empresas deben adaptarse a unmercado cuya demanda de contenido no deja de crecer Las nuevas arquitecturascomo microservicios asiacute como la gran cantidad de datos generada implica queuna mejor gestioacuten de los recursos y la rapidez para desplegar o escalar solucionesdando valor al cliente lo maacutes raacutepido posible es uno de los objetivos de todas lasempresas de base tecnoloacutegica
Las ventajas que ofrecen los planificadores con aplicaciones distribuidas sonnumerosas sin ir maacutes lejos empresas tan punteras como Google llevan maacutesde 10 antildeos orquestando contenedores24 Por un lado permiten aumentar elrendimiento de los equipos propios y por otro implementar un servicio comoplataforma para despliegues distribuidos sobre cualquier conjunto hardware deesta forma se provee un servicio similar al de la nube puacuteblica pero con laprincipal diferencia de que se elimina la independencia con el proveedor (vendorlock-in) esto es las aplicaciones no tienen limitaciones impuestas por eacuteste talescomo lenguaje de programacioacuten o herramientas y permite despliegues hiacutebridosentre recursos propios y la nube
83 Objetivos conseguidos
Implementacioacuten de los planificadores propuestos en la nube Se ha en-tendido y detallado el funcionamiento de estas herramientas y se hanimplementado en el servicio de infraestructura de Microsoft Azure
Despliegue de aplicaciones y servicios distribuidos Servicios que se usanactualmente en la industria del desarrollo software asiacute como una aplica-cioacuten web con una arquitectura moderna han sido desplegados de formadistribuida en los equipos cumpliendo con la funcionalidad esperada ade-maacutes de consiguiendo una alta disponibilidad
Aproximacioacuten de arquitectura escalable Se ha hecho una aproximacioacutende infraestructura escalable de forma que sea parcialmente extrapolable aotros proveedores
24httpwwwnextplatformcom20160322decade-container-control-google
46
84 Liacuteneas de investigacioacuten
Siguiendo con la materia de este proyecto se presentan posibles liacuteneas deinvestigacioacuten
Analizar el despliegue con estas herramientas de aplicaciones de Big Datay comparar la eficiencia con respecto a soluciones especializadas
Analizar el rendimiento de los algoritmos de planificacioacuten antes pruebasde estreacutes y situaciones de alta contienda
Comparar el uso de estas herramientas con las praacutecticas actuales de laindustria o implementacioacuten en un sistema de produccioacuten real
47
Referencias
[1] LA Barroso y U Houmllzle laquoThe Datacenter as a Computer An Introduc-tion to the Design of Warehouse-Scale Machinesraquo En Morgan amp ClaypoolPublishers ()
[2] Systems Research Group ndash NetOS (University of Cambridge) The evolu-tion of cluster scheduler architectures 2016 url httpswwwclcamacukresearchsrgnetoscamsasblog2016-03-09-scheduler-architectureshtml
[3] A Das I Gupta y A Motivala SWIM Scalable Weakly-consistent Infection-style Process Group Membership Protocol Inf teacutec Dept of ComputerScience Cornell University url https www cs cornell edu ~asdasresearchdsn02-swimpdf
[4] D Dubhashi y A Das Mastering Mesos PACKT Publishing mayo de2016
[5] The Apache Software Foundation Apache Mesos documentation urlhttpsmesosapacheorg
[6] David Greenberg Building Applications on Mesos OrsquoReilly Media 2016[7] Armand Grillet Comparison of Container Schedulers Inf teacutec Technische
Universitaumlt Berlin[8] HashiCorp Consul documentation url httpswwwconsulio[9] HashiCorp Nomad documentation url httpsdcosio[10] Dan C Marinescu Cloud computing theory and practice Morgan Kauf-
mann 2013[11] Mesosphere DCOS documentation url httpswwwnomadproject
io[12] Microsoft Azure documentation url httpsazuremicrosoftcom
es-esdocumentation[13] D Ongaro y J Ousterhout In Search of an Understandable Consensus
Algorithm Inf teacutec Stanford University url httpsraftgithubioraftpdf
[14] Fei Teng laquoRessource allocation and schelduling models for cloud compu-tingraquo Tesis de mtriacutea Ecole Centrale Paris 2011
[15] A Williams y col Automation and Orchestration with Docker and Contai-ners A Comprehensive Overview of the Docker and Container Ecosystem3 The New Stack 2016
48
- Resumen
- Summary
- Iacutendice de figuras
- Introduccioacuten y objetivos
-
- Contexto
- Objetivos
- Estructura del documento
-
- Cloud Computing
- Nuevas cargas de trabajo
- Gestioacuten de recursos Planificadores
-
- Sistemas distribuidos
-
- Clasificacioacuten
-
- Herramientas
-
- DCOS
-
- Apache Mesos
- Ejemplos de uso
-
- Nomad
-
- Protocolo de consenso Raft
- Protocolo gossip SWIM
- Planificacioacuten
-
- Casos de uso y despliegue
-
- Aplicacioacuten Web
-
- DCOS
- Nomad
-
- Servicio de integracioacuten continua
-
- DevOps
- Integracioacuten Continua
- Jenkins con Nomad
- Jenkins con DCOS
-
- Escalando la infraestructura
-
- Disentildeo
- Implementacioacuten
-
- Resultados y conclusiones
-
- Comparacioacuten
- Conclusiones
- Objetivos conseguidos
- Liacuteneas de investigacioacuten
-
iv
Summary
Tech-savvy companies have a large amount of computational resources tohandle the services that support the business process Typically tasks are al-located in these computers in a static way which is inefficient due to the factthat they are not distributed according to the workload besides involving fur-ther maintenance work Among the responsibilities of Information Technologyprofessionals is efficiently managing these resources and providing some guaran-tees of availability of those services according to the different capacity demands
The motivation of this project comes from the opportunity of efficiently dis-tributing the different tasks or services of an enterprise thanks to the evolutionof technologies such as virtualization distributed storage or software defined net-works but also with the improvement and cost reduction of the communicationlinks a potential turning point in the approach of designing IT infrastructures
This project goes into more detail on tools which pursue resource optim-ization availability scalability and fault tolerance of services Amongst theexisting solutions in the industry two open source projects have been chosenboth achieving the predefined objectives DCOS developed by the companyMesosphere and based on the Apache Mesos project and Nomad developed byHashiCorp
Firstly the internals of these two technologies will be studied followed by adeployment of use cases in both of them in the cloud Lastly the conclusionsreached comparing their performance will be described By this it is intendedto provide a perspective of the functionality of these tools and how they fit inthe nowadays perspective on Information Technology
Keywords Cluster Resource Manager Cluster Scheduler CloudComputing Apache Mesos HashiCorp Nomad Mesosphere DCOS
v
vi
Iacutendice
Resumen III
Summary V
Iacutendice de figuras IX
1 Introduccioacuten y objetivos 1
11 Contexto 1
12 Objetivos 2
13 Estructura del documento 2
2 Cloud Computing 3
3 Nuevas cargas de trabajo 5
4 Gestioacuten de recursos Planificadores 8
41 Sistemas distribuidos 8
411 Clasificacioacuten 10
5 Herramientas 13
51 DCOS 14
511 Apache Mesos 15
512 Ejemplos de uso 18
52 Nomad 19
521 Protocolo de consenso Raft 20
vii
522 Protocolo gossip SWIM 23
523 Planificacioacuten 24
6 Casos de uso y despliegue 27
61 Aplicacioacuten Web 27
611 DCOS 28
612 Nomad 33
62 Servicio de integracioacuten continua 40
621 DevOps 40
622 Integracioacuten Continua 40
623 Jenkins con Nomad 42
624 Jenkins con DCOS 42
7 Escalando la infraestructura 43
71 Disentildeo 43
72 Implementacioacuten 44
8 Resultados y conclusiones 45
81 Comparacioacuten 45
82 Conclusiones 46
83 Objetivos conseguidos 46
84 Liacuteneas de investigacioacuten 47
viii
Iacutendice de figuras
1 Comparacioacuten Centro de datos - Computacioacuten en la nube 4
2 Arquitectura Docker 6
3 Planificador monoliacutetico 11
4 Planificador de dos niveles 11
5 Planificador de estado compartido 12
6 Planificador distribuido 12
7 Arquitectura DCOS 14
8 Servicios DCOS 15
9 Arquitectura de Apache Mesos 17
10 Arquitectura multi-regioacuten en Nomad 20
11 Equipos sin consenso ejecutando el protocolo RAFT 21
12 Un equipo pasa a estado candidato (RAFT) 22
13 Cambio en un registro (RAFT) 22
14 Aprobacioacuten del resto de equipos (RAFT) 23
15 Diagrama de tiempo del protocolo SWIM 24
16 Procedimiento de asignacioacuten en Nomad 25
17 Arquitectura aplicacioacuten web 28
18 Infraestructura en Azure 29
19 Arquitectura de la aplicacioacuten web en DCOS 32
20 Despliegue en Azure de Nomad+Consul 35
ix
1 Introduccioacuten y objetivos
11 Contexto
Las tecnologiacuteas de la informacioacuten y la comunicacioacuten estaacuten suponiendo uncambio draacutestico en la sociedad en 2007 comenzaron a aparecer los teleacutefonosinteligentes tal y como los conocemos y nueves antildeos despueacutes se empieza a con-cebir la idea de dar conectividad a todo dispositivo electroacutenico movimiento queha tomado el nombre de Internet de las cosas Para hacerse una idea de la rapi-dez y magnitud de esta evolucioacuten la consultora Excelacom1 ha estimado que enun minuto se realizan 24 millones de buacutesquedas en Google o se ven 278 millonesde viacutedeos en Youtube En una eacutepoca en la que los recursos tecnoloacutegicos crecenexponencialmente y los usuarios demandan mayor contenido y movilidad nocabe duda que las empresas deben adaptarse lo maacutes raacutepidamente posible a esteproceso de digitalizacioacuten movidas por las nuevas necesidades de las personas
Dado el gran volumen de informacioacuten a lo largo de estos antildeos la compu-tacioacuten y el almacenamiento estaacuten pasando de clientes locales a concentrarse engrandes centros de datos una tendencia que Google ha denominado ldquoWarehouse-scale computingrdquo en 2009[1] Este movimiento hacia la computacioacuten desde ser-vidor no solo viene de la necesidad de mejorar la experiencia de los usuariossino tambieacuten de facilitar la gestioacuten y configuracioacuten de los recursos asiacute como laubicuidad de acceso que permite
En 2006 Amazon lanza Amazon Web Services siendo uno de los pionerosen el mercado de los recursos virtuales ofreciendo capacidad de computacioacutencon un coste proporcional exclusivamente a los recursos utilizados Todo ellocambioacute la perspectiva de los modelos tradicionales de TI a la conocida comocomputacioacuten en la nube recursos informaacuteticos que antes suponiacutean barrerasde entrada en ciertos mercados han pasado a ser condicioacuten necesaria para laconstante evolucioacuten de la tecnologiacutea y la sociedad De hecho Cisco estima quepara el antildeo 2019 maacutes del 86 de las cargas de trabajo seraacuten procesadas porcentros de datos en la nube2
1httpwwwexcelacomcomresourcesblog2016-update-what-happens-in-one-internet-minute2httpwwwciscocomcenussolutionscollateralservice-provider
global-cloud-index-gciCloud_Index_White_Paperpdf
1
12 Objetivos
El propoacutesito de este proyecto es estudiar la viabilidad del uso de planifica-dores de recursos para aumentar la eficiencia de eacutestos y facilitar al desarrolladorel despliegue de aplicaciones de forma distribuida y asiacute ofrecer un servicio ca-racterizado por una alta disponibilidad y escalabilidad
A lo largo de este trabajo se han usado algunas de las herramientas quese estaacuten comenzando a desarrollar para hacer frente a este nuevo enfoque degestioacuten de infraestructuras de las tecnologiacuteas de la informacioacuten (en adelanteinfraestructuras TI) realizando pruebas de concepto sobre cada una de ellas
13 Estructura del documento
A continuacioacuten se detalla las secciones que componen este trabajo La es-tructura queda como sigue
Cloud computing Se entra en detalle en este nuevo modelo de negocio queha originado nuevos enfoques y disentildeos de las infraestructuras TI dentrode las organizaciones
Nuevas cargas de trabajo Se explican algunas tecnologiacuteas representativasque estaacuten suponiendo un desafiacuteo para los profesionales de TI a la horade planificar los recursos y que se ven beneficiadas por entornos de tipocloud
Gestioacuten de recursos Planificadores Estado del arte de las tecnologiacuteas degestioacuten de clusters y planificacioacuten de recursos
Herramientas Descripcioacuten detallada del funcionamiento y arquitectura de lasherramientas usadas a lo largo del proyecto
Casos de uso y despliegue Se describe el proceso de implementacioacuten de unaaplicacioacuten web y un servicio de integracioacuten continua con el software pro-puesto
Escalando la infraestructura Se propone un procedimiento con cierta inde-pendencia del proveedor cloud
Resultados y conclusiones Resume las ideas y hechos a los que se ha llegadoademaacutes de introducir liacuteneas de investigacioacuten futuras
2
2 Cloud Computing
El NIST (National Insitute of Standards and Technology) define este con-cepto como un modelo que permite un acceso ubicuo y bajo demanda de formaremota a un conjunto compartido de recursos de computacioacuten que pueden seraprovisionados y liberados con unos miacutenimos esfuerzos de gestioacuten por parte delproveedor del servicio3
Clasificacioacuten
La computacioacuten en la nube abarca una amplia variedad de servicios y enfo-ques por lo que en primer lugar se va a dar una clasificacioacuten para posterior-mente entrar maacutes en detalle Existen distintos modelos de nube atendiendo a lagobernabilidad de la infraestructura seguacuten el NIST
Nubes puacuteblicas Los servicios y recursos son ofertados de forma puacuteblica yson provistos por una organizacioacuten que los comercializa bajo demanda
Nube privada Los recursos son gestionados por una uacutenica organizacioacutenpara su propio uso
Nube comunitaria En este caso la infraestructura es administrada por unconjunto de organizaciones con objetivos comunes
Nube hiacutebrida Una combinacioacuten de las anteriores
A su vez los distintos servicios que ofrece se pueden clasificar atendiendo algrado de control del usuario
Servicios de software (Software as a Service SaaS) El proveedor se encargade toda la gestioacuten de la infraestructura y oferta aplicaciones a las cuales elcliente puede acceder de forma ubicua a traveacutes de diversos clientes comoun navegador web Por ejemplo Office 365 o Google docs
Servicios de plataforma (Platform as a Service PaaS) Modelo de distribu-cioacuten que ofrece la capacidad de desplegar aplicaciones desarrolladas por elcliente usando las herramientas y lenguajes de programacioacuten soportadaspor el proveedor pero sin la posibilidad de gestionar los recursos consu-midos En este caso el cliente solo tiene control sobre la propia aplicacioacuteny algunas configuraciones del entorno Es el caso de Heroku o Google AppEngine
3httpnvlpubsnistgovnistpubsLegacySPnistspecialpublication800-145pdf
3
Servicios de infraestructura (Infrastructure as a Service IaaS) Se ofertanrecursos de computacioacuten puros como procesamiento o almacenamientomediante una plataforma de virtualizacioacuten El cliente puede controlar elsistema operativo componentes de red y aplicaciones
Figura 1 Comparacioacuten Centro de datos - Computacioacuten en la nubeFuente httpsad-hocnet
De entre las numerosas ventajas que ofrece la computacioacuten en la nube se puededestacar su flexibilidad ya que permite aprovisionar recursos y adaptarlos deacuerdo a la demanda reduce el capital inmovilizado y su amortizacioacuten laubicuidad que permite su consumo desde cualquier parte con conexioacuten a la redy la seguridad y fiabilidad que ofrece el proveedor que normalmente cuenta conrecursos geograacuteficamente distribuidos frente a la gestioacuten y mantenimiento derecursos propios
4
3 Nuevas cargas de trabajo
Las organizaciones que cuentan con sus propios infraestructuras TI han co-menzado a adoptar un enfoque de nube privada para gestionar las tareas ofunciones informaacuteticas sobre las que se sustentan el negocio ya que una es-tructura virtualizada puede ofrecer ventajas con respecto a las adaptaciones decentros de datos tradicionales en los aacutembitos de rendimiento escalabilidad eincluso seguridad4
A su vez se han desarrollado nuevas tecnologiacuteas que suponen cargas detrabajo dinaacutemicas y con gran intensidad de consumo de datos para las empresasque se ven beneficiadas al desplegarlas en recursos virtualizados
Big data
Con la creciente aceptacioacuten de las tecnologiacuteas TIC por parte de la sociedadla cantidad de datos generados en la red es ingente Las profesionales de TI tienecomo objetivo extraer valor de eacutestos para por ejemplo prever las tendencias delmercado Sin embargo este incremento exponencial hace que su procesamientoy almacenamiento requiera de un sistema con gran escalabilidad dado el hechode que una sola maacutequina no puede proveer de la capacidad necesaria
Integracioacuten continua
Modelo informaacutetico que consiste en hacer integraciones automaacuteticas de unproyecto con cualquier cambio en el coacutedigo con el objetivo de detectar fallosde forma temprana Esto implica la compilacioacuten del coacutedigo y su ejecucioacuten enun entorno de pruebas automaacuteticamente un proceso que mediante tecnologiacuteasde virtualizacioacuten permiten simular entornos con eficiencia y rapidez Su imple-mentacioacuten en sistemas distribuidos permite tanto una mejor planificacioacuten comoun mejor rendimiento de los recursos
Arquitectura de microservicios
Enfoque para desarrollar aplicaciones software como un conjunto de serviciosautoacutenomos que se comunican entre siacute a diferencia de aproximaciones monoliacuteti-cas donde la loacutegica del servicio estaacute desarrollada como una unidad Un sistemadistribuido permite el despliegue de los componentes en distintas maacutequinas loque mejora tanto su escalabilidad como la tolerancia a fallos
4httpswwwakamaicomesesresourcespublic-private-cloudjsp
5
Docker
Proyecto de coacutedigo abierto que facilita y automatiza el despliegue de aplica-ciones al encapsular el entorno de trabajo en contenedores Linux una tecnologiacuteaque permite a un sistema fiacutesico ejecutar muacuteltiples instancias de sistemas opera-tivos aislados mediante entornos virtuales con sus propios espacios de procesosy redes pero compartiendo el nuacutecleo (kernel) con el equipo anfitrioacuten
En la figura 2 se compara la pila de una virtualizacioacuten tradicional con res-pecto a los contenedores no se simula el sistema operativo por lo que el procesoes mucho maacutes ligero
Docker se caracteriza por
Autosuficiencia Los contenedores cuentan con las libreriacuteas y configuracio-nes necesarias para ejecutarse de manera autoacutenoma al compartir el nuacutecleo
Portabilidad El hecho de que sean autosuficientes implica que es inde-pendiente del host es decir se puede desplegar en cualquier equipo quesoporte esta tecnologiacutea
Tamantildeo El peso de un contenedor es sustancialmente inferior a otrastecnologiacuteas de virtualizacioacuten
Figura 2 Arquitectura DockerFuente httpsdockercom
6
Los componentes fundamentales de esta herramienta son
Imaacutegenes Describen el entorno de base sobre el que ejecutar el contene-dor por ejemplo la imagen del sistema operativo Ubuntu Sobre eacutesta seconstruyen las aplicaciones particulares del usuario dando lugar a otraimagen
Contenedores Se crean a partir de las imaacutegenes y comprenden todo aquellonecesario para arrancar la aplicacioacuten decir su entorno de ejecucioacuten
bull Voluacutemenes Encargados de gestionar la persistencia de datos e inde-pendientes del ciclo de vida del contenedor
Registros Pueden ser puacuteblicos o privados y almacenan las imaacutegenes elregistro puacuteblico oficial de Docker es Docker Hub
Dadas estas caracteriacutesticas los profesionales TI estaacuten comenzando a adoptarDocker ya que facilita tanto los despliegues como el trabajo compartido en dis-tintos entornos Sin embargo esto requiere de un software que permita desplegarlos distintos contenedores de forma que puedan trabajar en conjunto procesoque se ha denominado orquestacioacuten de contenedores
7
4 Gestioacuten de recursos Planificadores
Para sacar el maacuteximo provecho a las tecnologiacuteas anteriormente descritaslo ideal es desplegarlas en sistemas distribuidos sin embargo esto aumenta lacomplejidad del propio despliegue asiacute como la necesidad de software especiali-zado para ello Se necesitan algoritmos de planificacioacuten que permitan obtener elmaacuteximo rendimiento de los recursos por un lado y dar ciertas garantiacuteas de quetodas las tareas y procesos se van a ejecuta por otro
41 Sistemas distribuidos
En primer lugar se definen los sistemas distribuidos o clusters como unconjunto de ordenadores conectados entre siacute cuyo objetivo es trabajar como unauacutenica instancia de gran capacidad5
Su clasificacioacuten variacutea de acuerdo a cada autor pero en general se puedendividir seguacuten su objetivo en alto rendimiento aquellos cuyo objetivos es proveerde gran capacidad de coacutemputo gracias al conjunto de los nodos y alta disponi-bilidad con los cuales se busca la fiabilidad del sistema mediante redundanciayo balanceo de carga
El intereacutes de este proyecto recae en los uacuteltimos ya que el objetivo es porun lado ofrecer al desarrollador un entorno donde desplegar sus aplicaciones deforma distribuida y por otro maximizar el rendimiento de los recursos
De forma general las caracteriacutesticas que se buscan son las siguientes
Elasticidad Adaptacioacuten a cargas dinaacutemicas de trabajo aumentando (o dis-minuyendo) recursos de manera automaacutetica de tal forma que la utilizacioacutensea lo maacutes cercana a la demanda
Disponibilidad Capacidad de un sistema para mantener el servicio fun-cional
Tolerancia a fallos Recuperacioacuten del servicio ante el fallo de un compo-nente
Balanceo de carga Compartir las tareas entre las diferentes maacutequinasredundadas evitando asiacute puntos de uacutenico fallo
5httpsenwikipediaorgwikiComputer_cluster
8
Los programas que se implementan en entornos distribuidos se caracterizanpor ejecutarse de forma concurrente en equipos independientes estar conectadospor una red que introduce fallos aleatorios y no compartir memoria ni reloj Estoimplica entre otras cosas que
Los nodos soacutelo tienen un acceso raacutepido a su memoria local por lo quecualquier informacioacuten relativa al estado global puede ser potencialmenteerroacutenea
Las maacutequinas pueden sufrir caiacutedas de forma aleatoria
El intercambio de informacioacuten puede fallar ya sea por error en transmisioacuteno por caiacuteda de los nodos
Estas dificultades se ponen de manifiesto en el teorema de CAP en cienciasde la computacioacuten el teorema de CAP que lanzado inicialmente como conjetu-ra en el antildeo 2000 por Eric Brewer (motivo por el cual al teorema se le conoceformalmente como teorema de Brewer) y posteriormente demostrado en el antildeo20026 establece que es imposible para un sistema de coacutemputo distribuido ga-rantizar simultaacuteneamente dos de las tres propiedades siguientes
Consistencia (Consistency) es decir que todos los nodos vean la mismainformacioacuten al mismo tiempo Se busca que un cambio en el sistema soacutelose ejecute satisfactoriamente si y soacutelo si se efectuacutea a todos las maacutequinasde tal forma que los datos entre ellos nunca difieren y la respuesta a unapeticioacuten sea la misma independientemente del nodo que la atienda
Disponibilidad (Availability) esto es la garantiacutea de que toda peticioacuten debeobtener una respuesta (servicio funcional) aunque exista inconsistenciaentre nodos
Tolerancia al particionado (Partition Tolerance) es decir que el sistemasiga funcionado a pesar de un fallo en la comunicacioacuten entre los equipos
Por todo lo expresado anteriormente conseguir un sistema distribuido capazde ofrecer procesamiento de forma transparente implica una arquitectura TIcompleja Se requieren de subsistemas y herramientas que permitan la cohesioacutenentre todos los nodos
Gestor de los recursos de las diferentes maacutequinas
Monitorizacioacuten tanto de los servicios activos como de la funcionalidad delsistema ademaacutes de poliacuteticas para recuperacioacuten de fallo
Protocolos de consenso que permitan a los nodos ser consistentes con elestado global del cluster
6urlhttpsgroupscsailmitedutdspapersGilbertBrewer2pdf
9
Herramientas de descubrimiento de servicios que permita la comunicacioacutenentre tareas distribuidas
Planificadores Encargados de distribuir las tareas y procesos en las dife-rentes maacutequinas asignaacutendole parte de su capacidad
Los planificadores del ingleacutes cluster schedulers son un componente funda-mental por lo que vamos a entrar un poco maacutes en detalle en ellos
Planificadores (Cluster Schedulers)
Es el software encargado de monitorizar los recursos usados por cada maacute-quina perteneciente a un cluster y distribuir la carga de trabajo entre ellas deacuerdo a un poliacutetica o reglas
Este tipo de herramientas comparten cierta terminologiacutea que es relevantedefinir
Tarea Unidad de trabajo computacional comprendida por una secuenciade instrucciones datos de entrada y recursos asociados Por ejemplo laejecucioacuten de un comando o el arranque de una base de datos
Nodo Cualquier maacutequina integrante de un cluster En una arquitecturamaestro-esclavo se definen dos roles
bull Cliente Agente Esclavo Aquellos ordenadores que se encargan deejecutar las tareas
bull Maestro Servidor Su objetivo es mantener el estado del cluster ygestionar sus recursos
411 Clasificacioacuten
A lo largo de los uacuteltimos antildeos se han desarrollado diferentes tipos de plani-ficadores[2]
Monoliacutetico
Un solo planificador que se encarga de distribuir todas las tareas entran-tes La mayoriacutea de los planificadores en computacioacuten de alto rendimiento asiacutecomo Borg desarrollado por Google son de este tipo En la figura 3 se pue-de observar de forma graacutefica el procedimiento siendo las cajas grises maacutequinaspertenecientes al cluster y los ciacuterculos las tareas a asignar
10
Figura 3 Planificador monoliacuteticoFuente httpswwwclcamacuk
Planificacioacuten de dos niveles
La mayoriacutea de los clusters ejecutan aplicaciones con distintas necesidadesdesde procesos casi instantaacuteneos hasta servicios persistenteslo que implica dis-tintas necesidades de recursos
Por ello la planificacioacuten a dos niveles distingue dos funciones la gestioacutende recursos (gestor) y la disposicioacuten de las tareas (planificador) Cada serviciotiene su propio planificador de tal manera que el gestor les ldquoofertardquo recursosde acuerdo a una poliacutetica y los planificadores se encargan de escoger la maacutesadecuada Esto permite que el proceso de distribucioacuten sea maacutes acorde con lasnecesidades de los diferentes servicios Apache Mesos que detallaremos maacutesadelante sigue este esquema
Como desventaja cabriacutea sentildealar que esta programacioacuten implica que los pla-nificadores pierden la vista general de la infraestructura y las tareas soacutelo puedenejecutarse con los recursos que les son ofrecidos lo que dificulta la implementa-cioacuten de prioridades de ejecucioacuten de tareas entre otras
Figura 4 Planificador de dos niveles
11
Planificacioacuten de estado compartido
Muacuteltiples reacuteplicas del estado del cluster se actualizan independientementepara cada planificador como se observa en la figura 5 cuando sucede un cambiode forma local el planificador se encarga de informar al resto
Ejemplo de este tipo son Omega la evolucioacuten de Borg por parte de GoogleMicrosoft Apollo y Nomad que usaremos para los casos de uso
De entre las desventajas se puede destacar el hecho de que en general losnodos trabajan con informacioacuten desactualizada lo que conlleva una degradacioacutendel rendimiento en situaciones de alta contienda
Figura 5 Planificador de estado compartido
Planificacioacuten distribuida
En este caso no existe coordinacioacuten entre los distintos planificadores Cadauno de ellos funciona con su propia vista del cluster Las tareas pueden serorganizadas por cualquiera de ellos y desplegadas en cualquier parte del clusteren base a la aleatoriedad y multiplexacioacuten estadiacutestica de los flujos de trabajosin ninguacuten control central
Figura 6 Planificador distribuido
12
5 Herramientas
En la industria comienzan a aparecer soluciones software de coacutedigo abiertoque aglutinan los servicios necesarios para gestionar la infraestructura TI de ma-nera maacutes eficaz El objetivo es doble se busca facilitar la gestioacuten de los recursosde computacioacuten para organizaciones con instalaciones propias mediante su usocon un enfoque cloud esto es desplegar aplicaciones a traveacutes de un conjuntode ordenadores de forma transparente y sin tener en cuenta la infraestructurasubyacente o aprovechar el maacuteximo rendimiento de la infraestructura de losproveedores cloud puacuteblicos de forma que se tiene el maacuteximo control sobre eacutestapero no se depende de las soluciones propietarias permitiendo asiacute despliegueshiacutebridos
Entre estas herramientas se pueden destacar
OpenStack Proyecto desarrollado por la fundacioacuten del mismo nombre paraproporcionar servicios de infraestructuras (IaaS) basado en componentesque se comunican a traveacutes de APIs El componente Magnum incluye mo-tores de orquestacioacuten de contenedores
Kubernetes Sistema de orquestacioacuten de contenedores Docker creado por Goo-gle
CoreOs Sistema operativo basado en Linux disentildeado para despliegues distri-buidos sobre contenedores incluyendo mecanismos de descubrimiento deservicio y comparticioacuten de configuracioacuten
Docker Swarm Herramienta nativa de orquestacioacuten de contenedores Docker
YARN Entorno de gestioacuten de recursos y aplicaciones distribuidas de Hadoopuna libreriacutea software de procesamiento de grandes conjuntos de datos
Como podemos observar existe un gran rango de opciones para gestionar lainfraestructura desde un bajo nivel como puede ser OpenStack hasta Kuberne-tes o Docker Swarm que ofrecen exclusivamente orquestacioacuten de contenedores
En este trabajo se ha optado por Mesosphere DCOS y HashiCorp Nomadque se encuentran en el teacutermino medio su objetivo es proporcionar serviciosde plataforma que permitan la coexistencia dediferentes cargas de trabajo en elcluster
13
51 DCOS
DCOS es un proyecto de coacutedigo abierto7 creado y desarrollado por la empre-sa Mesosphere Se describe como un sistema operativo distribuido que abstraelos recursos de un cluster (capacidad de procesamiento memoria) permite lagestioacuten de muacuteltiples ordenadores de forma transparente y simplifica la instala-cioacuten de aplicaciones distribuidas
Su arquitectura se puede comparar a la de Linux en teacuterminos de nuacutecleo(kernel) y espacio de usuario El primero consta de recursos protegidos a losque no puede acceder el usuario e involucra operaciones de bajo nivel comoasignacioacuten de recursos o aislamiento de procesos En el espacio de usuario seejecutan las aplicaciones y servicios de maacutes alto nivel
Siguiendo con este siacutemil el nuacutecleo de DCOS estaacute basado en Apache Mesosque se explicaraacute en un apartado posterior y el espacio de usuario que estaacute com-prendido por los componentes del sistema esto es las diferentes herramientasque en conjunto conforman DCOS y los servicios encargados de planificar yejecutar las aplicaciones y tareas del usuario
Figura 7 Arquitectura DCOSFuente httpsdcosio
De entre los componentes que conforman DCOS destacan
Admin Router Balanceador de carga central basado en NGINX que dis-pone un proxy entre todos los servicios en el puerto 80 permitiendo sugestioacuten mediante la interfaz graacutefica Ademaacutes se encarga de la autenticacioacutenpara acceder al panel de administracioacuten
Cosmos Gestor de paquetes de las aplicaciones
Diagnostics Se ejecuta en todos los nodos y se encarga de monitorizar elestado de los daemons que sustentan DCOS
7Desde abril de 2016 httpsmesospherecomblog20160419open-source-dcos
14
Exhibitor Gestiona y automatiza el despliegue de ZooKeper la herra-mienta que provee de configuracioacuten centralizada y registro de nombres
Marathon Equivale al proceso init de los sistemas tipo Unix esto es elprimer proceso en ejecucioacuten tras la carga del kernel y que genera los demaacutesprocesos Se encarga de arrancar y monitorizar las aplicaciones y servicios
Mesos-DNS Servicio de DNS interno que define el dominio mesos pa-ra nodos y tareas en el cluster es decir permite resolver nombres conindependencia de la direccioacuten fiacutesica
Minuteman Balanceador de carga integrado a nivel TCPUDP disponiblepara las propias aplicaciones
Por otra parte se definen como servicios a las diferentes aplicaciones dis-tribuidas que DCOS permite instalar en el cluster y que pueden haber sidodesarrollados por la misma empresa Mesosphere o por terceros por ejemploApache Spark Jenkins o Apache Hadoop En la figura 8 se muestra un diagramade los servicios disponibles incluyendo algunos de las aplicaciones distribuidasque soporta DCOS
Figura 8 Servicios DCOSFuente httpsdcosio
511 Apache Mesos
El nuacutecleo de DCOS estaacute basado en Apache Mesos un proyecto de coacutedigoabierto creado por la Universidad de California Berkeley y desarrollado actual-mente por la fundacioacuten Apache Se trata de un administrador de clusters queabstrae los recursos y los dispone para diferentes aplicaciones y entornos de tra-bajo distribuidos (frameworks) mediante una interfaz comuacuten En el momento deredaccioacuten de este proyecto Apache Mesos soportaba una variedad de entornosque abarcaba desde Big Data (Apache Spark Hadoop) hasta bases de datos(Cassandra Hypertable)
15
Arquitectura
Mesos se basa en la asignacioacuten de dos roles diferentes a los nodos
Maestros (Masters) Se encargan de la gestioacuten y reparticioacuten de los recursospara los diferentes entornos de trabajo mediante ldquoofertas de recursosrdquo deacuerdo a los disponibles y a la poliacutetica de asignacioacuten (planificacioacuten en dosniveles)
Esclavos (Slaves) Ordenadores donde se ejecutaraacuten las aplicaciones y cu-yos recursos son ofertados por los maestros
En el caso de fallo del maestro las tareas pueden seguir ejecutaacutendose perono se podraacute asignar nuevos recursos ni tareas por ello pueden existir varios enel cluster para configuraciones de alta disponibilidad pero soacutelo uno orquesta alos esclavos
Para la eleccioacuten del master liacuteder Mesos usa Apache ZooKeeper un proyectode software desarrollado por la misma fundacioacuten cuyo objetivo es proveer deun servicio de configuracioacuten centralizado y registro de nombres8
Por otra parte los entornos de trabajo son los programas que deciden final-mente queacute recursos se van a usar y se encargan de que los esclavos ejecuten lastareas Eacutestos se ejecutan sobre Mesos y constan de dos componentes
Planificador (Scheduler) Optimiza y decide los recursos a utilizar de losofertados informando a los Masters
Procesador (Executor) Ejecuta las aplicaciones o servicios en los esclavos
El objetivo final es conseguir una interfaz liviana tolerante a fallos paracualquier tipo de entorno de trabajo de tal manera que en los esclavos del clusterpuedan ejecutarse simultaacuteneamente tareas con necesidades y duracioacuten diferentesPara ello se basa en dos conceptos asignacioacuten y aislamiento de recursos
Asignacioacuten de recursos
En el cluster pueden coexistir entornos de trabajo con tareas de larga dura-cioacuten y con gran consumo de recursos con tareas cortas que los ocupan y liberancon rapidez El maestro integra un moacutedulo de asignacioacuten de recursos (allocationmodule) que se encarga del algoritmo de distribucioacuten
En el momento de escribir este proyecto estaban desarrollados dos moacutedulosuno mediante el cual el usuario puede asignar prioridades y otro que implementa
8httpszookeeperapacheorg
16
el algoritmo Dominant Resource Fairness9 a grandes rasgos se determina entodos los esclavos la tarea en ejecucioacuten que necesita maacutes recursos y se calcula laproporcioacuten del recurso de mayor peso con respecto al total por ejemplo si unatarea ocupa 2 GB de memoria con respecto a 10 GB totales que tiene el clusterse le asigna un dominant share del 20 la tarea se asignaraacute al nodo con menordominant share
Aislamiento de recursos
Para conseguir que tareas de diferentes entornos de trabajo y con distin-ta naturaleza se ejecuten simultaacuteneamente en un mismo nodo Mesos usa loscontenedores Linux (descritos en la seccioacuten 3)
Funcionamiento
La figura 9 muestra el esquema de la arquitectura de Apache Mesos conalta disponibilidad (tres maestros) y con dos entornos de trabajo ejecutaacutendo-se Hadoop que permite el almacenamiento y procesamiento de gran cantidadde datos para proyectos de big data y un sistema que implementa la interfazsistema de paso de mensajes MPI
Como se puede observar el sistema ZooKeeper elige a un solo maestro comoliacuteder y eacuteste orquesta el cluster comunicando los esclavos con los planificadoresde los diferentes entornos de trabajo Tambieacuten se puede observar como las tareasde los distintos entornos estaacuten distribuidas entre los tres esclavos disponibles
Figura 9 Arquitectura de Apache MesosFuente httpsmesosapacheorg
El proceso de asignacioacuten se realiza como sigue en primer lugar un usuariosolicita la ejecucioacuten de una tarea mediante la interfaz de cada entorno de traba-jo (interfaz graacutefica API HTTP ) De forma paralela un esclavo informa almaestro de los recursos que tiene libres En consecuencia eacuteste se lo notifica almoacutedulo de asignacioacuten que en funcioacuten de su configuracioacuten decide cuaacutento ofertar
9httpspeopleeecsberkeleyedu~aligpapersdrfpdf
17
y a queacute entorno de trabajo y enviacutea la oferta a los planificadores Eacutestos respondenal maestro con queacute recursos ha decidido usar para cada tarea Finalmente lastareas son enviadas al esclavo seleccionado el cual asigna los recursos indicadosal procesador (executor) quien finalmente las ejecuta
Cabriacutea pensar que esta metodologiacutea puede conducir a situaciones en lasque un entorno podriacutea quedarse con tareas sin ejecutarse a la espera de unaoferta satisfactoria para ello Mesos implementa un sistema de filtros medianteel cual los entornos especifican los requisitos miacutenimos que debe cumplir unaoferta por ejemplo se puede especificar en queacute nodos debe desplegarse la tareaEste sistema estaacute disentildeado asiacute con el objetivo de mantener lo maacutes transparenteposible esta herramientas de forma que acepte entornos de trabajo de distintasnaturalezas
512 Ejemplos de uso
Grandes empresas estaacuten usando Apache Mesos con eficacia de acuerdo a susnecesidades e infraestructuras Caben destacar
Ebay En el modelo de implementacioacuten continua en esta empresa10 cadadesarrollador cuenta con su propia instancia que se ejecuta en una maacutequinavirtual dedicada lo que ha conllevado un uso de los recursos poco eficiente Enuna prueba de concepto consiguieron realizar una herramienta de integracioacutencontinua distribuida basada en un cluster con Apache mesos y con el entornoMarathon y Jenkins
Apple Anuncioacute que el motor de su famosa herramienta de asistencia per-sonal para iPhones Siri estaacute desplegada sobre Apache Mesos11 Para ello handesarrollado su propio entorno para facilitar a los ingenieros a desplegar los ser-vicios que la herramienta necesita para resolver las peticiones de los usuarios
Twitter Desarrolloacute su propio entorno denominado Aurora y actualmentegestionan sus recursos y miden el coste de las tareas que los empleados usancon el objetivo de que sean conscientes del gasto que puede suponer un usoinadecuado de la infraestructura12
10httpwwwebaytechblogcom20140404delivering-ebays-ci-solution-with-apache-mesos-part-i11httpwwwbusinessinsidercomapple-siri-uses-apache-mesos-2015-812httpswwwlinuxcomNEWS4-UNIQUE-WAYS-UBER-TWITTER-PAYPAL-AND-HUBSPOT-USE-APACHE-MESOS
18
52 Nomad
Herramienta de coacutedigo abierto de gestioacuten de clusters creada y desarrolladapor Hashicorp13 que permite el despliegue de aplicaciones y procesos de formadistribuida
Las principales diferencias con Apache Mesos a grandes rasgos son
Arquitectura maacutes ligera Nomad soacutelo requiere de un fichero para funcionarejecutaacutendolo con las correspondientes configuraciones en todos los nodosrealiza las funciones de gestioacuten del cluster eleccioacuten de liacuteder planificacioacutende recursos y ejecucioacuten de las tareas
Centro de datos y regiones muacuteltiples Su arquitectura estaacute orientada afacilitar la gestioacuten de diferentes centros de datos geograacuteficamente distri-buidos
Entorno de ejecucioacuten Las tareas se definen y son interpretadas mediantecontroladores integrados en Nomad que se valen de los recursos y herra-mientas de los nodos clientes para ejecutarlas Esta integracioacuten dificultael desarrollo de controladores por parte de terceros a diferencia de Mesosque delega dicha responsabilidad en los entornos de trabajo externos alproyecto
Usa un planificador de estado compartido con respecto a la planificacioacutenen dos niveles de Mesos
Antes de entrar en maacutes detalle en la arquitectura es importante definir lossiguientes teacuterminos
Controlador (Driver) Software que se encarga de interpretar las definicionesde las tareas y ejecutarlas semejante a los procesadores de los entornosde trabajo de Mesos A la hora de redactar este proyecto Nomad contabacon controladores para contenedores Docker virtualizacioacuten de maacutequinasmediante el emulador QEMU aplicaciones java y archivos binarios
Grupo de trabajo (Task Group) Conjunto de tareas que se ejecutan en elmismo nodo cliente
Trabajo (Job) Conjunto loacutegico de tareas y grupos de trabajo que se despliegana la vez
Asignacioacuten (Allocation) Relacioacuten entre un grupo de trabajo y el cliente don-de se ejecuta
Evaluacioacuten (Evaluation) Proceso mediante el cual Nomad planifica y ges-tiona el registro o actualizaciones de los trabajos
13httpswwwhashicorpcom
19
Nomad sigue una arquitectura maestro-esclavo similar a la de Apache Mesosmuacuteltiples servidores acuerdan entre siacute un liacuteder que gestiona la planificacioacuten detareas en los clientes que soacutelo conocen sus asignaciones y las ejecutan
Todos los servidores participan paralelamente en tareas de planificacioacuten derecursos y asignacioacuten de tareas y ademaacutes entre ellos eligen un liacuteder que seencarga de la coordinacioacuten de la suscripcioacuten de los clientes al cluster y de lagestioacuten de las peticiones
Los clientes estaacuten configurados para comunicarse con el servidor usando lla-madas a procedimiento remoto (RPC por sus siglas en ingleacutes) que permite unordenador ejecutar coacutedigo en otra maacutequina Mediante esta tecnologiacutea los nodosclientes avisan de su estado e informa de sus asignaciones recursos y controla-dores disponibles
Existe la posibilidad de gestionar varios centros de datos agrupados en regio-nes eacutestas son independientes pero permite definir tareas o comprobar el estadode todas ellas desde cualquier punto A continuacioacuten se muestra una figura dela arquitectura a alto nivel de esta configuracioacuten
Figura 10 Arquitectura multi-regioacuten en NomadFuente httpswwwnomadprojectio
La herramienta se sustenta sobre tres protocolos fundamentales un protocolode consenso entre los servidores para compartir informacioacuten sobre su estado yel liacuteder un protocolo Gossip para la gestioacuten entre regiones y el planificador detareas
521 Protocolo de consenso Raft
El objetivo es obtener consistencia en un conjunto de nodos que comparteninformacioacuten es decir si un cliente realiza un cambio que todos los nodos veanla misma informacioacuten a la vez y ademaacutes sea tolerante a fallos Para ello se basaen el algoritmo Raft[13] que se detalla brevemente a continuacioacuten
20
Los nodos participantes en el algoritmo pueden estar en tres estados
Liacuteder (Leader) Todos los cambios que realicen en el cluster pasan por eacutel pri-mero
Seguidor (Follower) Nodo pasivo cuya responsabilidad es responder a laspeticiones del nodo liacuteder
Candidato (Candidate) Maacutequina que no ha encontrado liacuteder y solicita sueleccioacuten
Supongamos que tenemos cinco equipos que acaban de arrancar el protocoloEn la figura 11 se observan los nodos y sus respectivos registros a la derecha
Figura 11 Equipos sin consenso ejecutando el protocolo RAFTFuente httpsgithubcomongardieraftscope
Al comenzar todos los nodos son seguidores esperando recibir comunicacioacutende un nodo que actuacutee como liacuteder Cada nodo tiene un tiempo de espera aleatoriodespueacutes del cual si no es informado por un liacuteder pasa a estado candidato y pideel ldquovotordquo al resto de los participantes El algoritmo divide el tiempo en plazos uncandidato pasa a liacuteder si recibe la mayoriacutea de los votos en un plazo determinadoSe define mayoriacutea o cuoacuterum (quorum) comolceil
N2rceil
+ 1 (1)
donde N representa el nuacutemero de nodos
Para el ejemplo propuesto de 5 equipos se requieren de 3 votos Soacutelo losnodos que se encuentren en estado seguidor pueden votar una uacutenica vez a laprimera solicitud que reciba dentro de un plazo
Supoacutengase que el nodo denotado con S1 ha cumplido su tiempo de espera yrealiza la peticioacuten de voto (figura 12) A partir de este momento se pueden dartres casos
La maacutequina gana la eleccioacuten y pasa a ser liacuteder informando al resto
Otro servidor se establece como liacuteder en el mismo momento
Varios nodos pasan a ser candidatos por lo que ninguno consigue los votos
21
Figura 12 Un equipo pasa a estado candidato (RAFT)
Si un candidato recibe un aviso de un liacuteder en el mismo plazo el primeropasa a ser seguidor y se acaba la eleccioacuten de liacuteder
Por otro lado si un equipo candidato no recibe los votos en el plazo y agotasu tiempo de espera avanza al siguiente plazo y repite el proceso de votacioacutenLa tercera posibilidad puede conllevar a un estado indefinido ya que varioscandidatos pueden agotar su tiempo de espera al mismo tiempo y repartir losvotos Para solventarlo el algoritmo establece tiempos de espera aleatorios paralos candidatos
Siguiendo con el ejemplo propuesto el servidor S1 pasa a ser el liacuteder Cadacierto tiempo eacuteste debe realizar avisos a los nodos seguidores para no agotar sutiempo de espera
En este momento el cluster de servidores estaacute en ldquoconsensordquo y la informacioacutenen todos los nodos estaacute actualizada Un cambio en la informacioacuten inicia unproceso de replicacioacuten el liacuteder registra el cambio lo pasa al resto de nodos yuna vez eacutestos responden el cambio se hace efectivo
Supoacutengase que se realiza un cambio en los datos en la figura 13 en la partederecha se observa el cambio en el registro del servidor S1 que informa a losnodos seguidores En consecuencia los nodos registran el cambio y responden aS1
Figura 13 Cambio en un registro (RAFT)
Una vez el cuoacuterum (en el ejemplo tres equipos) informa al liacuteder de que
22
ha registrado el cambio el liacuteder lo hace efectivo en su sistema y notifica a losnodos que hacen lo mismo En la figura 14 el enviacuteo todaviacutea no ha llegado ala maacutequina S3 y se observa que no ha hecho efectivo el cambio (en el registroaparece punteado)
Figura 14 Aprobacioacuten del resto de equipos (RAFT)
Este protocolo funcionaraacute correctamente mientras exista un nuacutemero de nodosen funcionamiento igual o superior al cuoacuterum en el ejemplo propuesto elcuoacuterum es tres por lo que el sistema puede tolerar la caiacuteda de dos de los equipos
522 Protocolo gossip SWIM
Nomad permite la gestioacuten simultaacutenea de varios centros de datos reparti-dos en regiones geograacuteficamente separadas requiriendo de un protocolo ligeroque mantenga a los miembros actualizados sobre los participantes del conjun-to Para ello usa una ligera variante del protocolo SWIM[3] (Scalable Weakly-consistent Infection-style Process Group Membership Protocol) desarrollada porHashiCorp Estaacute clasificado como un protocolo de tipo gossip que debe su nom-bre a la semejanza con coacutemo se distribuye un rumor en una red social
SWIM se sustenta en dos caracteriacutesticas fundamentales la deteccioacuten de fallosy la distribucioacuten de la informacioacuten relativa a los miembros A continuacioacuten sedetalla el funcionamiento de ambos componentes
Deteccioacuten de fallos
Este componente tiene dos paraacutemetros el periodo de protocolo T y el nuacutemerode subgrupos de deteccioacuten de fallos k en los que se dividen los nodos Paracomprobar la comunicacioacuten entre dos maacutequinas usa la utilidad ping basadaen el protocolo ICMP La deteccioacuten de caiacuteda de un servidor sigue el siguientealgoritmo
Durante el periodo T cada miembro Mi de un subgrupo elige otro al azar Mjdel mismo subgrupo y le enviacutea un mensaje ping para comprobar su estado Enel caso de que se cumpla un tiempo de espera determinado por una estimacioacuten
23
del tiempo de ida y vuelta (RTT por sus siglas en ingleacutes) de la red y no hayarespuesta Mi le vuelve a enviar un mensaje ping indirectamente a traveacutes deun nuacutemero k de miembros escogidos aleatoriamente De no recibir ninguna res-puesta Mi establece que Mj ha sufrido un fallo y lo etiqueta como ldquosospechosordquoinformando al componente de distribucioacuten
Figura 15 Diagrama de tiempo del protocolo SWIMFuente httpswwwcscornelledu
Componente de distribucioacuten
Se encarga de informar de cualquier cambio en los miembros a todo el con-junto Los eventos de nodo caiacutedo y la unioacuten o disociacioacuten de un miembro setransmiten a todos los servidores para que actualicen sus lista Para distribuirla informacioacuten a todos los nodos se podriacutea usar el meacutetodo de multicast perosuele estar deshabilitado Por ello se utiliza una teacutecnica de transmisioacuten denomi-nada Piggybacking mediante la cual se adjunta a los propios mensajes PINGy ACK del algoritmo la informacioacuten a distribuir reduciendo asiacute la congestioacutenen la red
523 Planificacioacuten
Proceso encargado de distribuir las tareas entre los nodos clientes de acuerdoa su estado
El planificador de Nomad estaacute basado en las publicaciones de Google sobresus herramientas de gestioacuten de clusters Borg y Omega14 y entiende los trabajosdescritos por el usuario como un estado deseado es decir su despliegue en unamaacutequina cliente de forma correcta y los clientes como el estado actual esto eslo que se encuentra en ejecucioacuten El registro actualizacioacuten o cancelacioacuten de un
14httpresearchgooglecompubspub43438html
24
trabajo asiacute como el fallo de un nodo cliente implican un cambio de estado atramitar por el sistema lo que se define como evaluacioacuten (evaluation) Esto uacutelti-mo supone comparar el estado actual (clientes) con el estado deseado (conjuntode trabajos registrados) y enviarlos a los planificadores correspondientes que seencargaraacuten de asignar las tareas a los nodos clientes
Figura 16 Procedimiento de asignacioacuten en NomadFuente httpswwwnomadprojectio
En la figura 16 se observa el flujo de trabajo en el que las distintas evalua-ciones se encolan en el evaluation broker que se ejecuta en el servidor liacuteder ygestiona las evaluaciones pendientes asignaacutendoles prioridades
A continuacioacuten los nodos servidores ejecutan los scheduling workers queprocesan las evaluaciones llamando a los distintos planificadores que generanun plan de asignacioacuten esto es un conjunto de relaciones entre las tareas y losnodos clientes donde se ejecutaraacuten Este proceso se divide en dos fases primerose descartan aquellos clientes que no cumplan los requisitos y posteriormentese asigna una calificacioacuten al resto Se selecciona el nodo con mayor puntuacioacuteny se encola el plan en el gestor que se ejecuta en el servidor liacuteder Existen tresplanificadores de acuerdo al tipo de trabajo
Service Incluye aquellos trabajos que estaacuten destinados a ejecutarse en un pe-riacuteodo largo de tiempo Para realizar las asignaciones el planificador evaluacuteala mayor parte de los nodos y usa una versioacuten del algoritmo Best fit in-fluenciada por el trabajo de Google en su herramienta Borg Se trata deun algoritmo de planificacioacuten que sacrifica tiempo a cambio de maximizarel rendimiento de los clientes asignando la tarea a la maacutequina que tengala mayor carga de trabajo con el objetivo de reducir equipos en funciona-
25
miento
Batch Tareas que incluyen listas de comandos en general de menor duracioacuteny que no requieren interaccioacuten con el usuario Se vale del algoritmo deSparrow desarrollado por la universidad de Berkeley15 para limitar losnodos clientes a evaluar
System Trabajos destinados a ejecutarse en todos los nodos incluso los que seunen al cluster posteriormente
Core Mantenimiento interno de Nomad
Una vez se ha realizado el proceso de planificacioacuten el nodo liacuteder lo registra enla cola de planes (plan queue) que se encarga de asignarles prioridad y manejarcondiciones de carrera es decir que no accedan a los recursos de los clientes sincontrol y evitar que eacutestos superen su capacidad
La maacutequina liacuteder del conjunto puede de este modo aceptar una asignacioacuteny ser ejecutada por los clientes o por el contrario rechazaacutersela al planificadorlo que implicariacutea realizar un plan parcial o totalmente nuevo
Finalmente el estado de las evaluaciones se actualizan y los clientes soninformados de las asignaciones ejecutaacutendose las tareas
15httppeopleeecsberkeleyedu~keopublicationssosp13-final17pdf
26
6 Casos de uso y despliegue
Con el objetivo de mostrar las posibles utilidades que este tipo de sistemaspueden tener en las infraestructuras TI actuales se han desplegado las dos he-rramientas en la nube Microsoft Azure usando su servicio cloud de instancias demaacutequinas virtuales Linux para simular un conjunto de ordenadores conectadosentre siacute por una red LAN Sobre ellas se ha implementado dos casos de usouna aplicacioacuten web con una arquitectura con cierta orientacioacuten a microserviciosy un sistema de integracioacuten continua
El coacutedigo y todos los ficheros de configuracioacuten se pueden encontrar en elrepositorio del proyecto en GitHub16
61 Aplicacioacuten Web
Se busca simular el proceso de adaptacioacuten de una solucioacuten web para su des-pliegue en un sistema distribuido con las herramientas anteriormente descritascon el objetivo de aumentar tanto su escalabilidad como disponibilidad medianteredundancia
Se ha partido de una aplicacioacuten ya existente17 un servicio de almacenamien-to y reproduccioacuten de canciones A grandes rasgos este servicio permite crearusuarios subir canciones con sus respectivas portadas tener playlists propias yescuchar las canciones a traveacutes de un navegador web
La solucioacuten estaacute dividida en 4 partes (figura 17)
Una vista web con la loacutegica
Un almacenamiento conectado en red (NAS por sus siglas en ingleacutes)
Una API REST para gestionar las peticiones al almacenamiento
Base de datos NoSQL basada en MongoDB
La nueva tendencia de los proyectos web es su implementacioacuten en contene-dores Docker ya que facilitan su portabilidad y ofrecen un procedimiento dedespliegue raacutepido sobre todo a la hora de desarrollar y realizar pruebas en en-tornos de produccioacuten simulados Por ello en este caso se va a hacer uso de los
16httpsgithubcomAntonioAlfrzCloud-Orchestrators17httpsgithubcomsonsoleslpCDPSfy
27
motores de orquestacioacuten de contenedores de ambas herramientas Marathon enDCOS y el controlador Docker en el caso de Nomad
Figura 17 Arquitectura aplicacioacuten web
A continuacioacuten vamos detallar el despliegue en ambas herramientas de es-ta solucioacuten y observar tanto queacute dificultades se encuentran como que ventajasofrecen El objetivo final es adaptar el proyecto modificaacutendolo lo menos posiblecon objeto de analizar la capacidad de estas herramientas para desplegar cual-quier aplicacioacuten sin que eso conlleve la modificacioacuten de la arquitectura de eacutestaes decir que no sea dependiente del entorno
611 DCOS
Se ha descrito DCOS como una herramienta que se despliega sobre un con-junto de ordenadores y que permite instalar gestionar el despliegue de sistemasdistribuidos
Microsoft Azure cuenta con una plantilla para desplegar en su servicio cloudun cluster de maacutequinas virtuales con DCOS ya instalado que cuenta con
Maacutequinas maestras (1 3 o 5 a seleccionar por el usuario) configuradascomo un conjunto de disponibilidad esto eso Azure da ciertas garantiacuteasde que al menos una maacutequina estaraacute en funcionamiento
Maacutequinas agentes Por motivos de seguridad se distinguen dos roles
bull Nodos privados solo accesibles desde la red interna y configuradoscomo un conjunto de escala un recurso de Azure para gestionar ydesplegar maacutequinas con configuraciones ideacutenticas para permitir unraacutepido escalado
bull Un equipo conectado accesible desde Internet a travntildees de un balan-ceador de carga puacuteblico y situado en una subred externa
28
Dos balanceadores de carga
bull La interfaz puacuteblica del cluster que se conecta con el cliente puacuteblicobull Acceso a los equipos maestros para el administrador que soacutelo permiteconexioacuten mediante SSH y credenciales
Almacenamiento para todas las maacutequinas
Configuraciones necesarias de red y seguridad
En la figura 18 se observa un diagrama de la infraestructura
Figura 18 Infraestructura en Azure
El primer obstaacuteculo es la persistencia de estado de la aplicacioacuten que seconsigue gracias a una base de datos no relacional basada en MongoDB asiacutecomo el almacenamiento de las canciones Para implementarla tenemos variasposibilidades
Montar un sistema externo de almacenamiento conectado en red en todoslos agentes donde se ejecuten las tareas de esta manera si una tarea pasade un nodo a otro por cualquier motivo puede tener acceso a los mismosficheros (opcioacuten del caso de uso original)
Implementar un sistema de ficheros distribuidos en los agentes
Usar los servicios de almacenamiento de las nubes puacuteblicas
Aprovechar el sistema de voluacutemenes persistentes de Apache Mesos Eacutestepermite reservar recursos de un agente de forma que al arrancar una tarease crea un volumen independiente del ciclo de vida de eacutesta con ello esosrecursos donde se ha almacenado la informacioacuten pueden volver a ofrecerseal mismo entorno de tal manera que otra tarea pueda acceder a ella
DCOS aprovecha este sistema de voluacutemenes persistentes y permite instalarbases de datos distribuidas como ArangoDB o Apache Cassandra sin embargoesto implicariacutea modificar todo el coacutedigo referente al modelo de la base de datos
29
Por motivos de eficiencia y latencia asiacute como de una mayor gobernabilidadde los datos la mejor opcioacuten es usar el recurso de voluacutemenes persistentes queofrece Apache Mesos ya que de esta manera se gestionariacutea la aplicacioacuten completamediante una uacutenica herramienta Sin embargo esto implica que la informacioacutense encuentra exclusivamente en el agente donde se haya ejecutado la tarea y porlo tanto se sigue requiriendo de software externo para distribuir la informacioacutenpara que se accesible para todos los agentes A la hora de realizar este proyectose encontraba en desarrollo Flocker una solucioacuten desarrollada por ClusterHQque permite compartir los voluacutemenes de Docker a traveacutes de un cluster quesi bien es compatible con el planificador de Mesos el proyecto se encontrabatodaviacutea en fases tempranas de desarrollo y los sistemas de almacenamiento quesoporta quedaban fuera del aacutembito de este trabajo
Por todo ello dado que las maacutequinas se han desplegado en la nube puacuteblicade Azure se decidioacute usar su servicio de almacenamiento de objetos para lascanciones y otra maacutequina para desplegar MongoDB y asiacute mantener el modelode datos original de la aplicacioacuten La diferencia del almacenamiento de obje-tos con respecto a nivel de fichero es que el primero no tiene jerarquiacutea paraorganizar los archivos eacutestos se guardan como objetos (con sus metadatos) enun mismo espacio soacutelo diferenciaacutendose por un identificador uacutenico esto implicaentre otras cosas que se puede acceder a un fichero dado uacutenicamente su IDindependientemente de la localizacioacuten fiacutesica de eacuteste facilitando pues la gestioacuteny el desarrollo
El coacutedigo del proyecto se ha modificado en los siguientes apartados
Las direcciones de la base de datos y los balanceadores de carga asiacute comosus puertos estaban originalmente fijos Se han configurado como variablesde entorno para facilitar el descubrimiento del servicio y hacer transpa-rente la aplicacioacuten al entorno de despliegue
La API REST se ha adaptado al almacenamiento en Azure en vez de enlocal
Estas modificaciones no suponen un cambio sustancial pero permiten separala persistencia de las tareas ejecutadas por DCOS lo que facilita en granmedida su ejecucioacuten al ser totalmente sin estado y ademaacutes implican tenerlos datos bajo un mayor control
Para la orquestacioacuten de contenedores se va a usar el entorno Marathondesarrollado tambieacuten por Mesosphere Eacuteste se puede usar a traveacutes de una interfazgraacutefica la interfaz de liacutenea de comandos (en lo que sigue CLI por sus siglas eningleacutes) de DCOS o con su API HTTP
Primero se han publicado la imaacutegenes de los contenedores que encapsulanla interfaz web y la api de la aplicacioacuten en el repositorio puacuteblico DockerHub
Los despliegues en este entorno se describen mediante ficheros JSON en losque se detalla entre otras opciones la imagen del contenedor los puertos a usar
30
los recursos que debe ocupar en un nodo o las instrucciones de monitorizacioacuten
Para el servicio de descubrimiento DCOS ofrece la posibilidad de asignardirecciones IP virtuales (VIP por sus siglas en ingleacutes) a tareas que se compartenen todos los nodos DCOS lleva integrado un balanceador de carga a nivel TCP(el componente denominado Minuteman) que balancea entre las direccionesvirtuales de las tareas y todas las instancias de eacutestas a lo largo del cluster Estoes necesario por dos motivos equilibrar la carga de los equipos con el fin deevitar un punto de uacutenico fallo mediante redundancia y evitar la contienda dedirecciones al ejecutar las tareas en puertos aleatorios
Este balanceador de carga estaacute basado en el trabajo de Michael Mitzenma-cher The Power of Two Choices in Randomized Load Balancing18 A grandesrasgos el algoritmo mantiene una media moacutevil exponencial de latencias paracada destino (backend) ademaacutes de las caiacutedas consecutivas Si un destino noresponde a una negociacioacuten en tres pasos (three way handshake) de forma con-secutiva en un periodo inferior a 5 ms se considera caiacutedo El algoritmo iterasobre los destinos disponibles en base a su histoacuterico de fallos y escoge dos deforma aleatoria de los cuales coge el de mejor meacutetrica
Las direcciones virtuales soacutelo se pueden resolver dentro del cluster porello para implementar la interfaz puacuteblica de la aplicacioacuten esto es el balancea-dor de carga de la interfaz web usaremos un paquete de DCOS denominadomarathon-lb un balanceador basado en HAProxy y adaptado por MesosphereEn este caso equilibra la carga de todas instancias de las tareas ejecutadas porel entorno Marathon por sus etiquetas y permite ademaacutes definir como puntode entrada muacuteltiples hosts virtuales definidos por sus nombres completos dedominio (FQDN por sus siglas en ingleacutes) en nuestro caso la interfaz puacuteblicadel balanceador de Azure para los agentes
Por motivos de seguridad todas las tareas se ejecutan en los agentes privadoses decir los que son exclusivamente accesibles desde la red interna Por su partemarathon-lb se ejecuta en el agente puacuteblico que cuenta con IP puacuteblica y lospuertos 80 (HTTP) y 8080 abiertos de forma que la aplicacioacuten sea accesibledesde Internet Esto es posible debido a que Apache Mesos permite reservarrecursos mediante roles asignados a nodos para un uso especiacutefico De esta formala arquitectura vista desde la aplicacioacuten quedariacutea como en la figura 19
18httpswwweecsharvardedu~michaelmpostscriptstpds2001pdf
31
Figura 19 Arquitectura de la aplicacioacuten web en DCOS
Ejecucioacuten
A la hora de desplegar la aplicacioacuten DCOS puede gestionarse medianteuna interfaz graacutefica o una interfaz de liacutenea de comandos La primera se accedea traveacutes de un navegador web en el puerto 80 (HTTP) y permite instalar losentornos disponibles observar el estado de los nodos y las tareas que se estaacutenejecutando y los ficheros de registros que eacutestas generan
La CLI permite el control desde un nodo o una maacutequina remota (suponiendoque los maestros tienen IP puacuteblica y el puerto 80 abierto) ya que DCOS tieneun sistema de autorizacioacuten que permite tener una interfaz puacuteblica con ciertasgarantiacuteas de seguridad
Por su parte cada entorno de trabajo puede ser controlado por la CLI peroademaacutes cuenta con sus propias interfaces Marathon expone una API HTTPen el puerto 8080 de la direccioacuten puacuteblica de los maestros del cluster asiacute comootra interfaz graacutefica Para desplegar un contenedor se podriacutea usar la CLI
$ dcos marathon app add lt f i l e j songt
O la API HTTP
$ cu r l minusX POST http lt ip_maestro gt8080v2apps minusd ltf i l e jsongt minusH Contentminustype app l i c a t i o n j son
32
612 Nomad
La arquitectura de Nomad es maacutes sencilla ya que solo requiere de un ficheroejecutable en todos los nodos para funcionar Si DCOS es la base de instala-cioacuten de entornos de terceros Nomad integra todas las funcionalidades baacutesicasesto es gestor de recursos planificador y ejecutor en los nodos cliente Estaherramienta cuenta con un menor tiempo de desarrollo y en el momento deescribir este documento cuenta exclusivamente con los siguientes controladoresen comparacioacuten con los entornos de DCOS
Motor Docker es decir funcioacuten de orquestacioacuten de contenedores
Ejecucioacuten de archivos binarios como comandos de Shell
Ejecucioacuten de aplicaciones Java
Virtualizacioacuten de maacutequinas mediante tecnologiacutea QEMU
Todos ellos necesitan que la tecnologiacutea subyacente esteacute instalada en las maacute-quinas clientes (Docker Java QEMU) Actualmente no permite el registro decontroladores por parte de terceros aunque estaacute planificado en un futuro ofreceruna interfaz para su desarrollo
Nomad no cuenta con el servicio de descubrimiento sin embargo puede inte-grarse con la herramienta Consul desarrollada por la misma empresa Por otrolado para el balanceo de carga usaremos un contenedor Docker con HAProxyuna herramienta de coacutedigo abierto que ofrece tanto servicios de proxy como debalanceador y cuyos ficheros de configuracioacuten completaremos con el proyectoConsul Template19
Consul
Consul sigue la misma arquitectura que Nomad es decir un nodo servidorque orquesta un conjunto de maacutequinas clientes y permite a los procesos que seejecutan en los equipos definirlos como servicios ofreciendo diversas caracteriacutes-ticas entorno a estos de los cuales vamos a usar dos
Descubrimiento de servicio Las maacutequinas clientes publican en el cataacutelogode servicios las tareas en ejecucioacuten y Consul les asigna nombres de dominioaccesibles por todos los miembros del cluster a traveacutes de la interfaz DNSincluida en esta herramientaConsul se integra con Nomad de forma que todas las tareas que se ejecu-ten en la segunda son automaacuteticamente publicados como servicios de laprimera de esta manera no hace falta conocer la direccioacuten de la maacutequinacliente donde se esteacute ejecutando el proceso ya que se puede acceder a eacutela traveacutes de su nombre de dominio de forma transparente Por ejemplo si
19[httpsgithubcomhashicorpconsul-template]
33
ejecutamos una tarea con ID web en el puerto 8080 se puede acceder aella en la direccioacuten webserviceconsul8080Para que las direcciones propias de Consul las resuelva su propio DNS y noel que esteacute asignado por defecto en la maacutequina usaremos la herramientadnsmasq20 que permite especificar la direccioacuten de un servidor DNS paraconsultas de direcciones especiacuteficas
Monitorizacioacuten Permite realizar comprobaciones del servicio y seguir su esta-do Aprovecharemos esta funcionalidad tanto para definir el propio procesode Nomad como servicio de Consul como las tareas desplegadas
HAProxy + Consul Template
HAProxy es una solucioacuten versaacutetil de coacutedigo abierto que ofrece solucionesde balanceo de carga y proxy Existen otras herramientas en el mercado comoNGINX o ldirectord sin embargo HAProxy suponiacutea una solucioacuten sencilla deconfigurar para mostrar el caso de uso
El uso de estas herramientas se debe a dos motivos para que no existacontienda con respecto a los puertos de los clientes usados por las tareas eacutestos sevan a asignar de forma dinaacutemica lo que en principio implicariacutea que la aplicacioacutendeberiacutea realizar consultas DNS de tipo SRV (que incluye puertos) a la interfazde Consul y balancear la carga entre tareas por redundancia y capacidad
Como la direccioacuten IP y puerto son variables cada vez que las tareas seactualicen o se reasignen es necesario volver a configurar HAProxy de formamanual Por ello HashiCorp ha desarrollado un programa denominado Con-sul Template que realiza peticiones sucesivas a la interfaz HTTP de Consul delas direcciones fiacutesicas de un servicio y reinicia automaacuteticamente el proceso deHAProxy Asiacute definiendo estas tareas como servicios Consul podremos tantomonitorizarlas como escalar las tareas dinaacutemicamente sin necesidad de cambiarel balanceador A partir del contenedor Docker oficial de HAProxy se ha desa-rrollado otro con la configuracioacuten baacutesica y con Consul Template para desplegarlocomo una tarea en Nomad
Despliegue
Se ha usado el mismo coacutedigo que en el apartado anterior con la persistenciaen el servicio de almacenamiento de Azure Desde la perspectiva del hardwarese implementaraacute la misma infraestructura que en el caso de DCOS (figura 18)estos es definiremos dos tipos de maacutequinas clientes un agente que se conectaraacutecon el balanceador de carga con nombre de dominio puacuteblico y donde se desple-garaacute el balanceador de carga de la vista web y agentes privados no accesiblesdesde fuera del cluster y donde se ejecutaraacuten el resto de tareas en la red inter-na La principal diferencia radica en las tareas que ejecutan HAproxy y ConsulTemplate que sustituye a las direcciones IP virtuales que ofrece DCOS
20httpwwwthekelleysorgukdnsmasqdochtml
34
Figura 20 Despliegue en Azure de Nomad+Consul
Cabe matizar que los balanceadores basados en HAProxy se implementanpor necesidad de la aplicacioacuten para el descubrimiento del servicio a diferenciade los de Azure que se implementan por motivos de seguridad y escalabilidaddel cluster en siacute
Configuracioacuten Nomad
Los ficheros de configuracioacuten de las maacutequinas maacutester y cliente son similaresy comparten la mayoriacutea de las opciones como por ejemplo el nombre del nodoo la interfaz de red donde escucha Nomad las peticiones Sus opciones son engeneral auto-explicativas sin embargo existen dos detalles que matizar
El proceso de Nomad escucha las peticiones tanto de los protocolos deconsenso como del usuario a traveacutes de una interfaz de red que se debeindicar en el fichero de configuracioacuten
En el caso de los clientes se deben indicar las direcciones de los servidoresdel cluster sin embargo se trata de un sistema dinaacutemico en el que losnodos pueden sufrir errores y cambiar de direccioacuten Por ello se ha definidoNomad como un servicio de Consul y asiacute poder definir la direccioacuten de losservidores como un nombre de dominio no por su direccioacuten fiacutesica que elservidor DNS de Consul se encargaraacute de resolver
Por defecto Nomad usa los siguientes puertos
API HTTP 4646 Peticiones HTTP y recepcioacuten de oacuterdenes mediante laliacutenea de comandos
RPC 4647 Protocolo de consenso entre los nodos del cluster
Serf 4648 Protocolo de gossip entre los servidores de los centros de datosgobernados por Nomad
35
Los dos uacuteltimos deben ser interfaces alcanzables por otros nodos sin embargo laAPI HTTP por motivos de seguridad deberiacutea ser local ya que en caso contrariocualquier persona con acceso a ella tiene el control sobre la herramienta Eacutestasolo deberiacutea estar accesible en un servidor o gestionarlo mediante una terminalSSH por ejemplo En este trabajo al ser una prueba de concepto se ha abiertoen todos los nodos
Trabajos de Nomad
Las tareas se detallan en ficheros con formato HashiCorp Configuration Lan-guage un derivado del formato JSON creado por la empresa que le da nombrecompatible con eacuteste y que permite comentarios
En estos ficheros se puede definir
La regioacuten y el centro de datos donde se ejecutaraacute (Nomad permite lagestioacuten de centros de datos geograacuteficamente distribuidos en regiones)
La poliacutetica de actualizacioacuten de la tarea
Grupo de tareas esto es que se ejecutaraacuten en el mismo nodo
El nuacutemero de grupos a ejecutarescalar asiacute como los liacutemite que debencumplir los nodos asignados
La poliacutetica de reinicio ante fallo o error
Tareas El controlador su configuracioacuten los paraacutemetros del servicio aso-ciado a registrar en Consul asiacute como los recursos que consume (puertosmemoria)
En nuestro caso usamos sobre todo el controlador Docker esto eso orques-tacioacuten de contenedores en los nodos clientes y tres de sus opciones
Imagen del contenedor Se han subido todas las imaacutegenes del proyecto a Doc-ker Hub donde por defecto se busca la imagen
Puertos Los puertos a usar por el contenedor que pueden ser estaacuteticos asigna-dos por el usuario o dinaacutemicos siendo Nomad el que se encarga de mapearun puerto libre del nodo cliente al expuesto por el contenedor
Servidores DNS Como usamos la interfaz DNS de Consul como descubri-miento de servicio se debe configurar el contenedor para que use cualquiernodo del cluster como servidor DNS
Configuracioacuten Consul
Al ser desarrolladas por la misma empresa los ficheros de configuracioacuten deConsul y Nomad comparten muchas opciones Consul tambieacuten acepta peticionesa traveacutes de una interfaz de red siendo los puertos usados por defecto
36
RPC 8300 8400 Maneja la peticiones del resto de nodos y usuarios
Serf 8301 8302 Protocolo gossip
HTTP API 8500
HTTPS API Desactivada por defecto
Interfaz DNS 8600
Se debe asignar a los protocolos internos del cluster esto es RPC y Serf unainterfaz alcanzable por los nodos y por el contrarioasignar a los dos uacuteltimos ala interfaz de loopback por motivos de seguridad
Cabe destacar que Consul tambieacuten cuenta con una interfaz graacutefica que per-mite ver el estado de los equipos y los servicios registrados y que se encuentra enel mismo puerto que la API HTTP en la direccioacuten httpIP_EQUIPO8500ui
Ejecucioacuten
Tanto Nomad como Consul requieren de la ejecucioacuten de un fichero en todoslos nodos integrantes del cluster Como prueba de concepto se ha decidido usardos servidores para ambos aunque cabe matizar que es un nuacutemero ineficienteya que la caiacuteda de uno de ellos supondriacutea la peacuterdida del cuoacuterum y por tantodel consenso del cluster
En primer lugar se arrancan los servidores que son los encargados de ejecu-tar el protocolo de consenso y gestionar el cluster y a continuacioacuten los clientesque no tienen praacutecticamente estado y dependen de los servidores
En el caso de Consul se debe indicar el directorio donde se guardan losficheros que describen los servicios asiacute como el archivo que especifica el resto delas opciones
1 Se inicia el primer servidor en uno de los equipos
$ consu l agent minuscon f i gminusd i r e t c consu l d s e r v i c e s minuscon f i gminus f i l e consu l_server j son
2 Los siguientes equipos deben unirse al anterior por lo que antildeadimos elargumento join con la direccioacuten del primer servidor Para el caso de otrosservidores
$ consu l agent minuscon f i gminusd i r e t c consu l d s e r v i c e s minuscon f i gminus f i l e consu l_server j son minus j o i n ltIP_servidor1gt
37
Una vez los servidores han alcanzado el consenso y elegido un liacuteder en losclientes
$ consu l agent minuscon f i gminusd i r e t c consu l d s e r v i c e s minuscon f i gminus f i l e c on su l_c l i en t j son minus j o i n ltIP_cualquierServ idorgt
El proceso para iniciar Nomad es igual y los comandos similares sin embargoya no es necesario indicar una direccioacuten IP fija en los equipos sino el nombre dedominio del servicio de Nomad registrado por Consul En el primer servidor
$ nomad agent minusc on f i g nomad_server j son
Y el resto de equipos (con su fichero de configuracioacuten correspondiente)$ nomad agent minusc on f i g nomad_server j son minus j o i n nomad s e r v i c e consu l
Por uacuteltimo para desplegar la aplicacioacuten web se han escrito tres ficherosque detallan las tareas de la interfaz web API y los balanceadores de cargaMediante la CLI
$ nomad run minusaddress=http lt ip_c lus te r gt4646 lt f i l e hclgt
O mediante la API HTTP de Nomad$ cu r l minusX POST minusd ltf i l e hclgthttp lt ip_c lus te r gt4646 jobltjob_namegt
Ansible
Como se puede comprobar con el aumento del nuacutemero de equipos pasa aser inviable manejar todos los nodos a traveacutes de terminal Ademaacutes como seha comentado con anterioridad Nomad requiere que en los nodos clientes es-teacuten instalados las herramientas que soporten las tareas por ejemplo el motorde Docker Por ello para facilitar tanto el arranque como la instalacioacuten de lasdependencias vamos a usar Ansible una herramienta de coacutedigo abierto desarro-llada en Python que permite gestionar configuraciones aprovisionar recursosdespliegue de aplicaciones de forma automaacutetica
A grandes rasgos esta herramienta funciona mediante ficheros en formatoYAML denominados play-books que describen un conjunto de pasos a ejecutaren una lista de equipos remotos Estos pasos son ejecutados por moacutedulos inde-pendientes a traveacutes de SSH es decir en cualquier ordenador con conexioacuten a los
38
hosts dado su contrasentildea o clave puacuteblica puede arrancar el script y realizariacutealos pasos de forma remota gestionando el cluster desde un solo equipo
Se han desarrollado guiones para lo siguiente
Descarga de los binarios de Nomad y Consul en todos los nodos copiade los ficheros de configuracioacuten baacutesicos y modificarlos de acuerdo a cadanodo (nombre del equipo direccioacuten IP)
Instalacioacuten de las dependencias
Arranque de Nomad y Consul
Ansible extiende su funcionalidad a traveacutes de moacutedulos independientes que per-miten por ejemplo instalar paquetes mediante herramientas de gestioacuten de pa-quetes (APT yum) aprovisionar automaacuteticamente maacutequinas virtuales de Ama-zon EC2
Algunas opciones de los ficheros de configuracioacuten de Nomad y Consul sondependientes del nodo particular por ejemplo la interfaz de red Para estetrabajo se ha realizado un moacutedulo para modificar los ficheros de configuracioacutende forma automaacutetica En el repositorio del proyecto se encuentra una carpetadonde se encuentran todos los ficheros necesarios para desplegar un clustertotalmente funcional solo requiere de una liacutenea de terminal con Ansible
$ ans ib l eminusplaybook minus i hos t s minusk ltssh_passgt minusu ltnode_usergt s i t e yml
39
62 Servicio de integracioacuten continua
Se ha implementado un sistema de integracioacuten continua que permite ejecu-tar tareas de compilacioacuten y pruebas de forma distribuida aumentando asiacute elrendimiento de los equipos En primer lugar se detallaraacute los motivos por los quepuede resultar beneficioso para las empresas una implementacioacuten de este tipo alo que seguiraacute los detalles del despliegue
621 DevOps
Metodologiacutea que defiende la comunicacioacuten y colaboracioacuten entre desarrolla-dores de software y los profesionales de operaciones a lo largo de todo el ciclo devida de una aplicacioacuten Estaacute muy relacionado con el desarrollo aacutegil de softwareesto es un enfoque para los proyectos que defiende el desarrollo iterativo e in-cremental donde los requisitos y soluciones evolucionan con el tiempo seguacuten lanecesidad del proyecto DevOps extiende esta filosofiacutea a todas los componentesde un servicio incluyendo sistemas y operaciones
Se trata de un concepto que cada organizacioacuten o empresa adapta a suspropias necesidades y procesos de negocio en este proyecto nos vamos a centraren la integracioacuten continua una praacutectica fundamental tanto del desarrollo aacutegilcomo de esta filosofiacutea
622 Integracioacuten Continua
Se define como una praacutectica de desarrollo software donde los miembros delequipo ponen en comuacuten su trabajo frecuentemente al menos una vez al diacutea21Cada integracioacuten se verifica con una compilacioacuten automaacutetica que incluye laejecucioacuten de pruebas para detectar errores de integracioacuten tan pronto como seaposible
Desde el punto de vista operativo esto supone automatizar la configuracioacutende equipos o el despliegue de maacutequinas virtuales donde compilar el proyecto yejecutar las pruebas y posteriormente eliminarlas Este flujo de trabajo se vebeneficiado en entornos distribuidos ya que el objetivo del desarrollador es com-probar el resultado de las pruebas raacutepidamente sin preocuparse del despliegueo los propios equipos
Para esta prueba de concepto vamos a usar Jenkins un servidor de integra-cioacuten continua escrito en Java que nos permite definir trabajos que contendraacutenla descripcioacuten tanto del entorno como su ejecucioacuten
Este sigue una estructura maestro-esclavo muy similar al de los gestores declusters usados en este proyecto el maestro contiene toda la loacutegica del servicio
21httpmartinfowlercomarticlescontinuousIntegrationhtml
40
trabajos autenticacioacuten y los esclavos son los encargados de la ejecucioacuten ensiacute Jenkins tiene varias viacuteas para aprovisionar los uacuteltimos
Mediante SSH
Interfaz graacutefica
Desarrollar un script propio
Ejecucioacuten de un fichero java
La ventaja de usar planificadores es que el despliegue de esclavos es dinaacutemicoes decir no tener una maacutequina especiacuteficamente configurada para ello DCOS yNomad se encargaraacuten de configurar estos despliegues en sus maacutequinas y poste-riormente eliminarlos Para ello se ha usado la uacuteltima opcioacuten definiendo tareasque descarguen el fichero java Con todo ello se consigue un entorno de inte-gracioacuten continua eficiente que ademaacutes permite la ejecucioacuten de otros servicios deforma independiente
Jenkins permite la creacioacuten de plugins que extienden sus funcionalidadesTanto Nomad22 como Apache Mesos cuentan con uno que permite su integra-cioacuten
Para esta prueba se va a usar el mismo proyecto que para el caso de usode orquestacioacuten de contenedores la aplicacioacuten web al que se le ha antildeadido untest para comprobar que se conecta correctamente a la base de datos medianteMocha un framework de Nodejs Por otro lado se antildeade el plugin de git ya queel coacutedigo se obtiene de GitHub el repositorio remoto de control de versiones delproyecto
El proceso general de ejecucioacuten seriacutea como sigue
1 Se ejecuta el maestro de Jenkins como tarea Docker partiendo de la imagenoficial
2 Al arrancar un trabajo se manda una tarea a los planificadores que laasignaraacuten a un nodo cliente Esta tarea consiste en la descarga del ficherode configuracioacuten Java y arrancarlo configurando el equipo como un clientede Jenkins temporalmente
3 Jenkins ejecuta el trabajo en el nuevo cliente en este caso iniciar la apli-cacioacuten web iniciar las pruebas y generar un informe
4 Se elimina el cliente
A continuacioacuten se detallan los matices de cada herramienta a la hora de imple-mentar este servicio
22Desarrollado por Ivo Verberk httpwwwivoverberknl
41
623 Jenkins con Nomad
El plugin permite la ejecucioacuten del fichero Java mediante dos controladorescontenedores Docker y Java En este proyecto nos hemos decantado por el pri-mero ya que nos ahorra instalar la maacutequina virtual de java en todos los nodoscliente Por ello se ha construido un contenedor base con Java para la ejecucioacutendel fichero de configuracioacuten y Nodejs para lanzar la aplicacioacuten web
El plugin se configura con la direccioacuten IP del cluster y el contenedor queejecuta el esclavo Jenkins Por su parte el trabajo en Jenkins se define conel repositorio en GitHub donde se aloja el coacutedigo del proyecto a probar y loscomandos a ejecutar en este caso npm update y npm test
624 Jenkins con DCOS
En el caso de DCOS su sistema de paquetes incluye Jenkins por lo queal instalarlo ya se tiene la configuracioacuten de Mesos totalmente funcional Sinembargo para ejecutar la aplicacioacuten en particular y las pruebas se requiere deNodejs en los equipos esclavos por ello debemos antildeadir un plugin de Jenkinsque permite instalar este entorno antes de ejecutar el trabajo Una vez hechoesto soacutelo queda definir la tarea igual que en el caso anterior
Cabe destacar que Mesosphere tambieacuten ha desarrollado un plugin que per-mite hacer despliegues en Marathon de tal manera que permitiriacutea con cadacommit del coacutedigo compilar la imagen del contenedor Docker y desplegarlaautomaacuteticamente aunque en este proyecto no se ha hecho pruebas de esta fun-cionalidad
42
7 Escalando la infraestructura
Uno de los factores clave que se busca a la hora de implementar sistemasdistribuidos es el poder escalar la infraestructura de forma maacutes sencilla estoes detectar que las maacutequinas estaacuten alcanzando el liacutemite de su capacidad yaumentar eacutesta ya sea mejorando sus caracteriacutesticas teacutecnicas o antildeadiendo maacutesnodos al cluster
El coacutedigo y todos los ficheros de configuracioacuten de esta seccioacuten tambieacuten sepueden encontrar en el repositorio del proyecto en GitHub23
71 Disentildeo
Microsoft Azure permite organizar los servicios cloud de forma loacutegica a traveacutesde grupos de recursos y asiacute poder crear o eliminar eacutestos en conjunto parauna aplicacioacuten determinada (por ejemplo una aplicacioacuten web suele requerir demaacutequinas virtuales bases de datos almacenamiento) Ademaacutes dispone dela opcioacuten de crear plantillas en formato JSON que permite al desarrolladordefinir los recursos y su interrelacioacuten para desplegar de forma automaacutetica unainfraestructura TI en la nube
Azure tambieacuten ofrece la posibilidad de monitorizar el estado de las maacutequinasvirtuales a traveacutes de extensiones lo que permite configurar el escalado automaacute-tico al alcanzar cierto liacutemite definido por el operador Eacutesta es a priori la formaen que deberiacutea implementarse hablando en teacuterminos de eficiencia sin embargoesta aproximacioacuten es totalmente dependiente de la plataforma es decir no sepuede extrapolar a otro proveedor o sobre recursos propios sin realizar un nue-vo disentildeo En este proyecto las tareas que son ejecutadas por estos equipos notienen estado ya que todo lo relativo a la persistencia lo hemos asignado fueradel cluster esto permite escalar la plataforma a traveacutes de otra aproximaciones
Las plantillas aceptan una serie de variables a indicar por el usuario entreotras los conjuntos de escala para definir los nodos aceptan una variable quedefine el nuacutemero de maacutequinas que los componen Por otro lado Azure ofreceuna API REST y kits de desarrollo software (SDK por sus siglas en ingleacutes) quepermiten su despliegue de forma programaacutetica Aprovechando estas facilidadesen este proyecto se va a aproximar la escalabilidad con el sucesivo desplieguede la infraestructura de forma automaacutetica se monitorizan los equipos y si sedetecta una maacutequina excesivamente cargada se aumenta el nuacutemero de equiposen la plantilla y se vuelve a desplegar
23httpsgithubcomAntonioAlfrzCloud-Orchestrators
43
En este proyecto se han disentildeado las plantillas para desplegar la arquitec-tura necesaria tanto de Nomad como de DCOS En el caso de la primera eldespliegue es maacutes descriptivo ya que incluye maacutequinas virtuales grupos de se-guridad redes En el caso de DCOS Azure cuenta con un servicio especiacuteficopara clusters gobernados por DCOS denominado Azure Container Service queincluye los componentes necesarios y la instalacioacuten ya realizada
72 Implementacioacuten
En primer lugar para monitorizar el estado de los equipos se va a usar laherramienta Nagios un sistema que permite controlar el estado del hardwarey los servicios de un equipo Se trata de una herramienta muy completa de laque se va a usar su capacidad para ejecutar comandos (plugins) en los nodospara detectar picos de carga generar alertas y ejecutar programas para estoseventos
Se ha desplegado una maacutequina virtual con esta herramienta en ambos siste-mas y se ha instalado una extensioacuten de Nagios (Nagios Remote Plugin Executor)en todos los nodos que permite ejecutar comprobaciones remotamente en con-creto para esta prueba de concepto medir el nivel de saturacioacuten de la unidadcentral de procesamiento (CPU por sus siglas del ingleacutes) Cuando sucede uncambio de estado de una maacutequina esto es cuando este paraacutemetro supera el liacutemi-te definido por el operador Nagios permite actuar en consecuencia ejecutandoprogramas por ello se ha desarrollado un script que ejecuta lo siguiente
Un programa desarrollado en Python con el SDK de Azure que modificalas plantillas y despliega los recursos
Un guioacuten de Ansible para instalar todos los componentes necesarios en lasnuevas maacutequinas y arrancar de nuevo el cluster y las aplicaciones
44
8 Resultados y conclusiones
En este uacuteltimo apartado se da una visioacuten global del proyecto asiacute como a lasconclusiones maacutes importantes a las que se ha llegado y posibles temas futurosde desarrollo
81 Comparacioacuten
Ambas herramientas ofrecen las funcionalidades para gestionar los recursoseficientemente ofreciendo a los desarrolladores una plataforma donde desplegarsus aplicaciones de forma distribuida independientemente de los equipos fiacutesicosy el hardware que las soporten
DCOS es una herramienta que en un comienzo fue privativa pero cuyos res-ponsables la empresa Mesosphere decidieron publicar una versioacuten de coacutedigoEacutesta nos permite gestionar un cluster de una forma sencilla y usable ademaacutes decomplementarlo con otras herramientas como el balanceador de carga integradoo la autenticacioacuten de usuarios ademaacutes estaacute basada en Apache Mesos un pro-yecto de relativa madurez y con el soporte de la Apache Software FoundationDe forma resumida DCOS ofrece muchas posibilidades y servicios a cambiode una arquitectura e instalacioacuten maacutes compleja
Por su parte HashiCorp con menor tiempo de desarrollo ha conseguidouna herramienta muy sencilla de desplegar que ademaacutes cumple con todas lasfuncionalidades baacutesicas ejecutando un simple binario en cada nodo se puededesplegar un gestor de clusters totalmente funcional Sin embargo no cuentacon todas las posibilidades de Mesos (Nomad cuenta con menos controladoresque entornos posibles de Mesos) ni con los antildeadidos de DCOS lo que implicael uso de otras herramientas para complementar el servicio (Consul HAProxy)
De entre las dificultades encontradas al usar estas herramientas y desplegaraplicaciones sobre ellas se puede destacar la depuracioacuten en ocasiones se desco-noce si un error viene de la propia herramienta de la aplicacioacuten desplegada o delequipo fiacutesico si no se cuenta con un sistema de procesamiento de registro unose puede encontrar con muacuteltiples terminales abiertas inspeccionando numerososficheros de registro buscando posibles errores Ademaacutes no dejan de ser solucio-nes que para usar eficientemente se debe conocer parte de su funcionamientoy sintaxis a la hora de describir la tareas lo que supone un esfuerzo antildeadido yaque cada una tiene sus particularidades y liacutemites
45
82 Conclusiones
En una sociedad cada vez maacutes digital las empresas deben adaptarse a unmercado cuya demanda de contenido no deja de crecer Las nuevas arquitecturascomo microservicios asiacute como la gran cantidad de datos generada implica queuna mejor gestioacuten de los recursos y la rapidez para desplegar o escalar solucionesdando valor al cliente lo maacutes raacutepido posible es uno de los objetivos de todas lasempresas de base tecnoloacutegica
Las ventajas que ofrecen los planificadores con aplicaciones distribuidas sonnumerosas sin ir maacutes lejos empresas tan punteras como Google llevan maacutesde 10 antildeos orquestando contenedores24 Por un lado permiten aumentar elrendimiento de los equipos propios y por otro implementar un servicio comoplataforma para despliegues distribuidos sobre cualquier conjunto hardware deesta forma se provee un servicio similar al de la nube puacuteblica pero con laprincipal diferencia de que se elimina la independencia con el proveedor (vendorlock-in) esto es las aplicaciones no tienen limitaciones impuestas por eacuteste talescomo lenguaje de programacioacuten o herramientas y permite despliegues hiacutebridosentre recursos propios y la nube
83 Objetivos conseguidos
Implementacioacuten de los planificadores propuestos en la nube Se ha en-tendido y detallado el funcionamiento de estas herramientas y se hanimplementado en el servicio de infraestructura de Microsoft Azure
Despliegue de aplicaciones y servicios distribuidos Servicios que se usanactualmente en la industria del desarrollo software asiacute como una aplica-cioacuten web con una arquitectura moderna han sido desplegados de formadistribuida en los equipos cumpliendo con la funcionalidad esperada ade-maacutes de consiguiendo una alta disponibilidad
Aproximacioacuten de arquitectura escalable Se ha hecho una aproximacioacutende infraestructura escalable de forma que sea parcialmente extrapolable aotros proveedores
24httpwwwnextplatformcom20160322decade-container-control-google
46
84 Liacuteneas de investigacioacuten
Siguiendo con la materia de este proyecto se presentan posibles liacuteneas deinvestigacioacuten
Analizar el despliegue con estas herramientas de aplicaciones de Big Datay comparar la eficiencia con respecto a soluciones especializadas
Analizar el rendimiento de los algoritmos de planificacioacuten antes pruebasde estreacutes y situaciones de alta contienda
Comparar el uso de estas herramientas con las praacutecticas actuales de laindustria o implementacioacuten en un sistema de produccioacuten real
47
Referencias
[1] LA Barroso y U Houmllzle laquoThe Datacenter as a Computer An Introduc-tion to the Design of Warehouse-Scale Machinesraquo En Morgan amp ClaypoolPublishers ()
[2] Systems Research Group ndash NetOS (University of Cambridge) The evolu-tion of cluster scheduler architectures 2016 url httpswwwclcamacukresearchsrgnetoscamsasblog2016-03-09-scheduler-architectureshtml
[3] A Das I Gupta y A Motivala SWIM Scalable Weakly-consistent Infection-style Process Group Membership Protocol Inf teacutec Dept of ComputerScience Cornell University url https www cs cornell edu ~asdasresearchdsn02-swimpdf
[4] D Dubhashi y A Das Mastering Mesos PACKT Publishing mayo de2016
[5] The Apache Software Foundation Apache Mesos documentation urlhttpsmesosapacheorg
[6] David Greenberg Building Applications on Mesos OrsquoReilly Media 2016[7] Armand Grillet Comparison of Container Schedulers Inf teacutec Technische
Universitaumlt Berlin[8] HashiCorp Consul documentation url httpswwwconsulio[9] HashiCorp Nomad documentation url httpsdcosio[10] Dan C Marinescu Cloud computing theory and practice Morgan Kauf-
mann 2013[11] Mesosphere DCOS documentation url httpswwwnomadproject
io[12] Microsoft Azure documentation url httpsazuremicrosoftcom
es-esdocumentation[13] D Ongaro y J Ousterhout In Search of an Understandable Consensus
Algorithm Inf teacutec Stanford University url httpsraftgithubioraftpdf
[14] Fei Teng laquoRessource allocation and schelduling models for cloud compu-tingraquo Tesis de mtriacutea Ecole Centrale Paris 2011
[15] A Williams y col Automation and Orchestration with Docker and Contai-ners A Comprehensive Overview of the Docker and Container Ecosystem3 The New Stack 2016
48
- Resumen
- Summary
- Iacutendice de figuras
- Introduccioacuten y objetivos
-
- Contexto
- Objetivos
- Estructura del documento
-
- Cloud Computing
- Nuevas cargas de trabajo
- Gestioacuten de recursos Planificadores
-
- Sistemas distribuidos
-
- Clasificacioacuten
-
- Herramientas
-
- DCOS
-
- Apache Mesos
- Ejemplos de uso
-
- Nomad
-
- Protocolo de consenso Raft
- Protocolo gossip SWIM
- Planificacioacuten
-
- Casos de uso y despliegue
-
- Aplicacioacuten Web
-
- DCOS
- Nomad
-
- Servicio de integracioacuten continua
-
- DevOps
- Integracioacuten Continua
- Jenkins con Nomad
- Jenkins con DCOS
-
- Escalando la infraestructura
-
- Disentildeo
- Implementacioacuten
-
- Resultados y conclusiones
-
- Comparacioacuten
- Conclusiones
- Objetivos conseguidos
- Liacuteneas de investigacioacuten
-
Summary
Tech-savvy companies have a large amount of computational resources tohandle the services that support the business process Typically tasks are al-located in these computers in a static way which is inefficient due to the factthat they are not distributed according to the workload besides involving fur-ther maintenance work Among the responsibilities of Information Technologyprofessionals is efficiently managing these resources and providing some guaran-tees of availability of those services according to the different capacity demands
The motivation of this project comes from the opportunity of efficiently dis-tributing the different tasks or services of an enterprise thanks to the evolutionof technologies such as virtualization distributed storage or software defined net-works but also with the improvement and cost reduction of the communicationlinks a potential turning point in the approach of designing IT infrastructures
This project goes into more detail on tools which pursue resource optim-ization availability scalability and fault tolerance of services Amongst theexisting solutions in the industry two open source projects have been chosenboth achieving the predefined objectives DCOS developed by the companyMesosphere and based on the Apache Mesos project and Nomad developed byHashiCorp
Firstly the internals of these two technologies will be studied followed by adeployment of use cases in both of them in the cloud Lastly the conclusionsreached comparing their performance will be described By this it is intendedto provide a perspective of the functionality of these tools and how they fit inthe nowadays perspective on Information Technology
Keywords Cluster Resource Manager Cluster Scheduler CloudComputing Apache Mesos HashiCorp Nomad Mesosphere DCOS
v
vi
Iacutendice
Resumen III
Summary V
Iacutendice de figuras IX
1 Introduccioacuten y objetivos 1
11 Contexto 1
12 Objetivos 2
13 Estructura del documento 2
2 Cloud Computing 3
3 Nuevas cargas de trabajo 5
4 Gestioacuten de recursos Planificadores 8
41 Sistemas distribuidos 8
411 Clasificacioacuten 10
5 Herramientas 13
51 DCOS 14
511 Apache Mesos 15
512 Ejemplos de uso 18
52 Nomad 19
521 Protocolo de consenso Raft 20
vii
522 Protocolo gossip SWIM 23
523 Planificacioacuten 24
6 Casos de uso y despliegue 27
61 Aplicacioacuten Web 27
611 DCOS 28
612 Nomad 33
62 Servicio de integracioacuten continua 40
621 DevOps 40
622 Integracioacuten Continua 40
623 Jenkins con Nomad 42
624 Jenkins con DCOS 42
7 Escalando la infraestructura 43
71 Disentildeo 43
72 Implementacioacuten 44
8 Resultados y conclusiones 45
81 Comparacioacuten 45
82 Conclusiones 46
83 Objetivos conseguidos 46
84 Liacuteneas de investigacioacuten 47
viii
Iacutendice de figuras
1 Comparacioacuten Centro de datos - Computacioacuten en la nube 4
2 Arquitectura Docker 6
3 Planificador monoliacutetico 11
4 Planificador de dos niveles 11
5 Planificador de estado compartido 12
6 Planificador distribuido 12
7 Arquitectura DCOS 14
8 Servicios DCOS 15
9 Arquitectura de Apache Mesos 17
10 Arquitectura multi-regioacuten en Nomad 20
11 Equipos sin consenso ejecutando el protocolo RAFT 21
12 Un equipo pasa a estado candidato (RAFT) 22
13 Cambio en un registro (RAFT) 22
14 Aprobacioacuten del resto de equipos (RAFT) 23
15 Diagrama de tiempo del protocolo SWIM 24
16 Procedimiento de asignacioacuten en Nomad 25
17 Arquitectura aplicacioacuten web 28
18 Infraestructura en Azure 29
19 Arquitectura de la aplicacioacuten web en DCOS 32
20 Despliegue en Azure de Nomad+Consul 35
ix
1 Introduccioacuten y objetivos
11 Contexto
Las tecnologiacuteas de la informacioacuten y la comunicacioacuten estaacuten suponiendo uncambio draacutestico en la sociedad en 2007 comenzaron a aparecer los teleacutefonosinteligentes tal y como los conocemos y nueves antildeos despueacutes se empieza a con-cebir la idea de dar conectividad a todo dispositivo electroacutenico movimiento queha tomado el nombre de Internet de las cosas Para hacerse una idea de la rapi-dez y magnitud de esta evolucioacuten la consultora Excelacom1 ha estimado que enun minuto se realizan 24 millones de buacutesquedas en Google o se ven 278 millonesde viacutedeos en Youtube En una eacutepoca en la que los recursos tecnoloacutegicos crecenexponencialmente y los usuarios demandan mayor contenido y movilidad nocabe duda que las empresas deben adaptarse lo maacutes raacutepidamente posible a esteproceso de digitalizacioacuten movidas por las nuevas necesidades de las personas
Dado el gran volumen de informacioacuten a lo largo de estos antildeos la compu-tacioacuten y el almacenamiento estaacuten pasando de clientes locales a concentrarse engrandes centros de datos una tendencia que Google ha denominado ldquoWarehouse-scale computingrdquo en 2009[1] Este movimiento hacia la computacioacuten desde ser-vidor no solo viene de la necesidad de mejorar la experiencia de los usuariossino tambieacuten de facilitar la gestioacuten y configuracioacuten de los recursos asiacute como laubicuidad de acceso que permite
En 2006 Amazon lanza Amazon Web Services siendo uno de los pionerosen el mercado de los recursos virtuales ofreciendo capacidad de computacioacutencon un coste proporcional exclusivamente a los recursos utilizados Todo ellocambioacute la perspectiva de los modelos tradicionales de TI a la conocida comocomputacioacuten en la nube recursos informaacuteticos que antes suponiacutean barrerasde entrada en ciertos mercados han pasado a ser condicioacuten necesaria para laconstante evolucioacuten de la tecnologiacutea y la sociedad De hecho Cisco estima quepara el antildeo 2019 maacutes del 86 de las cargas de trabajo seraacuten procesadas porcentros de datos en la nube2
1httpwwwexcelacomcomresourcesblog2016-update-what-happens-in-one-internet-minute2httpwwwciscocomcenussolutionscollateralservice-provider
global-cloud-index-gciCloud_Index_White_Paperpdf
1
12 Objetivos
El propoacutesito de este proyecto es estudiar la viabilidad del uso de planifica-dores de recursos para aumentar la eficiencia de eacutestos y facilitar al desarrolladorel despliegue de aplicaciones de forma distribuida y asiacute ofrecer un servicio ca-racterizado por una alta disponibilidad y escalabilidad
A lo largo de este trabajo se han usado algunas de las herramientas quese estaacuten comenzando a desarrollar para hacer frente a este nuevo enfoque degestioacuten de infraestructuras de las tecnologiacuteas de la informacioacuten (en adelanteinfraestructuras TI) realizando pruebas de concepto sobre cada una de ellas
13 Estructura del documento
A continuacioacuten se detalla las secciones que componen este trabajo La es-tructura queda como sigue
Cloud computing Se entra en detalle en este nuevo modelo de negocio queha originado nuevos enfoques y disentildeos de las infraestructuras TI dentrode las organizaciones
Nuevas cargas de trabajo Se explican algunas tecnologiacuteas representativasque estaacuten suponiendo un desafiacuteo para los profesionales de TI a la horade planificar los recursos y que se ven beneficiadas por entornos de tipocloud
Gestioacuten de recursos Planificadores Estado del arte de las tecnologiacuteas degestioacuten de clusters y planificacioacuten de recursos
Herramientas Descripcioacuten detallada del funcionamiento y arquitectura de lasherramientas usadas a lo largo del proyecto
Casos de uso y despliegue Se describe el proceso de implementacioacuten de unaaplicacioacuten web y un servicio de integracioacuten continua con el software pro-puesto
Escalando la infraestructura Se propone un procedimiento con cierta inde-pendencia del proveedor cloud
Resultados y conclusiones Resume las ideas y hechos a los que se ha llegadoademaacutes de introducir liacuteneas de investigacioacuten futuras
2
2 Cloud Computing
El NIST (National Insitute of Standards and Technology) define este con-cepto como un modelo que permite un acceso ubicuo y bajo demanda de formaremota a un conjunto compartido de recursos de computacioacuten que pueden seraprovisionados y liberados con unos miacutenimos esfuerzos de gestioacuten por parte delproveedor del servicio3
Clasificacioacuten
La computacioacuten en la nube abarca una amplia variedad de servicios y enfo-ques por lo que en primer lugar se va a dar una clasificacioacuten para posterior-mente entrar maacutes en detalle Existen distintos modelos de nube atendiendo a lagobernabilidad de la infraestructura seguacuten el NIST
Nubes puacuteblicas Los servicios y recursos son ofertados de forma puacuteblica yson provistos por una organizacioacuten que los comercializa bajo demanda
Nube privada Los recursos son gestionados por una uacutenica organizacioacutenpara su propio uso
Nube comunitaria En este caso la infraestructura es administrada por unconjunto de organizaciones con objetivos comunes
Nube hiacutebrida Una combinacioacuten de las anteriores
A su vez los distintos servicios que ofrece se pueden clasificar atendiendo algrado de control del usuario
Servicios de software (Software as a Service SaaS) El proveedor se encargade toda la gestioacuten de la infraestructura y oferta aplicaciones a las cuales elcliente puede acceder de forma ubicua a traveacutes de diversos clientes comoun navegador web Por ejemplo Office 365 o Google docs
Servicios de plataforma (Platform as a Service PaaS) Modelo de distribu-cioacuten que ofrece la capacidad de desplegar aplicaciones desarrolladas por elcliente usando las herramientas y lenguajes de programacioacuten soportadaspor el proveedor pero sin la posibilidad de gestionar los recursos consu-midos En este caso el cliente solo tiene control sobre la propia aplicacioacuteny algunas configuraciones del entorno Es el caso de Heroku o Google AppEngine
3httpnvlpubsnistgovnistpubsLegacySPnistspecialpublication800-145pdf
3
Servicios de infraestructura (Infrastructure as a Service IaaS) Se ofertanrecursos de computacioacuten puros como procesamiento o almacenamientomediante una plataforma de virtualizacioacuten El cliente puede controlar elsistema operativo componentes de red y aplicaciones
Figura 1 Comparacioacuten Centro de datos - Computacioacuten en la nubeFuente httpsad-hocnet
De entre las numerosas ventajas que ofrece la computacioacuten en la nube se puededestacar su flexibilidad ya que permite aprovisionar recursos y adaptarlos deacuerdo a la demanda reduce el capital inmovilizado y su amortizacioacuten laubicuidad que permite su consumo desde cualquier parte con conexioacuten a la redy la seguridad y fiabilidad que ofrece el proveedor que normalmente cuenta conrecursos geograacuteficamente distribuidos frente a la gestioacuten y mantenimiento derecursos propios
4
3 Nuevas cargas de trabajo
Las organizaciones que cuentan con sus propios infraestructuras TI han co-menzado a adoptar un enfoque de nube privada para gestionar las tareas ofunciones informaacuteticas sobre las que se sustentan el negocio ya que una es-tructura virtualizada puede ofrecer ventajas con respecto a las adaptaciones decentros de datos tradicionales en los aacutembitos de rendimiento escalabilidad eincluso seguridad4
A su vez se han desarrollado nuevas tecnologiacuteas que suponen cargas detrabajo dinaacutemicas y con gran intensidad de consumo de datos para las empresasque se ven beneficiadas al desplegarlas en recursos virtualizados
Big data
Con la creciente aceptacioacuten de las tecnologiacuteas TIC por parte de la sociedadla cantidad de datos generados en la red es ingente Las profesionales de TI tienecomo objetivo extraer valor de eacutestos para por ejemplo prever las tendencias delmercado Sin embargo este incremento exponencial hace que su procesamientoy almacenamiento requiera de un sistema con gran escalabilidad dado el hechode que una sola maacutequina no puede proveer de la capacidad necesaria
Integracioacuten continua
Modelo informaacutetico que consiste en hacer integraciones automaacuteticas de unproyecto con cualquier cambio en el coacutedigo con el objetivo de detectar fallosde forma temprana Esto implica la compilacioacuten del coacutedigo y su ejecucioacuten enun entorno de pruebas automaacuteticamente un proceso que mediante tecnologiacuteasde virtualizacioacuten permiten simular entornos con eficiencia y rapidez Su imple-mentacioacuten en sistemas distribuidos permite tanto una mejor planificacioacuten comoun mejor rendimiento de los recursos
Arquitectura de microservicios
Enfoque para desarrollar aplicaciones software como un conjunto de serviciosautoacutenomos que se comunican entre siacute a diferencia de aproximaciones monoliacuteti-cas donde la loacutegica del servicio estaacute desarrollada como una unidad Un sistemadistribuido permite el despliegue de los componentes en distintas maacutequinas loque mejora tanto su escalabilidad como la tolerancia a fallos
4httpswwwakamaicomesesresourcespublic-private-cloudjsp
5
Docker
Proyecto de coacutedigo abierto que facilita y automatiza el despliegue de aplica-ciones al encapsular el entorno de trabajo en contenedores Linux una tecnologiacuteaque permite a un sistema fiacutesico ejecutar muacuteltiples instancias de sistemas opera-tivos aislados mediante entornos virtuales con sus propios espacios de procesosy redes pero compartiendo el nuacutecleo (kernel) con el equipo anfitrioacuten
En la figura 2 se compara la pila de una virtualizacioacuten tradicional con res-pecto a los contenedores no se simula el sistema operativo por lo que el procesoes mucho maacutes ligero
Docker se caracteriza por
Autosuficiencia Los contenedores cuentan con las libreriacuteas y configuracio-nes necesarias para ejecutarse de manera autoacutenoma al compartir el nuacutecleo
Portabilidad El hecho de que sean autosuficientes implica que es inde-pendiente del host es decir se puede desplegar en cualquier equipo quesoporte esta tecnologiacutea
Tamantildeo El peso de un contenedor es sustancialmente inferior a otrastecnologiacuteas de virtualizacioacuten
Figura 2 Arquitectura DockerFuente httpsdockercom
6
Los componentes fundamentales de esta herramienta son
Imaacutegenes Describen el entorno de base sobre el que ejecutar el contene-dor por ejemplo la imagen del sistema operativo Ubuntu Sobre eacutesta seconstruyen las aplicaciones particulares del usuario dando lugar a otraimagen
Contenedores Se crean a partir de las imaacutegenes y comprenden todo aquellonecesario para arrancar la aplicacioacuten decir su entorno de ejecucioacuten
bull Voluacutemenes Encargados de gestionar la persistencia de datos e inde-pendientes del ciclo de vida del contenedor
Registros Pueden ser puacuteblicos o privados y almacenan las imaacutegenes elregistro puacuteblico oficial de Docker es Docker Hub
Dadas estas caracteriacutesticas los profesionales TI estaacuten comenzando a adoptarDocker ya que facilita tanto los despliegues como el trabajo compartido en dis-tintos entornos Sin embargo esto requiere de un software que permita desplegarlos distintos contenedores de forma que puedan trabajar en conjunto procesoque se ha denominado orquestacioacuten de contenedores
7
4 Gestioacuten de recursos Planificadores
Para sacar el maacuteximo provecho a las tecnologiacuteas anteriormente descritaslo ideal es desplegarlas en sistemas distribuidos sin embargo esto aumenta lacomplejidad del propio despliegue asiacute como la necesidad de software especiali-zado para ello Se necesitan algoritmos de planificacioacuten que permitan obtener elmaacuteximo rendimiento de los recursos por un lado y dar ciertas garantiacuteas de quetodas las tareas y procesos se van a ejecuta por otro
41 Sistemas distribuidos
En primer lugar se definen los sistemas distribuidos o clusters como unconjunto de ordenadores conectados entre siacute cuyo objetivo es trabajar como unauacutenica instancia de gran capacidad5
Su clasificacioacuten variacutea de acuerdo a cada autor pero en general se puedendividir seguacuten su objetivo en alto rendimiento aquellos cuyo objetivos es proveerde gran capacidad de coacutemputo gracias al conjunto de los nodos y alta disponi-bilidad con los cuales se busca la fiabilidad del sistema mediante redundanciayo balanceo de carga
El intereacutes de este proyecto recae en los uacuteltimos ya que el objetivo es porun lado ofrecer al desarrollador un entorno donde desplegar sus aplicaciones deforma distribuida y por otro maximizar el rendimiento de los recursos
De forma general las caracteriacutesticas que se buscan son las siguientes
Elasticidad Adaptacioacuten a cargas dinaacutemicas de trabajo aumentando (o dis-minuyendo) recursos de manera automaacutetica de tal forma que la utilizacioacutensea lo maacutes cercana a la demanda
Disponibilidad Capacidad de un sistema para mantener el servicio fun-cional
Tolerancia a fallos Recuperacioacuten del servicio ante el fallo de un compo-nente
Balanceo de carga Compartir las tareas entre las diferentes maacutequinasredundadas evitando asiacute puntos de uacutenico fallo
5httpsenwikipediaorgwikiComputer_cluster
8
Los programas que se implementan en entornos distribuidos se caracterizanpor ejecutarse de forma concurrente en equipos independientes estar conectadospor una red que introduce fallos aleatorios y no compartir memoria ni reloj Estoimplica entre otras cosas que
Los nodos soacutelo tienen un acceso raacutepido a su memoria local por lo quecualquier informacioacuten relativa al estado global puede ser potencialmenteerroacutenea
Las maacutequinas pueden sufrir caiacutedas de forma aleatoria
El intercambio de informacioacuten puede fallar ya sea por error en transmisioacuteno por caiacuteda de los nodos
Estas dificultades se ponen de manifiesto en el teorema de CAP en cienciasde la computacioacuten el teorema de CAP que lanzado inicialmente como conjetu-ra en el antildeo 2000 por Eric Brewer (motivo por el cual al teorema se le conoceformalmente como teorema de Brewer) y posteriormente demostrado en el antildeo20026 establece que es imposible para un sistema de coacutemputo distribuido ga-rantizar simultaacuteneamente dos de las tres propiedades siguientes
Consistencia (Consistency) es decir que todos los nodos vean la mismainformacioacuten al mismo tiempo Se busca que un cambio en el sistema soacutelose ejecute satisfactoriamente si y soacutelo si se efectuacutea a todos las maacutequinasde tal forma que los datos entre ellos nunca difieren y la respuesta a unapeticioacuten sea la misma independientemente del nodo que la atienda
Disponibilidad (Availability) esto es la garantiacutea de que toda peticioacuten debeobtener una respuesta (servicio funcional) aunque exista inconsistenciaentre nodos
Tolerancia al particionado (Partition Tolerance) es decir que el sistemasiga funcionado a pesar de un fallo en la comunicacioacuten entre los equipos
Por todo lo expresado anteriormente conseguir un sistema distribuido capazde ofrecer procesamiento de forma transparente implica una arquitectura TIcompleja Se requieren de subsistemas y herramientas que permitan la cohesioacutenentre todos los nodos
Gestor de los recursos de las diferentes maacutequinas
Monitorizacioacuten tanto de los servicios activos como de la funcionalidad delsistema ademaacutes de poliacuteticas para recuperacioacuten de fallo
Protocolos de consenso que permitan a los nodos ser consistentes con elestado global del cluster
6urlhttpsgroupscsailmitedutdspapersGilbertBrewer2pdf
9
Herramientas de descubrimiento de servicios que permita la comunicacioacutenentre tareas distribuidas
Planificadores Encargados de distribuir las tareas y procesos en las dife-rentes maacutequinas asignaacutendole parte de su capacidad
Los planificadores del ingleacutes cluster schedulers son un componente funda-mental por lo que vamos a entrar un poco maacutes en detalle en ellos
Planificadores (Cluster Schedulers)
Es el software encargado de monitorizar los recursos usados por cada maacute-quina perteneciente a un cluster y distribuir la carga de trabajo entre ellas deacuerdo a un poliacutetica o reglas
Este tipo de herramientas comparten cierta terminologiacutea que es relevantedefinir
Tarea Unidad de trabajo computacional comprendida por una secuenciade instrucciones datos de entrada y recursos asociados Por ejemplo laejecucioacuten de un comando o el arranque de una base de datos
Nodo Cualquier maacutequina integrante de un cluster En una arquitecturamaestro-esclavo se definen dos roles
bull Cliente Agente Esclavo Aquellos ordenadores que se encargan deejecutar las tareas
bull Maestro Servidor Su objetivo es mantener el estado del cluster ygestionar sus recursos
411 Clasificacioacuten
A lo largo de los uacuteltimos antildeos se han desarrollado diferentes tipos de plani-ficadores[2]
Monoliacutetico
Un solo planificador que se encarga de distribuir todas las tareas entran-tes La mayoriacutea de los planificadores en computacioacuten de alto rendimiento asiacutecomo Borg desarrollado por Google son de este tipo En la figura 3 se pue-de observar de forma graacutefica el procedimiento siendo las cajas grises maacutequinaspertenecientes al cluster y los ciacuterculos las tareas a asignar
10
Figura 3 Planificador monoliacuteticoFuente httpswwwclcamacuk
Planificacioacuten de dos niveles
La mayoriacutea de los clusters ejecutan aplicaciones con distintas necesidadesdesde procesos casi instantaacuteneos hasta servicios persistenteslo que implica dis-tintas necesidades de recursos
Por ello la planificacioacuten a dos niveles distingue dos funciones la gestioacutende recursos (gestor) y la disposicioacuten de las tareas (planificador) Cada serviciotiene su propio planificador de tal manera que el gestor les ldquoofertardquo recursosde acuerdo a una poliacutetica y los planificadores se encargan de escoger la maacutesadecuada Esto permite que el proceso de distribucioacuten sea maacutes acorde con lasnecesidades de los diferentes servicios Apache Mesos que detallaremos maacutesadelante sigue este esquema
Como desventaja cabriacutea sentildealar que esta programacioacuten implica que los pla-nificadores pierden la vista general de la infraestructura y las tareas soacutelo puedenejecutarse con los recursos que les son ofrecidos lo que dificulta la implementa-cioacuten de prioridades de ejecucioacuten de tareas entre otras
Figura 4 Planificador de dos niveles
11
Planificacioacuten de estado compartido
Muacuteltiples reacuteplicas del estado del cluster se actualizan independientementepara cada planificador como se observa en la figura 5 cuando sucede un cambiode forma local el planificador se encarga de informar al resto
Ejemplo de este tipo son Omega la evolucioacuten de Borg por parte de GoogleMicrosoft Apollo y Nomad que usaremos para los casos de uso
De entre las desventajas se puede destacar el hecho de que en general losnodos trabajan con informacioacuten desactualizada lo que conlleva una degradacioacutendel rendimiento en situaciones de alta contienda
Figura 5 Planificador de estado compartido
Planificacioacuten distribuida
En este caso no existe coordinacioacuten entre los distintos planificadores Cadauno de ellos funciona con su propia vista del cluster Las tareas pueden serorganizadas por cualquiera de ellos y desplegadas en cualquier parte del clusteren base a la aleatoriedad y multiplexacioacuten estadiacutestica de los flujos de trabajosin ninguacuten control central
Figura 6 Planificador distribuido
12
5 Herramientas
En la industria comienzan a aparecer soluciones software de coacutedigo abiertoque aglutinan los servicios necesarios para gestionar la infraestructura TI de ma-nera maacutes eficaz El objetivo es doble se busca facilitar la gestioacuten de los recursosde computacioacuten para organizaciones con instalaciones propias mediante su usocon un enfoque cloud esto es desplegar aplicaciones a traveacutes de un conjuntode ordenadores de forma transparente y sin tener en cuenta la infraestructurasubyacente o aprovechar el maacuteximo rendimiento de la infraestructura de losproveedores cloud puacuteblicos de forma que se tiene el maacuteximo control sobre eacutestapero no se depende de las soluciones propietarias permitiendo asiacute despliegueshiacutebridos
Entre estas herramientas se pueden destacar
OpenStack Proyecto desarrollado por la fundacioacuten del mismo nombre paraproporcionar servicios de infraestructuras (IaaS) basado en componentesque se comunican a traveacutes de APIs El componente Magnum incluye mo-tores de orquestacioacuten de contenedores
Kubernetes Sistema de orquestacioacuten de contenedores Docker creado por Goo-gle
CoreOs Sistema operativo basado en Linux disentildeado para despliegues distri-buidos sobre contenedores incluyendo mecanismos de descubrimiento deservicio y comparticioacuten de configuracioacuten
Docker Swarm Herramienta nativa de orquestacioacuten de contenedores Docker
YARN Entorno de gestioacuten de recursos y aplicaciones distribuidas de Hadoopuna libreriacutea software de procesamiento de grandes conjuntos de datos
Como podemos observar existe un gran rango de opciones para gestionar lainfraestructura desde un bajo nivel como puede ser OpenStack hasta Kuberne-tes o Docker Swarm que ofrecen exclusivamente orquestacioacuten de contenedores
En este trabajo se ha optado por Mesosphere DCOS y HashiCorp Nomadque se encuentran en el teacutermino medio su objetivo es proporcionar serviciosde plataforma que permitan la coexistencia dediferentes cargas de trabajo en elcluster
13
51 DCOS
DCOS es un proyecto de coacutedigo abierto7 creado y desarrollado por la empre-sa Mesosphere Se describe como un sistema operativo distribuido que abstraelos recursos de un cluster (capacidad de procesamiento memoria) permite lagestioacuten de muacuteltiples ordenadores de forma transparente y simplifica la instala-cioacuten de aplicaciones distribuidas
Su arquitectura se puede comparar a la de Linux en teacuterminos de nuacutecleo(kernel) y espacio de usuario El primero consta de recursos protegidos a losque no puede acceder el usuario e involucra operaciones de bajo nivel comoasignacioacuten de recursos o aislamiento de procesos En el espacio de usuario seejecutan las aplicaciones y servicios de maacutes alto nivel
Siguiendo con este siacutemil el nuacutecleo de DCOS estaacute basado en Apache Mesosque se explicaraacute en un apartado posterior y el espacio de usuario que estaacute com-prendido por los componentes del sistema esto es las diferentes herramientasque en conjunto conforman DCOS y los servicios encargados de planificar yejecutar las aplicaciones y tareas del usuario
Figura 7 Arquitectura DCOSFuente httpsdcosio
De entre los componentes que conforman DCOS destacan
Admin Router Balanceador de carga central basado en NGINX que dis-pone un proxy entre todos los servicios en el puerto 80 permitiendo sugestioacuten mediante la interfaz graacutefica Ademaacutes se encarga de la autenticacioacutenpara acceder al panel de administracioacuten
Cosmos Gestor de paquetes de las aplicaciones
Diagnostics Se ejecuta en todos los nodos y se encarga de monitorizar elestado de los daemons que sustentan DCOS
7Desde abril de 2016 httpsmesospherecomblog20160419open-source-dcos
14
Exhibitor Gestiona y automatiza el despliegue de ZooKeper la herra-mienta que provee de configuracioacuten centralizada y registro de nombres
Marathon Equivale al proceso init de los sistemas tipo Unix esto es elprimer proceso en ejecucioacuten tras la carga del kernel y que genera los demaacutesprocesos Se encarga de arrancar y monitorizar las aplicaciones y servicios
Mesos-DNS Servicio de DNS interno que define el dominio mesos pa-ra nodos y tareas en el cluster es decir permite resolver nombres conindependencia de la direccioacuten fiacutesica
Minuteman Balanceador de carga integrado a nivel TCPUDP disponiblepara las propias aplicaciones
Por otra parte se definen como servicios a las diferentes aplicaciones dis-tribuidas que DCOS permite instalar en el cluster y que pueden haber sidodesarrollados por la misma empresa Mesosphere o por terceros por ejemploApache Spark Jenkins o Apache Hadoop En la figura 8 se muestra un diagramade los servicios disponibles incluyendo algunos de las aplicaciones distribuidasque soporta DCOS
Figura 8 Servicios DCOSFuente httpsdcosio
511 Apache Mesos
El nuacutecleo de DCOS estaacute basado en Apache Mesos un proyecto de coacutedigoabierto creado por la Universidad de California Berkeley y desarrollado actual-mente por la fundacioacuten Apache Se trata de un administrador de clusters queabstrae los recursos y los dispone para diferentes aplicaciones y entornos de tra-bajo distribuidos (frameworks) mediante una interfaz comuacuten En el momento deredaccioacuten de este proyecto Apache Mesos soportaba una variedad de entornosque abarcaba desde Big Data (Apache Spark Hadoop) hasta bases de datos(Cassandra Hypertable)
15
Arquitectura
Mesos se basa en la asignacioacuten de dos roles diferentes a los nodos
Maestros (Masters) Se encargan de la gestioacuten y reparticioacuten de los recursospara los diferentes entornos de trabajo mediante ldquoofertas de recursosrdquo deacuerdo a los disponibles y a la poliacutetica de asignacioacuten (planificacioacuten en dosniveles)
Esclavos (Slaves) Ordenadores donde se ejecutaraacuten las aplicaciones y cu-yos recursos son ofertados por los maestros
En el caso de fallo del maestro las tareas pueden seguir ejecutaacutendose perono se podraacute asignar nuevos recursos ni tareas por ello pueden existir varios enel cluster para configuraciones de alta disponibilidad pero soacutelo uno orquesta alos esclavos
Para la eleccioacuten del master liacuteder Mesos usa Apache ZooKeeper un proyectode software desarrollado por la misma fundacioacuten cuyo objetivo es proveer deun servicio de configuracioacuten centralizado y registro de nombres8
Por otra parte los entornos de trabajo son los programas que deciden final-mente queacute recursos se van a usar y se encargan de que los esclavos ejecuten lastareas Eacutestos se ejecutan sobre Mesos y constan de dos componentes
Planificador (Scheduler) Optimiza y decide los recursos a utilizar de losofertados informando a los Masters
Procesador (Executor) Ejecuta las aplicaciones o servicios en los esclavos
El objetivo final es conseguir una interfaz liviana tolerante a fallos paracualquier tipo de entorno de trabajo de tal manera que en los esclavos del clusterpuedan ejecutarse simultaacuteneamente tareas con necesidades y duracioacuten diferentesPara ello se basa en dos conceptos asignacioacuten y aislamiento de recursos
Asignacioacuten de recursos
En el cluster pueden coexistir entornos de trabajo con tareas de larga dura-cioacuten y con gran consumo de recursos con tareas cortas que los ocupan y liberancon rapidez El maestro integra un moacutedulo de asignacioacuten de recursos (allocationmodule) que se encarga del algoritmo de distribucioacuten
En el momento de escribir este proyecto estaban desarrollados dos moacutedulosuno mediante el cual el usuario puede asignar prioridades y otro que implementa
8httpszookeeperapacheorg
16
el algoritmo Dominant Resource Fairness9 a grandes rasgos se determina entodos los esclavos la tarea en ejecucioacuten que necesita maacutes recursos y se calcula laproporcioacuten del recurso de mayor peso con respecto al total por ejemplo si unatarea ocupa 2 GB de memoria con respecto a 10 GB totales que tiene el clusterse le asigna un dominant share del 20 la tarea se asignaraacute al nodo con menordominant share
Aislamiento de recursos
Para conseguir que tareas de diferentes entornos de trabajo y con distin-ta naturaleza se ejecuten simultaacuteneamente en un mismo nodo Mesos usa loscontenedores Linux (descritos en la seccioacuten 3)
Funcionamiento
La figura 9 muestra el esquema de la arquitectura de Apache Mesos conalta disponibilidad (tres maestros) y con dos entornos de trabajo ejecutaacutendo-se Hadoop que permite el almacenamiento y procesamiento de gran cantidadde datos para proyectos de big data y un sistema que implementa la interfazsistema de paso de mensajes MPI
Como se puede observar el sistema ZooKeeper elige a un solo maestro comoliacuteder y eacuteste orquesta el cluster comunicando los esclavos con los planificadoresde los diferentes entornos de trabajo Tambieacuten se puede observar como las tareasde los distintos entornos estaacuten distribuidas entre los tres esclavos disponibles
Figura 9 Arquitectura de Apache MesosFuente httpsmesosapacheorg
El proceso de asignacioacuten se realiza como sigue en primer lugar un usuariosolicita la ejecucioacuten de una tarea mediante la interfaz de cada entorno de traba-jo (interfaz graacutefica API HTTP ) De forma paralela un esclavo informa almaestro de los recursos que tiene libres En consecuencia eacuteste se lo notifica almoacutedulo de asignacioacuten que en funcioacuten de su configuracioacuten decide cuaacutento ofertar
9httpspeopleeecsberkeleyedu~aligpapersdrfpdf
17
y a queacute entorno de trabajo y enviacutea la oferta a los planificadores Eacutestos respondenal maestro con queacute recursos ha decidido usar para cada tarea Finalmente lastareas son enviadas al esclavo seleccionado el cual asigna los recursos indicadosal procesador (executor) quien finalmente las ejecuta
Cabriacutea pensar que esta metodologiacutea puede conducir a situaciones en lasque un entorno podriacutea quedarse con tareas sin ejecutarse a la espera de unaoferta satisfactoria para ello Mesos implementa un sistema de filtros medianteel cual los entornos especifican los requisitos miacutenimos que debe cumplir unaoferta por ejemplo se puede especificar en queacute nodos debe desplegarse la tareaEste sistema estaacute disentildeado asiacute con el objetivo de mantener lo maacutes transparenteposible esta herramientas de forma que acepte entornos de trabajo de distintasnaturalezas
512 Ejemplos de uso
Grandes empresas estaacuten usando Apache Mesos con eficacia de acuerdo a susnecesidades e infraestructuras Caben destacar
Ebay En el modelo de implementacioacuten continua en esta empresa10 cadadesarrollador cuenta con su propia instancia que se ejecuta en una maacutequinavirtual dedicada lo que ha conllevado un uso de los recursos poco eficiente Enuna prueba de concepto consiguieron realizar una herramienta de integracioacutencontinua distribuida basada en un cluster con Apache mesos y con el entornoMarathon y Jenkins
Apple Anuncioacute que el motor de su famosa herramienta de asistencia per-sonal para iPhones Siri estaacute desplegada sobre Apache Mesos11 Para ello handesarrollado su propio entorno para facilitar a los ingenieros a desplegar los ser-vicios que la herramienta necesita para resolver las peticiones de los usuarios
Twitter Desarrolloacute su propio entorno denominado Aurora y actualmentegestionan sus recursos y miden el coste de las tareas que los empleados usancon el objetivo de que sean conscientes del gasto que puede suponer un usoinadecuado de la infraestructura12
10httpwwwebaytechblogcom20140404delivering-ebays-ci-solution-with-apache-mesos-part-i11httpwwwbusinessinsidercomapple-siri-uses-apache-mesos-2015-812httpswwwlinuxcomNEWS4-UNIQUE-WAYS-UBER-TWITTER-PAYPAL-AND-HUBSPOT-USE-APACHE-MESOS
18
52 Nomad
Herramienta de coacutedigo abierto de gestioacuten de clusters creada y desarrolladapor Hashicorp13 que permite el despliegue de aplicaciones y procesos de formadistribuida
Las principales diferencias con Apache Mesos a grandes rasgos son
Arquitectura maacutes ligera Nomad soacutelo requiere de un fichero para funcionarejecutaacutendolo con las correspondientes configuraciones en todos los nodosrealiza las funciones de gestioacuten del cluster eleccioacuten de liacuteder planificacioacutende recursos y ejecucioacuten de las tareas
Centro de datos y regiones muacuteltiples Su arquitectura estaacute orientada afacilitar la gestioacuten de diferentes centros de datos geograacuteficamente distri-buidos
Entorno de ejecucioacuten Las tareas se definen y son interpretadas mediantecontroladores integrados en Nomad que se valen de los recursos y herra-mientas de los nodos clientes para ejecutarlas Esta integracioacuten dificultael desarrollo de controladores por parte de terceros a diferencia de Mesosque delega dicha responsabilidad en los entornos de trabajo externos alproyecto
Usa un planificador de estado compartido con respecto a la planificacioacutenen dos niveles de Mesos
Antes de entrar en maacutes detalle en la arquitectura es importante definir lossiguientes teacuterminos
Controlador (Driver) Software que se encarga de interpretar las definicionesde las tareas y ejecutarlas semejante a los procesadores de los entornosde trabajo de Mesos A la hora de redactar este proyecto Nomad contabacon controladores para contenedores Docker virtualizacioacuten de maacutequinasmediante el emulador QEMU aplicaciones java y archivos binarios
Grupo de trabajo (Task Group) Conjunto de tareas que se ejecutan en elmismo nodo cliente
Trabajo (Job) Conjunto loacutegico de tareas y grupos de trabajo que se despliegana la vez
Asignacioacuten (Allocation) Relacioacuten entre un grupo de trabajo y el cliente don-de se ejecuta
Evaluacioacuten (Evaluation) Proceso mediante el cual Nomad planifica y ges-tiona el registro o actualizaciones de los trabajos
13httpswwwhashicorpcom
19
Nomad sigue una arquitectura maestro-esclavo similar a la de Apache Mesosmuacuteltiples servidores acuerdan entre siacute un liacuteder que gestiona la planificacioacuten detareas en los clientes que soacutelo conocen sus asignaciones y las ejecutan
Todos los servidores participan paralelamente en tareas de planificacioacuten derecursos y asignacioacuten de tareas y ademaacutes entre ellos eligen un liacuteder que seencarga de la coordinacioacuten de la suscripcioacuten de los clientes al cluster y de lagestioacuten de las peticiones
Los clientes estaacuten configurados para comunicarse con el servidor usando lla-madas a procedimiento remoto (RPC por sus siglas en ingleacutes) que permite unordenador ejecutar coacutedigo en otra maacutequina Mediante esta tecnologiacutea los nodosclientes avisan de su estado e informa de sus asignaciones recursos y controla-dores disponibles
Existe la posibilidad de gestionar varios centros de datos agrupados en regio-nes eacutestas son independientes pero permite definir tareas o comprobar el estadode todas ellas desde cualquier punto A continuacioacuten se muestra una figura dela arquitectura a alto nivel de esta configuracioacuten
Figura 10 Arquitectura multi-regioacuten en NomadFuente httpswwwnomadprojectio
La herramienta se sustenta sobre tres protocolos fundamentales un protocolode consenso entre los servidores para compartir informacioacuten sobre su estado yel liacuteder un protocolo Gossip para la gestioacuten entre regiones y el planificador detareas
521 Protocolo de consenso Raft
El objetivo es obtener consistencia en un conjunto de nodos que comparteninformacioacuten es decir si un cliente realiza un cambio que todos los nodos veanla misma informacioacuten a la vez y ademaacutes sea tolerante a fallos Para ello se basaen el algoritmo Raft[13] que se detalla brevemente a continuacioacuten
20
Los nodos participantes en el algoritmo pueden estar en tres estados
Liacuteder (Leader) Todos los cambios que realicen en el cluster pasan por eacutel pri-mero
Seguidor (Follower) Nodo pasivo cuya responsabilidad es responder a laspeticiones del nodo liacuteder
Candidato (Candidate) Maacutequina que no ha encontrado liacuteder y solicita sueleccioacuten
Supongamos que tenemos cinco equipos que acaban de arrancar el protocoloEn la figura 11 se observan los nodos y sus respectivos registros a la derecha
Figura 11 Equipos sin consenso ejecutando el protocolo RAFTFuente httpsgithubcomongardieraftscope
Al comenzar todos los nodos son seguidores esperando recibir comunicacioacutende un nodo que actuacutee como liacuteder Cada nodo tiene un tiempo de espera aleatoriodespueacutes del cual si no es informado por un liacuteder pasa a estado candidato y pideel ldquovotordquo al resto de los participantes El algoritmo divide el tiempo en plazos uncandidato pasa a liacuteder si recibe la mayoriacutea de los votos en un plazo determinadoSe define mayoriacutea o cuoacuterum (quorum) comolceil
N2rceil
+ 1 (1)
donde N representa el nuacutemero de nodos
Para el ejemplo propuesto de 5 equipos se requieren de 3 votos Soacutelo losnodos que se encuentren en estado seguidor pueden votar una uacutenica vez a laprimera solicitud que reciba dentro de un plazo
Supoacutengase que el nodo denotado con S1 ha cumplido su tiempo de espera yrealiza la peticioacuten de voto (figura 12) A partir de este momento se pueden dartres casos
La maacutequina gana la eleccioacuten y pasa a ser liacuteder informando al resto
Otro servidor se establece como liacuteder en el mismo momento
Varios nodos pasan a ser candidatos por lo que ninguno consigue los votos
21
Figura 12 Un equipo pasa a estado candidato (RAFT)
Si un candidato recibe un aviso de un liacuteder en el mismo plazo el primeropasa a ser seguidor y se acaba la eleccioacuten de liacuteder
Por otro lado si un equipo candidato no recibe los votos en el plazo y agotasu tiempo de espera avanza al siguiente plazo y repite el proceso de votacioacutenLa tercera posibilidad puede conllevar a un estado indefinido ya que varioscandidatos pueden agotar su tiempo de espera al mismo tiempo y repartir losvotos Para solventarlo el algoritmo establece tiempos de espera aleatorios paralos candidatos
Siguiendo con el ejemplo propuesto el servidor S1 pasa a ser el liacuteder Cadacierto tiempo eacuteste debe realizar avisos a los nodos seguidores para no agotar sutiempo de espera
En este momento el cluster de servidores estaacute en ldquoconsensordquo y la informacioacutenen todos los nodos estaacute actualizada Un cambio en la informacioacuten inicia unproceso de replicacioacuten el liacuteder registra el cambio lo pasa al resto de nodos yuna vez eacutestos responden el cambio se hace efectivo
Supoacutengase que se realiza un cambio en los datos en la figura 13 en la partederecha se observa el cambio en el registro del servidor S1 que informa a losnodos seguidores En consecuencia los nodos registran el cambio y responden aS1
Figura 13 Cambio en un registro (RAFT)
Una vez el cuoacuterum (en el ejemplo tres equipos) informa al liacuteder de que
22
ha registrado el cambio el liacuteder lo hace efectivo en su sistema y notifica a losnodos que hacen lo mismo En la figura 14 el enviacuteo todaviacutea no ha llegado ala maacutequina S3 y se observa que no ha hecho efectivo el cambio (en el registroaparece punteado)
Figura 14 Aprobacioacuten del resto de equipos (RAFT)
Este protocolo funcionaraacute correctamente mientras exista un nuacutemero de nodosen funcionamiento igual o superior al cuoacuterum en el ejemplo propuesto elcuoacuterum es tres por lo que el sistema puede tolerar la caiacuteda de dos de los equipos
522 Protocolo gossip SWIM
Nomad permite la gestioacuten simultaacutenea de varios centros de datos reparti-dos en regiones geograacuteficamente separadas requiriendo de un protocolo ligeroque mantenga a los miembros actualizados sobre los participantes del conjun-to Para ello usa una ligera variante del protocolo SWIM[3] (Scalable Weakly-consistent Infection-style Process Group Membership Protocol) desarrollada porHashiCorp Estaacute clasificado como un protocolo de tipo gossip que debe su nom-bre a la semejanza con coacutemo se distribuye un rumor en una red social
SWIM se sustenta en dos caracteriacutesticas fundamentales la deteccioacuten de fallosy la distribucioacuten de la informacioacuten relativa a los miembros A continuacioacuten sedetalla el funcionamiento de ambos componentes
Deteccioacuten de fallos
Este componente tiene dos paraacutemetros el periodo de protocolo T y el nuacutemerode subgrupos de deteccioacuten de fallos k en los que se dividen los nodos Paracomprobar la comunicacioacuten entre dos maacutequinas usa la utilidad ping basadaen el protocolo ICMP La deteccioacuten de caiacuteda de un servidor sigue el siguientealgoritmo
Durante el periodo T cada miembro Mi de un subgrupo elige otro al azar Mjdel mismo subgrupo y le enviacutea un mensaje ping para comprobar su estado Enel caso de que se cumpla un tiempo de espera determinado por una estimacioacuten
23
del tiempo de ida y vuelta (RTT por sus siglas en ingleacutes) de la red y no hayarespuesta Mi le vuelve a enviar un mensaje ping indirectamente a traveacutes deun nuacutemero k de miembros escogidos aleatoriamente De no recibir ninguna res-puesta Mi establece que Mj ha sufrido un fallo y lo etiqueta como ldquosospechosordquoinformando al componente de distribucioacuten
Figura 15 Diagrama de tiempo del protocolo SWIMFuente httpswwwcscornelledu
Componente de distribucioacuten
Se encarga de informar de cualquier cambio en los miembros a todo el con-junto Los eventos de nodo caiacutedo y la unioacuten o disociacioacuten de un miembro setransmiten a todos los servidores para que actualicen sus lista Para distribuirla informacioacuten a todos los nodos se podriacutea usar el meacutetodo de multicast perosuele estar deshabilitado Por ello se utiliza una teacutecnica de transmisioacuten denomi-nada Piggybacking mediante la cual se adjunta a los propios mensajes PINGy ACK del algoritmo la informacioacuten a distribuir reduciendo asiacute la congestioacutenen la red
523 Planificacioacuten
Proceso encargado de distribuir las tareas entre los nodos clientes de acuerdoa su estado
El planificador de Nomad estaacute basado en las publicaciones de Google sobresus herramientas de gestioacuten de clusters Borg y Omega14 y entiende los trabajosdescritos por el usuario como un estado deseado es decir su despliegue en unamaacutequina cliente de forma correcta y los clientes como el estado actual esto eslo que se encuentra en ejecucioacuten El registro actualizacioacuten o cancelacioacuten de un
14httpresearchgooglecompubspub43438html
24
trabajo asiacute como el fallo de un nodo cliente implican un cambio de estado atramitar por el sistema lo que se define como evaluacioacuten (evaluation) Esto uacutelti-mo supone comparar el estado actual (clientes) con el estado deseado (conjuntode trabajos registrados) y enviarlos a los planificadores correspondientes que seencargaraacuten de asignar las tareas a los nodos clientes
Figura 16 Procedimiento de asignacioacuten en NomadFuente httpswwwnomadprojectio
En la figura 16 se observa el flujo de trabajo en el que las distintas evalua-ciones se encolan en el evaluation broker que se ejecuta en el servidor liacuteder ygestiona las evaluaciones pendientes asignaacutendoles prioridades
A continuacioacuten los nodos servidores ejecutan los scheduling workers queprocesan las evaluaciones llamando a los distintos planificadores que generanun plan de asignacioacuten esto es un conjunto de relaciones entre las tareas y losnodos clientes donde se ejecutaraacuten Este proceso se divide en dos fases primerose descartan aquellos clientes que no cumplan los requisitos y posteriormentese asigna una calificacioacuten al resto Se selecciona el nodo con mayor puntuacioacuteny se encola el plan en el gestor que se ejecuta en el servidor liacuteder Existen tresplanificadores de acuerdo al tipo de trabajo
Service Incluye aquellos trabajos que estaacuten destinados a ejecutarse en un pe-riacuteodo largo de tiempo Para realizar las asignaciones el planificador evaluacuteala mayor parte de los nodos y usa una versioacuten del algoritmo Best fit in-fluenciada por el trabajo de Google en su herramienta Borg Se trata deun algoritmo de planificacioacuten que sacrifica tiempo a cambio de maximizarel rendimiento de los clientes asignando la tarea a la maacutequina que tengala mayor carga de trabajo con el objetivo de reducir equipos en funciona-
25
miento
Batch Tareas que incluyen listas de comandos en general de menor duracioacuteny que no requieren interaccioacuten con el usuario Se vale del algoritmo deSparrow desarrollado por la universidad de Berkeley15 para limitar losnodos clientes a evaluar
System Trabajos destinados a ejecutarse en todos los nodos incluso los que seunen al cluster posteriormente
Core Mantenimiento interno de Nomad
Una vez se ha realizado el proceso de planificacioacuten el nodo liacuteder lo registra enla cola de planes (plan queue) que se encarga de asignarles prioridad y manejarcondiciones de carrera es decir que no accedan a los recursos de los clientes sincontrol y evitar que eacutestos superen su capacidad
La maacutequina liacuteder del conjunto puede de este modo aceptar una asignacioacuteny ser ejecutada por los clientes o por el contrario rechazaacutersela al planificadorlo que implicariacutea realizar un plan parcial o totalmente nuevo
Finalmente el estado de las evaluaciones se actualizan y los clientes soninformados de las asignaciones ejecutaacutendose las tareas
15httppeopleeecsberkeleyedu~keopublicationssosp13-final17pdf
26
6 Casos de uso y despliegue
Con el objetivo de mostrar las posibles utilidades que este tipo de sistemaspueden tener en las infraestructuras TI actuales se han desplegado las dos he-rramientas en la nube Microsoft Azure usando su servicio cloud de instancias demaacutequinas virtuales Linux para simular un conjunto de ordenadores conectadosentre siacute por una red LAN Sobre ellas se ha implementado dos casos de usouna aplicacioacuten web con una arquitectura con cierta orientacioacuten a microserviciosy un sistema de integracioacuten continua
El coacutedigo y todos los ficheros de configuracioacuten se pueden encontrar en elrepositorio del proyecto en GitHub16
61 Aplicacioacuten Web
Se busca simular el proceso de adaptacioacuten de una solucioacuten web para su des-pliegue en un sistema distribuido con las herramientas anteriormente descritascon el objetivo de aumentar tanto su escalabilidad como disponibilidad medianteredundancia
Se ha partido de una aplicacioacuten ya existente17 un servicio de almacenamien-to y reproduccioacuten de canciones A grandes rasgos este servicio permite crearusuarios subir canciones con sus respectivas portadas tener playlists propias yescuchar las canciones a traveacutes de un navegador web
La solucioacuten estaacute dividida en 4 partes (figura 17)
Una vista web con la loacutegica
Un almacenamiento conectado en red (NAS por sus siglas en ingleacutes)
Una API REST para gestionar las peticiones al almacenamiento
Base de datos NoSQL basada en MongoDB
La nueva tendencia de los proyectos web es su implementacioacuten en contene-dores Docker ya que facilitan su portabilidad y ofrecen un procedimiento dedespliegue raacutepido sobre todo a la hora de desarrollar y realizar pruebas en en-tornos de produccioacuten simulados Por ello en este caso se va a hacer uso de los
16httpsgithubcomAntonioAlfrzCloud-Orchestrators17httpsgithubcomsonsoleslpCDPSfy
27
motores de orquestacioacuten de contenedores de ambas herramientas Marathon enDCOS y el controlador Docker en el caso de Nomad
Figura 17 Arquitectura aplicacioacuten web
A continuacioacuten vamos detallar el despliegue en ambas herramientas de es-ta solucioacuten y observar tanto queacute dificultades se encuentran como que ventajasofrecen El objetivo final es adaptar el proyecto modificaacutendolo lo menos posiblecon objeto de analizar la capacidad de estas herramientas para desplegar cual-quier aplicacioacuten sin que eso conlleve la modificacioacuten de la arquitectura de eacutestaes decir que no sea dependiente del entorno
611 DCOS
Se ha descrito DCOS como una herramienta que se despliega sobre un con-junto de ordenadores y que permite instalar gestionar el despliegue de sistemasdistribuidos
Microsoft Azure cuenta con una plantilla para desplegar en su servicio cloudun cluster de maacutequinas virtuales con DCOS ya instalado que cuenta con
Maacutequinas maestras (1 3 o 5 a seleccionar por el usuario) configuradascomo un conjunto de disponibilidad esto eso Azure da ciertas garantiacuteasde que al menos una maacutequina estaraacute en funcionamiento
Maacutequinas agentes Por motivos de seguridad se distinguen dos roles
bull Nodos privados solo accesibles desde la red interna y configuradoscomo un conjunto de escala un recurso de Azure para gestionar ydesplegar maacutequinas con configuraciones ideacutenticas para permitir unraacutepido escalado
bull Un equipo conectado accesible desde Internet a travntildees de un balan-ceador de carga puacuteblico y situado en una subred externa
28
Dos balanceadores de carga
bull La interfaz puacuteblica del cluster que se conecta con el cliente puacuteblicobull Acceso a los equipos maestros para el administrador que soacutelo permiteconexioacuten mediante SSH y credenciales
Almacenamiento para todas las maacutequinas
Configuraciones necesarias de red y seguridad
En la figura 18 se observa un diagrama de la infraestructura
Figura 18 Infraestructura en Azure
El primer obstaacuteculo es la persistencia de estado de la aplicacioacuten que seconsigue gracias a una base de datos no relacional basada en MongoDB asiacutecomo el almacenamiento de las canciones Para implementarla tenemos variasposibilidades
Montar un sistema externo de almacenamiento conectado en red en todoslos agentes donde se ejecuten las tareas de esta manera si una tarea pasade un nodo a otro por cualquier motivo puede tener acceso a los mismosficheros (opcioacuten del caso de uso original)
Implementar un sistema de ficheros distribuidos en los agentes
Usar los servicios de almacenamiento de las nubes puacuteblicas
Aprovechar el sistema de voluacutemenes persistentes de Apache Mesos Eacutestepermite reservar recursos de un agente de forma que al arrancar una tarease crea un volumen independiente del ciclo de vida de eacutesta con ello esosrecursos donde se ha almacenado la informacioacuten pueden volver a ofrecerseal mismo entorno de tal manera que otra tarea pueda acceder a ella
DCOS aprovecha este sistema de voluacutemenes persistentes y permite instalarbases de datos distribuidas como ArangoDB o Apache Cassandra sin embargoesto implicariacutea modificar todo el coacutedigo referente al modelo de la base de datos
29
Por motivos de eficiencia y latencia asiacute como de una mayor gobernabilidadde los datos la mejor opcioacuten es usar el recurso de voluacutemenes persistentes queofrece Apache Mesos ya que de esta manera se gestionariacutea la aplicacioacuten completamediante una uacutenica herramienta Sin embargo esto implica que la informacioacutense encuentra exclusivamente en el agente donde se haya ejecutado la tarea y porlo tanto se sigue requiriendo de software externo para distribuir la informacioacutenpara que se accesible para todos los agentes A la hora de realizar este proyectose encontraba en desarrollo Flocker una solucioacuten desarrollada por ClusterHQque permite compartir los voluacutemenes de Docker a traveacutes de un cluster quesi bien es compatible con el planificador de Mesos el proyecto se encontrabatodaviacutea en fases tempranas de desarrollo y los sistemas de almacenamiento quesoporta quedaban fuera del aacutembito de este trabajo
Por todo ello dado que las maacutequinas se han desplegado en la nube puacuteblicade Azure se decidioacute usar su servicio de almacenamiento de objetos para lascanciones y otra maacutequina para desplegar MongoDB y asiacute mantener el modelode datos original de la aplicacioacuten La diferencia del almacenamiento de obje-tos con respecto a nivel de fichero es que el primero no tiene jerarquiacutea paraorganizar los archivos eacutestos se guardan como objetos (con sus metadatos) enun mismo espacio soacutelo diferenciaacutendose por un identificador uacutenico esto implicaentre otras cosas que se puede acceder a un fichero dado uacutenicamente su IDindependientemente de la localizacioacuten fiacutesica de eacuteste facilitando pues la gestioacuteny el desarrollo
El coacutedigo del proyecto se ha modificado en los siguientes apartados
Las direcciones de la base de datos y los balanceadores de carga asiacute comosus puertos estaban originalmente fijos Se han configurado como variablesde entorno para facilitar el descubrimiento del servicio y hacer transpa-rente la aplicacioacuten al entorno de despliegue
La API REST se ha adaptado al almacenamiento en Azure en vez de enlocal
Estas modificaciones no suponen un cambio sustancial pero permiten separala persistencia de las tareas ejecutadas por DCOS lo que facilita en granmedida su ejecucioacuten al ser totalmente sin estado y ademaacutes implican tenerlos datos bajo un mayor control
Para la orquestacioacuten de contenedores se va a usar el entorno Marathondesarrollado tambieacuten por Mesosphere Eacuteste se puede usar a traveacutes de una interfazgraacutefica la interfaz de liacutenea de comandos (en lo que sigue CLI por sus siglas eningleacutes) de DCOS o con su API HTTP
Primero se han publicado la imaacutegenes de los contenedores que encapsulanla interfaz web y la api de la aplicacioacuten en el repositorio puacuteblico DockerHub
Los despliegues en este entorno se describen mediante ficheros JSON en losque se detalla entre otras opciones la imagen del contenedor los puertos a usar
30
los recursos que debe ocupar en un nodo o las instrucciones de monitorizacioacuten
Para el servicio de descubrimiento DCOS ofrece la posibilidad de asignardirecciones IP virtuales (VIP por sus siglas en ingleacutes) a tareas que se compartenen todos los nodos DCOS lleva integrado un balanceador de carga a nivel TCP(el componente denominado Minuteman) que balancea entre las direccionesvirtuales de las tareas y todas las instancias de eacutestas a lo largo del cluster Estoes necesario por dos motivos equilibrar la carga de los equipos con el fin deevitar un punto de uacutenico fallo mediante redundancia y evitar la contienda dedirecciones al ejecutar las tareas en puertos aleatorios
Este balanceador de carga estaacute basado en el trabajo de Michael Mitzenma-cher The Power of Two Choices in Randomized Load Balancing18 A grandesrasgos el algoritmo mantiene una media moacutevil exponencial de latencias paracada destino (backend) ademaacutes de las caiacutedas consecutivas Si un destino noresponde a una negociacioacuten en tres pasos (three way handshake) de forma con-secutiva en un periodo inferior a 5 ms se considera caiacutedo El algoritmo iterasobre los destinos disponibles en base a su histoacuterico de fallos y escoge dos deforma aleatoria de los cuales coge el de mejor meacutetrica
Las direcciones virtuales soacutelo se pueden resolver dentro del cluster porello para implementar la interfaz puacuteblica de la aplicacioacuten esto es el balancea-dor de carga de la interfaz web usaremos un paquete de DCOS denominadomarathon-lb un balanceador basado en HAProxy y adaptado por MesosphereEn este caso equilibra la carga de todas instancias de las tareas ejecutadas porel entorno Marathon por sus etiquetas y permite ademaacutes definir como puntode entrada muacuteltiples hosts virtuales definidos por sus nombres completos dedominio (FQDN por sus siglas en ingleacutes) en nuestro caso la interfaz puacuteblicadel balanceador de Azure para los agentes
Por motivos de seguridad todas las tareas se ejecutan en los agentes privadoses decir los que son exclusivamente accesibles desde la red interna Por su partemarathon-lb se ejecuta en el agente puacuteblico que cuenta con IP puacuteblica y lospuertos 80 (HTTP) y 8080 abiertos de forma que la aplicacioacuten sea accesibledesde Internet Esto es posible debido a que Apache Mesos permite reservarrecursos mediante roles asignados a nodos para un uso especiacutefico De esta formala arquitectura vista desde la aplicacioacuten quedariacutea como en la figura 19
18httpswwweecsharvardedu~michaelmpostscriptstpds2001pdf
31
Figura 19 Arquitectura de la aplicacioacuten web en DCOS
Ejecucioacuten
A la hora de desplegar la aplicacioacuten DCOS puede gestionarse medianteuna interfaz graacutefica o una interfaz de liacutenea de comandos La primera se accedea traveacutes de un navegador web en el puerto 80 (HTTP) y permite instalar losentornos disponibles observar el estado de los nodos y las tareas que se estaacutenejecutando y los ficheros de registros que eacutestas generan
La CLI permite el control desde un nodo o una maacutequina remota (suponiendoque los maestros tienen IP puacuteblica y el puerto 80 abierto) ya que DCOS tieneun sistema de autorizacioacuten que permite tener una interfaz puacuteblica con ciertasgarantiacuteas de seguridad
Por su parte cada entorno de trabajo puede ser controlado por la CLI peroademaacutes cuenta con sus propias interfaces Marathon expone una API HTTPen el puerto 8080 de la direccioacuten puacuteblica de los maestros del cluster asiacute comootra interfaz graacutefica Para desplegar un contenedor se podriacutea usar la CLI
$ dcos marathon app add lt f i l e j songt
O la API HTTP
$ cu r l minusX POST http lt ip_maestro gt8080v2apps minusd ltf i l e jsongt minusH Contentminustype app l i c a t i o n j son
32
612 Nomad
La arquitectura de Nomad es maacutes sencilla ya que solo requiere de un ficheroejecutable en todos los nodos para funcionar Si DCOS es la base de instala-cioacuten de entornos de terceros Nomad integra todas las funcionalidades baacutesicasesto es gestor de recursos planificador y ejecutor en los nodos cliente Estaherramienta cuenta con un menor tiempo de desarrollo y en el momento deescribir este documento cuenta exclusivamente con los siguientes controladoresen comparacioacuten con los entornos de DCOS
Motor Docker es decir funcioacuten de orquestacioacuten de contenedores
Ejecucioacuten de archivos binarios como comandos de Shell
Ejecucioacuten de aplicaciones Java
Virtualizacioacuten de maacutequinas mediante tecnologiacutea QEMU
Todos ellos necesitan que la tecnologiacutea subyacente esteacute instalada en las maacute-quinas clientes (Docker Java QEMU) Actualmente no permite el registro decontroladores por parte de terceros aunque estaacute planificado en un futuro ofreceruna interfaz para su desarrollo
Nomad no cuenta con el servicio de descubrimiento sin embargo puede inte-grarse con la herramienta Consul desarrollada por la misma empresa Por otrolado para el balanceo de carga usaremos un contenedor Docker con HAProxyuna herramienta de coacutedigo abierto que ofrece tanto servicios de proxy como debalanceador y cuyos ficheros de configuracioacuten completaremos con el proyectoConsul Template19
Consul
Consul sigue la misma arquitectura que Nomad es decir un nodo servidorque orquesta un conjunto de maacutequinas clientes y permite a los procesos que seejecutan en los equipos definirlos como servicios ofreciendo diversas caracteriacutes-ticas entorno a estos de los cuales vamos a usar dos
Descubrimiento de servicio Las maacutequinas clientes publican en el cataacutelogode servicios las tareas en ejecucioacuten y Consul les asigna nombres de dominioaccesibles por todos los miembros del cluster a traveacutes de la interfaz DNSincluida en esta herramientaConsul se integra con Nomad de forma que todas las tareas que se ejecu-ten en la segunda son automaacuteticamente publicados como servicios de laprimera de esta manera no hace falta conocer la direccioacuten de la maacutequinacliente donde se esteacute ejecutando el proceso ya que se puede acceder a eacutela traveacutes de su nombre de dominio de forma transparente Por ejemplo si
19[httpsgithubcomhashicorpconsul-template]
33
ejecutamos una tarea con ID web en el puerto 8080 se puede acceder aella en la direccioacuten webserviceconsul8080Para que las direcciones propias de Consul las resuelva su propio DNS y noel que esteacute asignado por defecto en la maacutequina usaremos la herramientadnsmasq20 que permite especificar la direccioacuten de un servidor DNS paraconsultas de direcciones especiacuteficas
Monitorizacioacuten Permite realizar comprobaciones del servicio y seguir su esta-do Aprovecharemos esta funcionalidad tanto para definir el propio procesode Nomad como servicio de Consul como las tareas desplegadas
HAProxy + Consul Template
HAProxy es una solucioacuten versaacutetil de coacutedigo abierto que ofrece solucionesde balanceo de carga y proxy Existen otras herramientas en el mercado comoNGINX o ldirectord sin embargo HAProxy suponiacutea una solucioacuten sencilla deconfigurar para mostrar el caso de uso
El uso de estas herramientas se debe a dos motivos para que no existacontienda con respecto a los puertos de los clientes usados por las tareas eacutestos sevan a asignar de forma dinaacutemica lo que en principio implicariacutea que la aplicacioacutendeberiacutea realizar consultas DNS de tipo SRV (que incluye puertos) a la interfazde Consul y balancear la carga entre tareas por redundancia y capacidad
Como la direccioacuten IP y puerto son variables cada vez que las tareas seactualicen o se reasignen es necesario volver a configurar HAProxy de formamanual Por ello HashiCorp ha desarrollado un programa denominado Con-sul Template que realiza peticiones sucesivas a la interfaz HTTP de Consul delas direcciones fiacutesicas de un servicio y reinicia automaacuteticamente el proceso deHAProxy Asiacute definiendo estas tareas como servicios Consul podremos tantomonitorizarlas como escalar las tareas dinaacutemicamente sin necesidad de cambiarel balanceador A partir del contenedor Docker oficial de HAProxy se ha desa-rrollado otro con la configuracioacuten baacutesica y con Consul Template para desplegarlocomo una tarea en Nomad
Despliegue
Se ha usado el mismo coacutedigo que en el apartado anterior con la persistenciaen el servicio de almacenamiento de Azure Desde la perspectiva del hardwarese implementaraacute la misma infraestructura que en el caso de DCOS (figura 18)estos es definiremos dos tipos de maacutequinas clientes un agente que se conectaraacutecon el balanceador de carga con nombre de dominio puacuteblico y donde se desple-garaacute el balanceador de carga de la vista web y agentes privados no accesiblesdesde fuera del cluster y donde se ejecutaraacuten el resto de tareas en la red inter-na La principal diferencia radica en las tareas que ejecutan HAproxy y ConsulTemplate que sustituye a las direcciones IP virtuales que ofrece DCOS
20httpwwwthekelleysorgukdnsmasqdochtml
34
Figura 20 Despliegue en Azure de Nomad+Consul
Cabe matizar que los balanceadores basados en HAProxy se implementanpor necesidad de la aplicacioacuten para el descubrimiento del servicio a diferenciade los de Azure que se implementan por motivos de seguridad y escalabilidaddel cluster en siacute
Configuracioacuten Nomad
Los ficheros de configuracioacuten de las maacutequinas maacutester y cliente son similaresy comparten la mayoriacutea de las opciones como por ejemplo el nombre del nodoo la interfaz de red donde escucha Nomad las peticiones Sus opciones son engeneral auto-explicativas sin embargo existen dos detalles que matizar
El proceso de Nomad escucha las peticiones tanto de los protocolos deconsenso como del usuario a traveacutes de una interfaz de red que se debeindicar en el fichero de configuracioacuten
En el caso de los clientes se deben indicar las direcciones de los servidoresdel cluster sin embargo se trata de un sistema dinaacutemico en el que losnodos pueden sufrir errores y cambiar de direccioacuten Por ello se ha definidoNomad como un servicio de Consul y asiacute poder definir la direccioacuten de losservidores como un nombre de dominio no por su direccioacuten fiacutesica que elservidor DNS de Consul se encargaraacute de resolver
Por defecto Nomad usa los siguientes puertos
API HTTP 4646 Peticiones HTTP y recepcioacuten de oacuterdenes mediante laliacutenea de comandos
RPC 4647 Protocolo de consenso entre los nodos del cluster
Serf 4648 Protocolo de gossip entre los servidores de los centros de datosgobernados por Nomad
35
Los dos uacuteltimos deben ser interfaces alcanzables por otros nodos sin embargo laAPI HTTP por motivos de seguridad deberiacutea ser local ya que en caso contrariocualquier persona con acceso a ella tiene el control sobre la herramienta Eacutestasolo deberiacutea estar accesible en un servidor o gestionarlo mediante una terminalSSH por ejemplo En este trabajo al ser una prueba de concepto se ha abiertoen todos los nodos
Trabajos de Nomad
Las tareas se detallan en ficheros con formato HashiCorp Configuration Lan-guage un derivado del formato JSON creado por la empresa que le da nombrecompatible con eacuteste y que permite comentarios
En estos ficheros se puede definir
La regioacuten y el centro de datos donde se ejecutaraacute (Nomad permite lagestioacuten de centros de datos geograacuteficamente distribuidos en regiones)
La poliacutetica de actualizacioacuten de la tarea
Grupo de tareas esto es que se ejecutaraacuten en el mismo nodo
El nuacutemero de grupos a ejecutarescalar asiacute como los liacutemite que debencumplir los nodos asignados
La poliacutetica de reinicio ante fallo o error
Tareas El controlador su configuracioacuten los paraacutemetros del servicio aso-ciado a registrar en Consul asiacute como los recursos que consume (puertosmemoria)
En nuestro caso usamos sobre todo el controlador Docker esto eso orques-tacioacuten de contenedores en los nodos clientes y tres de sus opciones
Imagen del contenedor Se han subido todas las imaacutegenes del proyecto a Doc-ker Hub donde por defecto se busca la imagen
Puertos Los puertos a usar por el contenedor que pueden ser estaacuteticos asigna-dos por el usuario o dinaacutemicos siendo Nomad el que se encarga de mapearun puerto libre del nodo cliente al expuesto por el contenedor
Servidores DNS Como usamos la interfaz DNS de Consul como descubri-miento de servicio se debe configurar el contenedor para que use cualquiernodo del cluster como servidor DNS
Configuracioacuten Consul
Al ser desarrolladas por la misma empresa los ficheros de configuracioacuten deConsul y Nomad comparten muchas opciones Consul tambieacuten acepta peticionesa traveacutes de una interfaz de red siendo los puertos usados por defecto
36
RPC 8300 8400 Maneja la peticiones del resto de nodos y usuarios
Serf 8301 8302 Protocolo gossip
HTTP API 8500
HTTPS API Desactivada por defecto
Interfaz DNS 8600
Se debe asignar a los protocolos internos del cluster esto es RPC y Serf unainterfaz alcanzable por los nodos y por el contrarioasignar a los dos uacuteltimos ala interfaz de loopback por motivos de seguridad
Cabe destacar que Consul tambieacuten cuenta con una interfaz graacutefica que per-mite ver el estado de los equipos y los servicios registrados y que se encuentra enel mismo puerto que la API HTTP en la direccioacuten httpIP_EQUIPO8500ui
Ejecucioacuten
Tanto Nomad como Consul requieren de la ejecucioacuten de un fichero en todoslos nodos integrantes del cluster Como prueba de concepto se ha decidido usardos servidores para ambos aunque cabe matizar que es un nuacutemero ineficienteya que la caiacuteda de uno de ellos supondriacutea la peacuterdida del cuoacuterum y por tantodel consenso del cluster
En primer lugar se arrancan los servidores que son los encargados de ejecu-tar el protocolo de consenso y gestionar el cluster y a continuacioacuten los clientesque no tienen praacutecticamente estado y dependen de los servidores
En el caso de Consul se debe indicar el directorio donde se guardan losficheros que describen los servicios asiacute como el archivo que especifica el resto delas opciones
1 Se inicia el primer servidor en uno de los equipos
$ consu l agent minuscon f i gminusd i r e t c consu l d s e r v i c e s minuscon f i gminus f i l e consu l_server j son
2 Los siguientes equipos deben unirse al anterior por lo que antildeadimos elargumento join con la direccioacuten del primer servidor Para el caso de otrosservidores
$ consu l agent minuscon f i gminusd i r e t c consu l d s e r v i c e s minuscon f i gminus f i l e consu l_server j son minus j o i n ltIP_servidor1gt
37
Una vez los servidores han alcanzado el consenso y elegido un liacuteder en losclientes
$ consu l agent minuscon f i gminusd i r e t c consu l d s e r v i c e s minuscon f i gminus f i l e c on su l_c l i en t j son minus j o i n ltIP_cualquierServ idorgt
El proceso para iniciar Nomad es igual y los comandos similares sin embargoya no es necesario indicar una direccioacuten IP fija en los equipos sino el nombre dedominio del servicio de Nomad registrado por Consul En el primer servidor
$ nomad agent minusc on f i g nomad_server j son
Y el resto de equipos (con su fichero de configuracioacuten correspondiente)$ nomad agent minusc on f i g nomad_server j son minus j o i n nomad s e r v i c e consu l
Por uacuteltimo para desplegar la aplicacioacuten web se han escrito tres ficherosque detallan las tareas de la interfaz web API y los balanceadores de cargaMediante la CLI
$ nomad run minusaddress=http lt ip_c lus te r gt4646 lt f i l e hclgt
O mediante la API HTTP de Nomad$ cu r l minusX POST minusd ltf i l e hclgthttp lt ip_c lus te r gt4646 jobltjob_namegt
Ansible
Como se puede comprobar con el aumento del nuacutemero de equipos pasa aser inviable manejar todos los nodos a traveacutes de terminal Ademaacutes como seha comentado con anterioridad Nomad requiere que en los nodos clientes es-teacuten instalados las herramientas que soporten las tareas por ejemplo el motorde Docker Por ello para facilitar tanto el arranque como la instalacioacuten de lasdependencias vamos a usar Ansible una herramienta de coacutedigo abierto desarro-llada en Python que permite gestionar configuraciones aprovisionar recursosdespliegue de aplicaciones de forma automaacutetica
A grandes rasgos esta herramienta funciona mediante ficheros en formatoYAML denominados play-books que describen un conjunto de pasos a ejecutaren una lista de equipos remotos Estos pasos son ejecutados por moacutedulos inde-pendientes a traveacutes de SSH es decir en cualquier ordenador con conexioacuten a los
38
hosts dado su contrasentildea o clave puacuteblica puede arrancar el script y realizariacutealos pasos de forma remota gestionando el cluster desde un solo equipo
Se han desarrollado guiones para lo siguiente
Descarga de los binarios de Nomad y Consul en todos los nodos copiade los ficheros de configuracioacuten baacutesicos y modificarlos de acuerdo a cadanodo (nombre del equipo direccioacuten IP)
Instalacioacuten de las dependencias
Arranque de Nomad y Consul
Ansible extiende su funcionalidad a traveacutes de moacutedulos independientes que per-miten por ejemplo instalar paquetes mediante herramientas de gestioacuten de pa-quetes (APT yum) aprovisionar automaacuteticamente maacutequinas virtuales de Ama-zon EC2
Algunas opciones de los ficheros de configuracioacuten de Nomad y Consul sondependientes del nodo particular por ejemplo la interfaz de red Para estetrabajo se ha realizado un moacutedulo para modificar los ficheros de configuracioacutende forma automaacutetica En el repositorio del proyecto se encuentra una carpetadonde se encuentran todos los ficheros necesarios para desplegar un clustertotalmente funcional solo requiere de una liacutenea de terminal con Ansible
$ ans ib l eminusplaybook minus i hos t s minusk ltssh_passgt minusu ltnode_usergt s i t e yml
39
62 Servicio de integracioacuten continua
Se ha implementado un sistema de integracioacuten continua que permite ejecu-tar tareas de compilacioacuten y pruebas de forma distribuida aumentando asiacute elrendimiento de los equipos En primer lugar se detallaraacute los motivos por los quepuede resultar beneficioso para las empresas una implementacioacuten de este tipo alo que seguiraacute los detalles del despliegue
621 DevOps
Metodologiacutea que defiende la comunicacioacuten y colaboracioacuten entre desarrolla-dores de software y los profesionales de operaciones a lo largo de todo el ciclo devida de una aplicacioacuten Estaacute muy relacionado con el desarrollo aacutegil de softwareesto es un enfoque para los proyectos que defiende el desarrollo iterativo e in-cremental donde los requisitos y soluciones evolucionan con el tiempo seguacuten lanecesidad del proyecto DevOps extiende esta filosofiacutea a todas los componentesde un servicio incluyendo sistemas y operaciones
Se trata de un concepto que cada organizacioacuten o empresa adapta a suspropias necesidades y procesos de negocio en este proyecto nos vamos a centraren la integracioacuten continua una praacutectica fundamental tanto del desarrollo aacutegilcomo de esta filosofiacutea
622 Integracioacuten Continua
Se define como una praacutectica de desarrollo software donde los miembros delequipo ponen en comuacuten su trabajo frecuentemente al menos una vez al diacutea21Cada integracioacuten se verifica con una compilacioacuten automaacutetica que incluye laejecucioacuten de pruebas para detectar errores de integracioacuten tan pronto como seaposible
Desde el punto de vista operativo esto supone automatizar la configuracioacutende equipos o el despliegue de maacutequinas virtuales donde compilar el proyecto yejecutar las pruebas y posteriormente eliminarlas Este flujo de trabajo se vebeneficiado en entornos distribuidos ya que el objetivo del desarrollador es com-probar el resultado de las pruebas raacutepidamente sin preocuparse del despliegueo los propios equipos
Para esta prueba de concepto vamos a usar Jenkins un servidor de integra-cioacuten continua escrito en Java que nos permite definir trabajos que contendraacutenla descripcioacuten tanto del entorno como su ejecucioacuten
Este sigue una estructura maestro-esclavo muy similar al de los gestores declusters usados en este proyecto el maestro contiene toda la loacutegica del servicio
21httpmartinfowlercomarticlescontinuousIntegrationhtml
40
trabajos autenticacioacuten y los esclavos son los encargados de la ejecucioacuten ensiacute Jenkins tiene varias viacuteas para aprovisionar los uacuteltimos
Mediante SSH
Interfaz graacutefica
Desarrollar un script propio
Ejecucioacuten de un fichero java
La ventaja de usar planificadores es que el despliegue de esclavos es dinaacutemicoes decir no tener una maacutequina especiacuteficamente configurada para ello DCOS yNomad se encargaraacuten de configurar estos despliegues en sus maacutequinas y poste-riormente eliminarlos Para ello se ha usado la uacuteltima opcioacuten definiendo tareasque descarguen el fichero java Con todo ello se consigue un entorno de inte-gracioacuten continua eficiente que ademaacutes permite la ejecucioacuten de otros servicios deforma independiente
Jenkins permite la creacioacuten de plugins que extienden sus funcionalidadesTanto Nomad22 como Apache Mesos cuentan con uno que permite su integra-cioacuten
Para esta prueba se va a usar el mismo proyecto que para el caso de usode orquestacioacuten de contenedores la aplicacioacuten web al que se le ha antildeadido untest para comprobar que se conecta correctamente a la base de datos medianteMocha un framework de Nodejs Por otro lado se antildeade el plugin de git ya queel coacutedigo se obtiene de GitHub el repositorio remoto de control de versiones delproyecto
El proceso general de ejecucioacuten seriacutea como sigue
1 Se ejecuta el maestro de Jenkins como tarea Docker partiendo de la imagenoficial
2 Al arrancar un trabajo se manda una tarea a los planificadores que laasignaraacuten a un nodo cliente Esta tarea consiste en la descarga del ficherode configuracioacuten Java y arrancarlo configurando el equipo como un clientede Jenkins temporalmente
3 Jenkins ejecuta el trabajo en el nuevo cliente en este caso iniciar la apli-cacioacuten web iniciar las pruebas y generar un informe
4 Se elimina el cliente
A continuacioacuten se detallan los matices de cada herramienta a la hora de imple-mentar este servicio
22Desarrollado por Ivo Verberk httpwwwivoverberknl
41
623 Jenkins con Nomad
El plugin permite la ejecucioacuten del fichero Java mediante dos controladorescontenedores Docker y Java En este proyecto nos hemos decantado por el pri-mero ya que nos ahorra instalar la maacutequina virtual de java en todos los nodoscliente Por ello se ha construido un contenedor base con Java para la ejecucioacutendel fichero de configuracioacuten y Nodejs para lanzar la aplicacioacuten web
El plugin se configura con la direccioacuten IP del cluster y el contenedor queejecuta el esclavo Jenkins Por su parte el trabajo en Jenkins se define conel repositorio en GitHub donde se aloja el coacutedigo del proyecto a probar y loscomandos a ejecutar en este caso npm update y npm test
624 Jenkins con DCOS
En el caso de DCOS su sistema de paquetes incluye Jenkins por lo queal instalarlo ya se tiene la configuracioacuten de Mesos totalmente funcional Sinembargo para ejecutar la aplicacioacuten en particular y las pruebas se requiere deNodejs en los equipos esclavos por ello debemos antildeadir un plugin de Jenkinsque permite instalar este entorno antes de ejecutar el trabajo Una vez hechoesto soacutelo queda definir la tarea igual que en el caso anterior
Cabe destacar que Mesosphere tambieacuten ha desarrollado un plugin que per-mite hacer despliegues en Marathon de tal manera que permitiriacutea con cadacommit del coacutedigo compilar la imagen del contenedor Docker y desplegarlaautomaacuteticamente aunque en este proyecto no se ha hecho pruebas de esta fun-cionalidad
42
7 Escalando la infraestructura
Uno de los factores clave que se busca a la hora de implementar sistemasdistribuidos es el poder escalar la infraestructura de forma maacutes sencilla estoes detectar que las maacutequinas estaacuten alcanzando el liacutemite de su capacidad yaumentar eacutesta ya sea mejorando sus caracteriacutesticas teacutecnicas o antildeadiendo maacutesnodos al cluster
El coacutedigo y todos los ficheros de configuracioacuten de esta seccioacuten tambieacuten sepueden encontrar en el repositorio del proyecto en GitHub23
71 Disentildeo
Microsoft Azure permite organizar los servicios cloud de forma loacutegica a traveacutesde grupos de recursos y asiacute poder crear o eliminar eacutestos en conjunto parauna aplicacioacuten determinada (por ejemplo una aplicacioacuten web suele requerir demaacutequinas virtuales bases de datos almacenamiento) Ademaacutes dispone dela opcioacuten de crear plantillas en formato JSON que permite al desarrolladordefinir los recursos y su interrelacioacuten para desplegar de forma automaacutetica unainfraestructura TI en la nube
Azure tambieacuten ofrece la posibilidad de monitorizar el estado de las maacutequinasvirtuales a traveacutes de extensiones lo que permite configurar el escalado automaacute-tico al alcanzar cierto liacutemite definido por el operador Eacutesta es a priori la formaen que deberiacutea implementarse hablando en teacuterminos de eficiencia sin embargoesta aproximacioacuten es totalmente dependiente de la plataforma es decir no sepuede extrapolar a otro proveedor o sobre recursos propios sin realizar un nue-vo disentildeo En este proyecto las tareas que son ejecutadas por estos equipos notienen estado ya que todo lo relativo a la persistencia lo hemos asignado fueradel cluster esto permite escalar la plataforma a traveacutes de otra aproximaciones
Las plantillas aceptan una serie de variables a indicar por el usuario entreotras los conjuntos de escala para definir los nodos aceptan una variable quedefine el nuacutemero de maacutequinas que los componen Por otro lado Azure ofreceuna API REST y kits de desarrollo software (SDK por sus siglas en ingleacutes) quepermiten su despliegue de forma programaacutetica Aprovechando estas facilidadesen este proyecto se va a aproximar la escalabilidad con el sucesivo desplieguede la infraestructura de forma automaacutetica se monitorizan los equipos y si sedetecta una maacutequina excesivamente cargada se aumenta el nuacutemero de equiposen la plantilla y se vuelve a desplegar
23httpsgithubcomAntonioAlfrzCloud-Orchestrators
43
En este proyecto se han disentildeado las plantillas para desplegar la arquitec-tura necesaria tanto de Nomad como de DCOS En el caso de la primera eldespliegue es maacutes descriptivo ya que incluye maacutequinas virtuales grupos de se-guridad redes En el caso de DCOS Azure cuenta con un servicio especiacuteficopara clusters gobernados por DCOS denominado Azure Container Service queincluye los componentes necesarios y la instalacioacuten ya realizada
72 Implementacioacuten
En primer lugar para monitorizar el estado de los equipos se va a usar laherramienta Nagios un sistema que permite controlar el estado del hardwarey los servicios de un equipo Se trata de una herramienta muy completa de laque se va a usar su capacidad para ejecutar comandos (plugins) en los nodospara detectar picos de carga generar alertas y ejecutar programas para estoseventos
Se ha desplegado una maacutequina virtual con esta herramienta en ambos siste-mas y se ha instalado una extensioacuten de Nagios (Nagios Remote Plugin Executor)en todos los nodos que permite ejecutar comprobaciones remotamente en con-creto para esta prueba de concepto medir el nivel de saturacioacuten de la unidadcentral de procesamiento (CPU por sus siglas del ingleacutes) Cuando sucede uncambio de estado de una maacutequina esto es cuando este paraacutemetro supera el liacutemi-te definido por el operador Nagios permite actuar en consecuencia ejecutandoprogramas por ello se ha desarrollado un script que ejecuta lo siguiente
Un programa desarrollado en Python con el SDK de Azure que modificalas plantillas y despliega los recursos
Un guioacuten de Ansible para instalar todos los componentes necesarios en lasnuevas maacutequinas y arrancar de nuevo el cluster y las aplicaciones
44
8 Resultados y conclusiones
En este uacuteltimo apartado se da una visioacuten global del proyecto asiacute como a lasconclusiones maacutes importantes a las que se ha llegado y posibles temas futurosde desarrollo
81 Comparacioacuten
Ambas herramientas ofrecen las funcionalidades para gestionar los recursoseficientemente ofreciendo a los desarrolladores una plataforma donde desplegarsus aplicaciones de forma distribuida independientemente de los equipos fiacutesicosy el hardware que las soporten
DCOS es una herramienta que en un comienzo fue privativa pero cuyos res-ponsables la empresa Mesosphere decidieron publicar una versioacuten de coacutedigoEacutesta nos permite gestionar un cluster de una forma sencilla y usable ademaacutes decomplementarlo con otras herramientas como el balanceador de carga integradoo la autenticacioacuten de usuarios ademaacutes estaacute basada en Apache Mesos un pro-yecto de relativa madurez y con el soporte de la Apache Software FoundationDe forma resumida DCOS ofrece muchas posibilidades y servicios a cambiode una arquitectura e instalacioacuten maacutes compleja
Por su parte HashiCorp con menor tiempo de desarrollo ha conseguidouna herramienta muy sencilla de desplegar que ademaacutes cumple con todas lasfuncionalidades baacutesicas ejecutando un simple binario en cada nodo se puededesplegar un gestor de clusters totalmente funcional Sin embargo no cuentacon todas las posibilidades de Mesos (Nomad cuenta con menos controladoresque entornos posibles de Mesos) ni con los antildeadidos de DCOS lo que implicael uso de otras herramientas para complementar el servicio (Consul HAProxy)
De entre las dificultades encontradas al usar estas herramientas y desplegaraplicaciones sobre ellas se puede destacar la depuracioacuten en ocasiones se desco-noce si un error viene de la propia herramienta de la aplicacioacuten desplegada o delequipo fiacutesico si no se cuenta con un sistema de procesamiento de registro unose puede encontrar con muacuteltiples terminales abiertas inspeccionando numerososficheros de registro buscando posibles errores Ademaacutes no dejan de ser solucio-nes que para usar eficientemente se debe conocer parte de su funcionamientoy sintaxis a la hora de describir la tareas lo que supone un esfuerzo antildeadido yaque cada una tiene sus particularidades y liacutemites
45
82 Conclusiones
En una sociedad cada vez maacutes digital las empresas deben adaptarse a unmercado cuya demanda de contenido no deja de crecer Las nuevas arquitecturascomo microservicios asiacute como la gran cantidad de datos generada implica queuna mejor gestioacuten de los recursos y la rapidez para desplegar o escalar solucionesdando valor al cliente lo maacutes raacutepido posible es uno de los objetivos de todas lasempresas de base tecnoloacutegica
Las ventajas que ofrecen los planificadores con aplicaciones distribuidas sonnumerosas sin ir maacutes lejos empresas tan punteras como Google llevan maacutesde 10 antildeos orquestando contenedores24 Por un lado permiten aumentar elrendimiento de los equipos propios y por otro implementar un servicio comoplataforma para despliegues distribuidos sobre cualquier conjunto hardware deesta forma se provee un servicio similar al de la nube puacuteblica pero con laprincipal diferencia de que se elimina la independencia con el proveedor (vendorlock-in) esto es las aplicaciones no tienen limitaciones impuestas por eacuteste talescomo lenguaje de programacioacuten o herramientas y permite despliegues hiacutebridosentre recursos propios y la nube
83 Objetivos conseguidos
Implementacioacuten de los planificadores propuestos en la nube Se ha en-tendido y detallado el funcionamiento de estas herramientas y se hanimplementado en el servicio de infraestructura de Microsoft Azure
Despliegue de aplicaciones y servicios distribuidos Servicios que se usanactualmente en la industria del desarrollo software asiacute como una aplica-cioacuten web con una arquitectura moderna han sido desplegados de formadistribuida en los equipos cumpliendo con la funcionalidad esperada ade-maacutes de consiguiendo una alta disponibilidad
Aproximacioacuten de arquitectura escalable Se ha hecho una aproximacioacutende infraestructura escalable de forma que sea parcialmente extrapolable aotros proveedores
24httpwwwnextplatformcom20160322decade-container-control-google
46
84 Liacuteneas de investigacioacuten
Siguiendo con la materia de este proyecto se presentan posibles liacuteneas deinvestigacioacuten
Analizar el despliegue con estas herramientas de aplicaciones de Big Datay comparar la eficiencia con respecto a soluciones especializadas
Analizar el rendimiento de los algoritmos de planificacioacuten antes pruebasde estreacutes y situaciones de alta contienda
Comparar el uso de estas herramientas con las praacutecticas actuales de laindustria o implementacioacuten en un sistema de produccioacuten real
47
Referencias
[1] LA Barroso y U Houmllzle laquoThe Datacenter as a Computer An Introduc-tion to the Design of Warehouse-Scale Machinesraquo En Morgan amp ClaypoolPublishers ()
[2] Systems Research Group ndash NetOS (University of Cambridge) The evolu-tion of cluster scheduler architectures 2016 url httpswwwclcamacukresearchsrgnetoscamsasblog2016-03-09-scheduler-architectureshtml
[3] A Das I Gupta y A Motivala SWIM Scalable Weakly-consistent Infection-style Process Group Membership Protocol Inf teacutec Dept of ComputerScience Cornell University url https www cs cornell edu ~asdasresearchdsn02-swimpdf
[4] D Dubhashi y A Das Mastering Mesos PACKT Publishing mayo de2016
[5] The Apache Software Foundation Apache Mesos documentation urlhttpsmesosapacheorg
[6] David Greenberg Building Applications on Mesos OrsquoReilly Media 2016[7] Armand Grillet Comparison of Container Schedulers Inf teacutec Technische
Universitaumlt Berlin[8] HashiCorp Consul documentation url httpswwwconsulio[9] HashiCorp Nomad documentation url httpsdcosio[10] Dan C Marinescu Cloud computing theory and practice Morgan Kauf-
mann 2013[11] Mesosphere DCOS documentation url httpswwwnomadproject
io[12] Microsoft Azure documentation url httpsazuremicrosoftcom
es-esdocumentation[13] D Ongaro y J Ousterhout In Search of an Understandable Consensus
Algorithm Inf teacutec Stanford University url httpsraftgithubioraftpdf
[14] Fei Teng laquoRessource allocation and schelduling models for cloud compu-tingraquo Tesis de mtriacutea Ecole Centrale Paris 2011
[15] A Williams y col Automation and Orchestration with Docker and Contai-ners A Comprehensive Overview of the Docker and Container Ecosystem3 The New Stack 2016
48
- Resumen
- Summary
- Iacutendice de figuras
- Introduccioacuten y objetivos
-
- Contexto
- Objetivos
- Estructura del documento
-
- Cloud Computing
- Nuevas cargas de trabajo
- Gestioacuten de recursos Planificadores
-
- Sistemas distribuidos
-
- Clasificacioacuten
-
- Herramientas
-
- DCOS
-
- Apache Mesos
- Ejemplos de uso
-
- Nomad
-
- Protocolo de consenso Raft
- Protocolo gossip SWIM
- Planificacioacuten
-
- Casos de uso y despliegue
-
- Aplicacioacuten Web
-
- DCOS
- Nomad
-
- Servicio de integracioacuten continua
-
- DevOps
- Integracioacuten Continua
- Jenkins con Nomad
- Jenkins con DCOS
-
- Escalando la infraestructura
-
- Disentildeo
- Implementacioacuten
-
- Resultados y conclusiones
-
- Comparacioacuten
- Conclusiones
- Objetivos conseguidos
- Liacuteneas de investigacioacuten
-
vi
Iacutendice
Resumen III
Summary V
Iacutendice de figuras IX
1 Introduccioacuten y objetivos 1
11 Contexto 1
12 Objetivos 2
13 Estructura del documento 2
2 Cloud Computing 3
3 Nuevas cargas de trabajo 5
4 Gestioacuten de recursos Planificadores 8
41 Sistemas distribuidos 8
411 Clasificacioacuten 10
5 Herramientas 13
51 DCOS 14
511 Apache Mesos 15
512 Ejemplos de uso 18
52 Nomad 19
521 Protocolo de consenso Raft 20
vii
522 Protocolo gossip SWIM 23
523 Planificacioacuten 24
6 Casos de uso y despliegue 27
61 Aplicacioacuten Web 27
611 DCOS 28
612 Nomad 33
62 Servicio de integracioacuten continua 40
621 DevOps 40
622 Integracioacuten Continua 40
623 Jenkins con Nomad 42
624 Jenkins con DCOS 42
7 Escalando la infraestructura 43
71 Disentildeo 43
72 Implementacioacuten 44
8 Resultados y conclusiones 45
81 Comparacioacuten 45
82 Conclusiones 46
83 Objetivos conseguidos 46
84 Liacuteneas de investigacioacuten 47
viii
Iacutendice de figuras
1 Comparacioacuten Centro de datos - Computacioacuten en la nube 4
2 Arquitectura Docker 6
3 Planificador monoliacutetico 11
4 Planificador de dos niveles 11
5 Planificador de estado compartido 12
6 Planificador distribuido 12
7 Arquitectura DCOS 14
8 Servicios DCOS 15
9 Arquitectura de Apache Mesos 17
10 Arquitectura multi-regioacuten en Nomad 20
11 Equipos sin consenso ejecutando el protocolo RAFT 21
12 Un equipo pasa a estado candidato (RAFT) 22
13 Cambio en un registro (RAFT) 22
14 Aprobacioacuten del resto de equipos (RAFT) 23
15 Diagrama de tiempo del protocolo SWIM 24
16 Procedimiento de asignacioacuten en Nomad 25
17 Arquitectura aplicacioacuten web 28
18 Infraestructura en Azure 29
19 Arquitectura de la aplicacioacuten web en DCOS 32
20 Despliegue en Azure de Nomad+Consul 35
ix
1 Introduccioacuten y objetivos
11 Contexto
Las tecnologiacuteas de la informacioacuten y la comunicacioacuten estaacuten suponiendo uncambio draacutestico en la sociedad en 2007 comenzaron a aparecer los teleacutefonosinteligentes tal y como los conocemos y nueves antildeos despueacutes se empieza a con-cebir la idea de dar conectividad a todo dispositivo electroacutenico movimiento queha tomado el nombre de Internet de las cosas Para hacerse una idea de la rapi-dez y magnitud de esta evolucioacuten la consultora Excelacom1 ha estimado que enun minuto se realizan 24 millones de buacutesquedas en Google o se ven 278 millonesde viacutedeos en Youtube En una eacutepoca en la que los recursos tecnoloacutegicos crecenexponencialmente y los usuarios demandan mayor contenido y movilidad nocabe duda que las empresas deben adaptarse lo maacutes raacutepidamente posible a esteproceso de digitalizacioacuten movidas por las nuevas necesidades de las personas
Dado el gran volumen de informacioacuten a lo largo de estos antildeos la compu-tacioacuten y el almacenamiento estaacuten pasando de clientes locales a concentrarse engrandes centros de datos una tendencia que Google ha denominado ldquoWarehouse-scale computingrdquo en 2009[1] Este movimiento hacia la computacioacuten desde ser-vidor no solo viene de la necesidad de mejorar la experiencia de los usuariossino tambieacuten de facilitar la gestioacuten y configuracioacuten de los recursos asiacute como laubicuidad de acceso que permite
En 2006 Amazon lanza Amazon Web Services siendo uno de los pionerosen el mercado de los recursos virtuales ofreciendo capacidad de computacioacutencon un coste proporcional exclusivamente a los recursos utilizados Todo ellocambioacute la perspectiva de los modelos tradicionales de TI a la conocida comocomputacioacuten en la nube recursos informaacuteticos que antes suponiacutean barrerasde entrada en ciertos mercados han pasado a ser condicioacuten necesaria para laconstante evolucioacuten de la tecnologiacutea y la sociedad De hecho Cisco estima quepara el antildeo 2019 maacutes del 86 de las cargas de trabajo seraacuten procesadas porcentros de datos en la nube2
1httpwwwexcelacomcomresourcesblog2016-update-what-happens-in-one-internet-minute2httpwwwciscocomcenussolutionscollateralservice-provider
global-cloud-index-gciCloud_Index_White_Paperpdf
1
12 Objetivos
El propoacutesito de este proyecto es estudiar la viabilidad del uso de planifica-dores de recursos para aumentar la eficiencia de eacutestos y facilitar al desarrolladorel despliegue de aplicaciones de forma distribuida y asiacute ofrecer un servicio ca-racterizado por una alta disponibilidad y escalabilidad
A lo largo de este trabajo se han usado algunas de las herramientas quese estaacuten comenzando a desarrollar para hacer frente a este nuevo enfoque degestioacuten de infraestructuras de las tecnologiacuteas de la informacioacuten (en adelanteinfraestructuras TI) realizando pruebas de concepto sobre cada una de ellas
13 Estructura del documento
A continuacioacuten se detalla las secciones que componen este trabajo La es-tructura queda como sigue
Cloud computing Se entra en detalle en este nuevo modelo de negocio queha originado nuevos enfoques y disentildeos de las infraestructuras TI dentrode las organizaciones
Nuevas cargas de trabajo Se explican algunas tecnologiacuteas representativasque estaacuten suponiendo un desafiacuteo para los profesionales de TI a la horade planificar los recursos y que se ven beneficiadas por entornos de tipocloud
Gestioacuten de recursos Planificadores Estado del arte de las tecnologiacuteas degestioacuten de clusters y planificacioacuten de recursos
Herramientas Descripcioacuten detallada del funcionamiento y arquitectura de lasherramientas usadas a lo largo del proyecto
Casos de uso y despliegue Se describe el proceso de implementacioacuten de unaaplicacioacuten web y un servicio de integracioacuten continua con el software pro-puesto
Escalando la infraestructura Se propone un procedimiento con cierta inde-pendencia del proveedor cloud
Resultados y conclusiones Resume las ideas y hechos a los que se ha llegadoademaacutes de introducir liacuteneas de investigacioacuten futuras
2
2 Cloud Computing
El NIST (National Insitute of Standards and Technology) define este con-cepto como un modelo que permite un acceso ubicuo y bajo demanda de formaremota a un conjunto compartido de recursos de computacioacuten que pueden seraprovisionados y liberados con unos miacutenimos esfuerzos de gestioacuten por parte delproveedor del servicio3
Clasificacioacuten
La computacioacuten en la nube abarca una amplia variedad de servicios y enfo-ques por lo que en primer lugar se va a dar una clasificacioacuten para posterior-mente entrar maacutes en detalle Existen distintos modelos de nube atendiendo a lagobernabilidad de la infraestructura seguacuten el NIST
Nubes puacuteblicas Los servicios y recursos son ofertados de forma puacuteblica yson provistos por una organizacioacuten que los comercializa bajo demanda
Nube privada Los recursos son gestionados por una uacutenica organizacioacutenpara su propio uso
Nube comunitaria En este caso la infraestructura es administrada por unconjunto de organizaciones con objetivos comunes
Nube hiacutebrida Una combinacioacuten de las anteriores
A su vez los distintos servicios que ofrece se pueden clasificar atendiendo algrado de control del usuario
Servicios de software (Software as a Service SaaS) El proveedor se encargade toda la gestioacuten de la infraestructura y oferta aplicaciones a las cuales elcliente puede acceder de forma ubicua a traveacutes de diversos clientes comoun navegador web Por ejemplo Office 365 o Google docs
Servicios de plataforma (Platform as a Service PaaS) Modelo de distribu-cioacuten que ofrece la capacidad de desplegar aplicaciones desarrolladas por elcliente usando las herramientas y lenguajes de programacioacuten soportadaspor el proveedor pero sin la posibilidad de gestionar los recursos consu-midos En este caso el cliente solo tiene control sobre la propia aplicacioacuteny algunas configuraciones del entorno Es el caso de Heroku o Google AppEngine
3httpnvlpubsnistgovnistpubsLegacySPnistspecialpublication800-145pdf
3
Servicios de infraestructura (Infrastructure as a Service IaaS) Se ofertanrecursos de computacioacuten puros como procesamiento o almacenamientomediante una plataforma de virtualizacioacuten El cliente puede controlar elsistema operativo componentes de red y aplicaciones
Figura 1 Comparacioacuten Centro de datos - Computacioacuten en la nubeFuente httpsad-hocnet
De entre las numerosas ventajas que ofrece la computacioacuten en la nube se puededestacar su flexibilidad ya que permite aprovisionar recursos y adaptarlos deacuerdo a la demanda reduce el capital inmovilizado y su amortizacioacuten laubicuidad que permite su consumo desde cualquier parte con conexioacuten a la redy la seguridad y fiabilidad que ofrece el proveedor que normalmente cuenta conrecursos geograacuteficamente distribuidos frente a la gestioacuten y mantenimiento derecursos propios
4
3 Nuevas cargas de trabajo
Las organizaciones que cuentan con sus propios infraestructuras TI han co-menzado a adoptar un enfoque de nube privada para gestionar las tareas ofunciones informaacuteticas sobre las que se sustentan el negocio ya que una es-tructura virtualizada puede ofrecer ventajas con respecto a las adaptaciones decentros de datos tradicionales en los aacutembitos de rendimiento escalabilidad eincluso seguridad4
A su vez se han desarrollado nuevas tecnologiacuteas que suponen cargas detrabajo dinaacutemicas y con gran intensidad de consumo de datos para las empresasque se ven beneficiadas al desplegarlas en recursos virtualizados
Big data
Con la creciente aceptacioacuten de las tecnologiacuteas TIC por parte de la sociedadla cantidad de datos generados en la red es ingente Las profesionales de TI tienecomo objetivo extraer valor de eacutestos para por ejemplo prever las tendencias delmercado Sin embargo este incremento exponencial hace que su procesamientoy almacenamiento requiera de un sistema con gran escalabilidad dado el hechode que una sola maacutequina no puede proveer de la capacidad necesaria
Integracioacuten continua
Modelo informaacutetico que consiste en hacer integraciones automaacuteticas de unproyecto con cualquier cambio en el coacutedigo con el objetivo de detectar fallosde forma temprana Esto implica la compilacioacuten del coacutedigo y su ejecucioacuten enun entorno de pruebas automaacuteticamente un proceso que mediante tecnologiacuteasde virtualizacioacuten permiten simular entornos con eficiencia y rapidez Su imple-mentacioacuten en sistemas distribuidos permite tanto una mejor planificacioacuten comoun mejor rendimiento de los recursos
Arquitectura de microservicios
Enfoque para desarrollar aplicaciones software como un conjunto de serviciosautoacutenomos que se comunican entre siacute a diferencia de aproximaciones monoliacuteti-cas donde la loacutegica del servicio estaacute desarrollada como una unidad Un sistemadistribuido permite el despliegue de los componentes en distintas maacutequinas loque mejora tanto su escalabilidad como la tolerancia a fallos
4httpswwwakamaicomesesresourcespublic-private-cloudjsp
5
Docker
Proyecto de coacutedigo abierto que facilita y automatiza el despliegue de aplica-ciones al encapsular el entorno de trabajo en contenedores Linux una tecnologiacuteaque permite a un sistema fiacutesico ejecutar muacuteltiples instancias de sistemas opera-tivos aislados mediante entornos virtuales con sus propios espacios de procesosy redes pero compartiendo el nuacutecleo (kernel) con el equipo anfitrioacuten
En la figura 2 se compara la pila de una virtualizacioacuten tradicional con res-pecto a los contenedores no se simula el sistema operativo por lo que el procesoes mucho maacutes ligero
Docker se caracteriza por
Autosuficiencia Los contenedores cuentan con las libreriacuteas y configuracio-nes necesarias para ejecutarse de manera autoacutenoma al compartir el nuacutecleo
Portabilidad El hecho de que sean autosuficientes implica que es inde-pendiente del host es decir se puede desplegar en cualquier equipo quesoporte esta tecnologiacutea
Tamantildeo El peso de un contenedor es sustancialmente inferior a otrastecnologiacuteas de virtualizacioacuten
Figura 2 Arquitectura DockerFuente httpsdockercom
6
Los componentes fundamentales de esta herramienta son
Imaacutegenes Describen el entorno de base sobre el que ejecutar el contene-dor por ejemplo la imagen del sistema operativo Ubuntu Sobre eacutesta seconstruyen las aplicaciones particulares del usuario dando lugar a otraimagen
Contenedores Se crean a partir de las imaacutegenes y comprenden todo aquellonecesario para arrancar la aplicacioacuten decir su entorno de ejecucioacuten
bull Voluacutemenes Encargados de gestionar la persistencia de datos e inde-pendientes del ciclo de vida del contenedor
Registros Pueden ser puacuteblicos o privados y almacenan las imaacutegenes elregistro puacuteblico oficial de Docker es Docker Hub
Dadas estas caracteriacutesticas los profesionales TI estaacuten comenzando a adoptarDocker ya que facilita tanto los despliegues como el trabajo compartido en dis-tintos entornos Sin embargo esto requiere de un software que permita desplegarlos distintos contenedores de forma que puedan trabajar en conjunto procesoque se ha denominado orquestacioacuten de contenedores
7
4 Gestioacuten de recursos Planificadores
Para sacar el maacuteximo provecho a las tecnologiacuteas anteriormente descritaslo ideal es desplegarlas en sistemas distribuidos sin embargo esto aumenta lacomplejidad del propio despliegue asiacute como la necesidad de software especiali-zado para ello Se necesitan algoritmos de planificacioacuten que permitan obtener elmaacuteximo rendimiento de los recursos por un lado y dar ciertas garantiacuteas de quetodas las tareas y procesos se van a ejecuta por otro
41 Sistemas distribuidos
En primer lugar se definen los sistemas distribuidos o clusters como unconjunto de ordenadores conectados entre siacute cuyo objetivo es trabajar como unauacutenica instancia de gran capacidad5
Su clasificacioacuten variacutea de acuerdo a cada autor pero en general se puedendividir seguacuten su objetivo en alto rendimiento aquellos cuyo objetivos es proveerde gran capacidad de coacutemputo gracias al conjunto de los nodos y alta disponi-bilidad con los cuales se busca la fiabilidad del sistema mediante redundanciayo balanceo de carga
El intereacutes de este proyecto recae en los uacuteltimos ya que el objetivo es porun lado ofrecer al desarrollador un entorno donde desplegar sus aplicaciones deforma distribuida y por otro maximizar el rendimiento de los recursos
De forma general las caracteriacutesticas que se buscan son las siguientes
Elasticidad Adaptacioacuten a cargas dinaacutemicas de trabajo aumentando (o dis-minuyendo) recursos de manera automaacutetica de tal forma que la utilizacioacutensea lo maacutes cercana a la demanda
Disponibilidad Capacidad de un sistema para mantener el servicio fun-cional
Tolerancia a fallos Recuperacioacuten del servicio ante el fallo de un compo-nente
Balanceo de carga Compartir las tareas entre las diferentes maacutequinasredundadas evitando asiacute puntos de uacutenico fallo
5httpsenwikipediaorgwikiComputer_cluster
8
Los programas que se implementan en entornos distribuidos se caracterizanpor ejecutarse de forma concurrente en equipos independientes estar conectadospor una red que introduce fallos aleatorios y no compartir memoria ni reloj Estoimplica entre otras cosas que
Los nodos soacutelo tienen un acceso raacutepido a su memoria local por lo quecualquier informacioacuten relativa al estado global puede ser potencialmenteerroacutenea
Las maacutequinas pueden sufrir caiacutedas de forma aleatoria
El intercambio de informacioacuten puede fallar ya sea por error en transmisioacuteno por caiacuteda de los nodos
Estas dificultades se ponen de manifiesto en el teorema de CAP en cienciasde la computacioacuten el teorema de CAP que lanzado inicialmente como conjetu-ra en el antildeo 2000 por Eric Brewer (motivo por el cual al teorema se le conoceformalmente como teorema de Brewer) y posteriormente demostrado en el antildeo20026 establece que es imposible para un sistema de coacutemputo distribuido ga-rantizar simultaacuteneamente dos de las tres propiedades siguientes
Consistencia (Consistency) es decir que todos los nodos vean la mismainformacioacuten al mismo tiempo Se busca que un cambio en el sistema soacutelose ejecute satisfactoriamente si y soacutelo si se efectuacutea a todos las maacutequinasde tal forma que los datos entre ellos nunca difieren y la respuesta a unapeticioacuten sea la misma independientemente del nodo que la atienda
Disponibilidad (Availability) esto es la garantiacutea de que toda peticioacuten debeobtener una respuesta (servicio funcional) aunque exista inconsistenciaentre nodos
Tolerancia al particionado (Partition Tolerance) es decir que el sistemasiga funcionado a pesar de un fallo en la comunicacioacuten entre los equipos
Por todo lo expresado anteriormente conseguir un sistema distribuido capazde ofrecer procesamiento de forma transparente implica una arquitectura TIcompleja Se requieren de subsistemas y herramientas que permitan la cohesioacutenentre todos los nodos
Gestor de los recursos de las diferentes maacutequinas
Monitorizacioacuten tanto de los servicios activos como de la funcionalidad delsistema ademaacutes de poliacuteticas para recuperacioacuten de fallo
Protocolos de consenso que permitan a los nodos ser consistentes con elestado global del cluster
6urlhttpsgroupscsailmitedutdspapersGilbertBrewer2pdf
9
Herramientas de descubrimiento de servicios que permita la comunicacioacutenentre tareas distribuidas
Planificadores Encargados de distribuir las tareas y procesos en las dife-rentes maacutequinas asignaacutendole parte de su capacidad
Los planificadores del ingleacutes cluster schedulers son un componente funda-mental por lo que vamos a entrar un poco maacutes en detalle en ellos
Planificadores (Cluster Schedulers)
Es el software encargado de monitorizar los recursos usados por cada maacute-quina perteneciente a un cluster y distribuir la carga de trabajo entre ellas deacuerdo a un poliacutetica o reglas
Este tipo de herramientas comparten cierta terminologiacutea que es relevantedefinir
Tarea Unidad de trabajo computacional comprendida por una secuenciade instrucciones datos de entrada y recursos asociados Por ejemplo laejecucioacuten de un comando o el arranque de una base de datos
Nodo Cualquier maacutequina integrante de un cluster En una arquitecturamaestro-esclavo se definen dos roles
bull Cliente Agente Esclavo Aquellos ordenadores que se encargan deejecutar las tareas
bull Maestro Servidor Su objetivo es mantener el estado del cluster ygestionar sus recursos
411 Clasificacioacuten
A lo largo de los uacuteltimos antildeos se han desarrollado diferentes tipos de plani-ficadores[2]
Monoliacutetico
Un solo planificador que se encarga de distribuir todas las tareas entran-tes La mayoriacutea de los planificadores en computacioacuten de alto rendimiento asiacutecomo Borg desarrollado por Google son de este tipo En la figura 3 se pue-de observar de forma graacutefica el procedimiento siendo las cajas grises maacutequinaspertenecientes al cluster y los ciacuterculos las tareas a asignar
10
Figura 3 Planificador monoliacuteticoFuente httpswwwclcamacuk
Planificacioacuten de dos niveles
La mayoriacutea de los clusters ejecutan aplicaciones con distintas necesidadesdesde procesos casi instantaacuteneos hasta servicios persistenteslo que implica dis-tintas necesidades de recursos
Por ello la planificacioacuten a dos niveles distingue dos funciones la gestioacutende recursos (gestor) y la disposicioacuten de las tareas (planificador) Cada serviciotiene su propio planificador de tal manera que el gestor les ldquoofertardquo recursosde acuerdo a una poliacutetica y los planificadores se encargan de escoger la maacutesadecuada Esto permite que el proceso de distribucioacuten sea maacutes acorde con lasnecesidades de los diferentes servicios Apache Mesos que detallaremos maacutesadelante sigue este esquema
Como desventaja cabriacutea sentildealar que esta programacioacuten implica que los pla-nificadores pierden la vista general de la infraestructura y las tareas soacutelo puedenejecutarse con los recursos que les son ofrecidos lo que dificulta la implementa-cioacuten de prioridades de ejecucioacuten de tareas entre otras
Figura 4 Planificador de dos niveles
11
Planificacioacuten de estado compartido
Muacuteltiples reacuteplicas del estado del cluster se actualizan independientementepara cada planificador como se observa en la figura 5 cuando sucede un cambiode forma local el planificador se encarga de informar al resto
Ejemplo de este tipo son Omega la evolucioacuten de Borg por parte de GoogleMicrosoft Apollo y Nomad que usaremos para los casos de uso
De entre las desventajas se puede destacar el hecho de que en general losnodos trabajan con informacioacuten desactualizada lo que conlleva una degradacioacutendel rendimiento en situaciones de alta contienda
Figura 5 Planificador de estado compartido
Planificacioacuten distribuida
En este caso no existe coordinacioacuten entre los distintos planificadores Cadauno de ellos funciona con su propia vista del cluster Las tareas pueden serorganizadas por cualquiera de ellos y desplegadas en cualquier parte del clusteren base a la aleatoriedad y multiplexacioacuten estadiacutestica de los flujos de trabajosin ninguacuten control central
Figura 6 Planificador distribuido
12
5 Herramientas
En la industria comienzan a aparecer soluciones software de coacutedigo abiertoque aglutinan los servicios necesarios para gestionar la infraestructura TI de ma-nera maacutes eficaz El objetivo es doble se busca facilitar la gestioacuten de los recursosde computacioacuten para organizaciones con instalaciones propias mediante su usocon un enfoque cloud esto es desplegar aplicaciones a traveacutes de un conjuntode ordenadores de forma transparente y sin tener en cuenta la infraestructurasubyacente o aprovechar el maacuteximo rendimiento de la infraestructura de losproveedores cloud puacuteblicos de forma que se tiene el maacuteximo control sobre eacutestapero no se depende de las soluciones propietarias permitiendo asiacute despliegueshiacutebridos
Entre estas herramientas se pueden destacar
OpenStack Proyecto desarrollado por la fundacioacuten del mismo nombre paraproporcionar servicios de infraestructuras (IaaS) basado en componentesque se comunican a traveacutes de APIs El componente Magnum incluye mo-tores de orquestacioacuten de contenedores
Kubernetes Sistema de orquestacioacuten de contenedores Docker creado por Goo-gle
CoreOs Sistema operativo basado en Linux disentildeado para despliegues distri-buidos sobre contenedores incluyendo mecanismos de descubrimiento deservicio y comparticioacuten de configuracioacuten
Docker Swarm Herramienta nativa de orquestacioacuten de contenedores Docker
YARN Entorno de gestioacuten de recursos y aplicaciones distribuidas de Hadoopuna libreriacutea software de procesamiento de grandes conjuntos de datos
Como podemos observar existe un gran rango de opciones para gestionar lainfraestructura desde un bajo nivel como puede ser OpenStack hasta Kuberne-tes o Docker Swarm que ofrecen exclusivamente orquestacioacuten de contenedores
En este trabajo se ha optado por Mesosphere DCOS y HashiCorp Nomadque se encuentran en el teacutermino medio su objetivo es proporcionar serviciosde plataforma que permitan la coexistencia dediferentes cargas de trabajo en elcluster
13
51 DCOS
DCOS es un proyecto de coacutedigo abierto7 creado y desarrollado por la empre-sa Mesosphere Se describe como un sistema operativo distribuido que abstraelos recursos de un cluster (capacidad de procesamiento memoria) permite lagestioacuten de muacuteltiples ordenadores de forma transparente y simplifica la instala-cioacuten de aplicaciones distribuidas
Su arquitectura se puede comparar a la de Linux en teacuterminos de nuacutecleo(kernel) y espacio de usuario El primero consta de recursos protegidos a losque no puede acceder el usuario e involucra operaciones de bajo nivel comoasignacioacuten de recursos o aislamiento de procesos En el espacio de usuario seejecutan las aplicaciones y servicios de maacutes alto nivel
Siguiendo con este siacutemil el nuacutecleo de DCOS estaacute basado en Apache Mesosque se explicaraacute en un apartado posterior y el espacio de usuario que estaacute com-prendido por los componentes del sistema esto es las diferentes herramientasque en conjunto conforman DCOS y los servicios encargados de planificar yejecutar las aplicaciones y tareas del usuario
Figura 7 Arquitectura DCOSFuente httpsdcosio
De entre los componentes que conforman DCOS destacan
Admin Router Balanceador de carga central basado en NGINX que dis-pone un proxy entre todos los servicios en el puerto 80 permitiendo sugestioacuten mediante la interfaz graacutefica Ademaacutes se encarga de la autenticacioacutenpara acceder al panel de administracioacuten
Cosmos Gestor de paquetes de las aplicaciones
Diagnostics Se ejecuta en todos los nodos y se encarga de monitorizar elestado de los daemons que sustentan DCOS
7Desde abril de 2016 httpsmesospherecomblog20160419open-source-dcos
14
Exhibitor Gestiona y automatiza el despliegue de ZooKeper la herra-mienta que provee de configuracioacuten centralizada y registro de nombres
Marathon Equivale al proceso init de los sistemas tipo Unix esto es elprimer proceso en ejecucioacuten tras la carga del kernel y que genera los demaacutesprocesos Se encarga de arrancar y monitorizar las aplicaciones y servicios
Mesos-DNS Servicio de DNS interno que define el dominio mesos pa-ra nodos y tareas en el cluster es decir permite resolver nombres conindependencia de la direccioacuten fiacutesica
Minuteman Balanceador de carga integrado a nivel TCPUDP disponiblepara las propias aplicaciones
Por otra parte se definen como servicios a las diferentes aplicaciones dis-tribuidas que DCOS permite instalar en el cluster y que pueden haber sidodesarrollados por la misma empresa Mesosphere o por terceros por ejemploApache Spark Jenkins o Apache Hadoop En la figura 8 se muestra un diagramade los servicios disponibles incluyendo algunos de las aplicaciones distribuidasque soporta DCOS
Figura 8 Servicios DCOSFuente httpsdcosio
511 Apache Mesos
El nuacutecleo de DCOS estaacute basado en Apache Mesos un proyecto de coacutedigoabierto creado por la Universidad de California Berkeley y desarrollado actual-mente por la fundacioacuten Apache Se trata de un administrador de clusters queabstrae los recursos y los dispone para diferentes aplicaciones y entornos de tra-bajo distribuidos (frameworks) mediante una interfaz comuacuten En el momento deredaccioacuten de este proyecto Apache Mesos soportaba una variedad de entornosque abarcaba desde Big Data (Apache Spark Hadoop) hasta bases de datos(Cassandra Hypertable)
15
Arquitectura
Mesos se basa en la asignacioacuten de dos roles diferentes a los nodos
Maestros (Masters) Se encargan de la gestioacuten y reparticioacuten de los recursospara los diferentes entornos de trabajo mediante ldquoofertas de recursosrdquo deacuerdo a los disponibles y a la poliacutetica de asignacioacuten (planificacioacuten en dosniveles)
Esclavos (Slaves) Ordenadores donde se ejecutaraacuten las aplicaciones y cu-yos recursos son ofertados por los maestros
En el caso de fallo del maestro las tareas pueden seguir ejecutaacutendose perono se podraacute asignar nuevos recursos ni tareas por ello pueden existir varios enel cluster para configuraciones de alta disponibilidad pero soacutelo uno orquesta alos esclavos
Para la eleccioacuten del master liacuteder Mesos usa Apache ZooKeeper un proyectode software desarrollado por la misma fundacioacuten cuyo objetivo es proveer deun servicio de configuracioacuten centralizado y registro de nombres8
Por otra parte los entornos de trabajo son los programas que deciden final-mente queacute recursos se van a usar y se encargan de que los esclavos ejecuten lastareas Eacutestos se ejecutan sobre Mesos y constan de dos componentes
Planificador (Scheduler) Optimiza y decide los recursos a utilizar de losofertados informando a los Masters
Procesador (Executor) Ejecuta las aplicaciones o servicios en los esclavos
El objetivo final es conseguir una interfaz liviana tolerante a fallos paracualquier tipo de entorno de trabajo de tal manera que en los esclavos del clusterpuedan ejecutarse simultaacuteneamente tareas con necesidades y duracioacuten diferentesPara ello se basa en dos conceptos asignacioacuten y aislamiento de recursos
Asignacioacuten de recursos
En el cluster pueden coexistir entornos de trabajo con tareas de larga dura-cioacuten y con gran consumo de recursos con tareas cortas que los ocupan y liberancon rapidez El maestro integra un moacutedulo de asignacioacuten de recursos (allocationmodule) que se encarga del algoritmo de distribucioacuten
En el momento de escribir este proyecto estaban desarrollados dos moacutedulosuno mediante el cual el usuario puede asignar prioridades y otro que implementa
8httpszookeeperapacheorg
16
el algoritmo Dominant Resource Fairness9 a grandes rasgos se determina entodos los esclavos la tarea en ejecucioacuten que necesita maacutes recursos y se calcula laproporcioacuten del recurso de mayor peso con respecto al total por ejemplo si unatarea ocupa 2 GB de memoria con respecto a 10 GB totales que tiene el clusterse le asigna un dominant share del 20 la tarea se asignaraacute al nodo con menordominant share
Aislamiento de recursos
Para conseguir que tareas de diferentes entornos de trabajo y con distin-ta naturaleza se ejecuten simultaacuteneamente en un mismo nodo Mesos usa loscontenedores Linux (descritos en la seccioacuten 3)
Funcionamiento
La figura 9 muestra el esquema de la arquitectura de Apache Mesos conalta disponibilidad (tres maestros) y con dos entornos de trabajo ejecutaacutendo-se Hadoop que permite el almacenamiento y procesamiento de gran cantidadde datos para proyectos de big data y un sistema que implementa la interfazsistema de paso de mensajes MPI
Como se puede observar el sistema ZooKeeper elige a un solo maestro comoliacuteder y eacuteste orquesta el cluster comunicando los esclavos con los planificadoresde los diferentes entornos de trabajo Tambieacuten se puede observar como las tareasde los distintos entornos estaacuten distribuidas entre los tres esclavos disponibles
Figura 9 Arquitectura de Apache MesosFuente httpsmesosapacheorg
El proceso de asignacioacuten se realiza como sigue en primer lugar un usuariosolicita la ejecucioacuten de una tarea mediante la interfaz de cada entorno de traba-jo (interfaz graacutefica API HTTP ) De forma paralela un esclavo informa almaestro de los recursos que tiene libres En consecuencia eacuteste se lo notifica almoacutedulo de asignacioacuten que en funcioacuten de su configuracioacuten decide cuaacutento ofertar
9httpspeopleeecsberkeleyedu~aligpapersdrfpdf
17
y a queacute entorno de trabajo y enviacutea la oferta a los planificadores Eacutestos respondenal maestro con queacute recursos ha decidido usar para cada tarea Finalmente lastareas son enviadas al esclavo seleccionado el cual asigna los recursos indicadosal procesador (executor) quien finalmente las ejecuta
Cabriacutea pensar que esta metodologiacutea puede conducir a situaciones en lasque un entorno podriacutea quedarse con tareas sin ejecutarse a la espera de unaoferta satisfactoria para ello Mesos implementa un sistema de filtros medianteel cual los entornos especifican los requisitos miacutenimos que debe cumplir unaoferta por ejemplo se puede especificar en queacute nodos debe desplegarse la tareaEste sistema estaacute disentildeado asiacute con el objetivo de mantener lo maacutes transparenteposible esta herramientas de forma que acepte entornos de trabajo de distintasnaturalezas
512 Ejemplos de uso
Grandes empresas estaacuten usando Apache Mesos con eficacia de acuerdo a susnecesidades e infraestructuras Caben destacar
Ebay En el modelo de implementacioacuten continua en esta empresa10 cadadesarrollador cuenta con su propia instancia que se ejecuta en una maacutequinavirtual dedicada lo que ha conllevado un uso de los recursos poco eficiente Enuna prueba de concepto consiguieron realizar una herramienta de integracioacutencontinua distribuida basada en un cluster con Apache mesos y con el entornoMarathon y Jenkins
Apple Anuncioacute que el motor de su famosa herramienta de asistencia per-sonal para iPhones Siri estaacute desplegada sobre Apache Mesos11 Para ello handesarrollado su propio entorno para facilitar a los ingenieros a desplegar los ser-vicios que la herramienta necesita para resolver las peticiones de los usuarios
Twitter Desarrolloacute su propio entorno denominado Aurora y actualmentegestionan sus recursos y miden el coste de las tareas que los empleados usancon el objetivo de que sean conscientes del gasto que puede suponer un usoinadecuado de la infraestructura12
10httpwwwebaytechblogcom20140404delivering-ebays-ci-solution-with-apache-mesos-part-i11httpwwwbusinessinsidercomapple-siri-uses-apache-mesos-2015-812httpswwwlinuxcomNEWS4-UNIQUE-WAYS-UBER-TWITTER-PAYPAL-AND-HUBSPOT-USE-APACHE-MESOS
18
52 Nomad
Herramienta de coacutedigo abierto de gestioacuten de clusters creada y desarrolladapor Hashicorp13 que permite el despliegue de aplicaciones y procesos de formadistribuida
Las principales diferencias con Apache Mesos a grandes rasgos son
Arquitectura maacutes ligera Nomad soacutelo requiere de un fichero para funcionarejecutaacutendolo con las correspondientes configuraciones en todos los nodosrealiza las funciones de gestioacuten del cluster eleccioacuten de liacuteder planificacioacutende recursos y ejecucioacuten de las tareas
Centro de datos y regiones muacuteltiples Su arquitectura estaacute orientada afacilitar la gestioacuten de diferentes centros de datos geograacuteficamente distri-buidos
Entorno de ejecucioacuten Las tareas se definen y son interpretadas mediantecontroladores integrados en Nomad que se valen de los recursos y herra-mientas de los nodos clientes para ejecutarlas Esta integracioacuten dificultael desarrollo de controladores por parte de terceros a diferencia de Mesosque delega dicha responsabilidad en los entornos de trabajo externos alproyecto
Usa un planificador de estado compartido con respecto a la planificacioacutenen dos niveles de Mesos
Antes de entrar en maacutes detalle en la arquitectura es importante definir lossiguientes teacuterminos
Controlador (Driver) Software que se encarga de interpretar las definicionesde las tareas y ejecutarlas semejante a los procesadores de los entornosde trabajo de Mesos A la hora de redactar este proyecto Nomad contabacon controladores para contenedores Docker virtualizacioacuten de maacutequinasmediante el emulador QEMU aplicaciones java y archivos binarios
Grupo de trabajo (Task Group) Conjunto de tareas que se ejecutan en elmismo nodo cliente
Trabajo (Job) Conjunto loacutegico de tareas y grupos de trabajo que se despliegana la vez
Asignacioacuten (Allocation) Relacioacuten entre un grupo de trabajo y el cliente don-de se ejecuta
Evaluacioacuten (Evaluation) Proceso mediante el cual Nomad planifica y ges-tiona el registro o actualizaciones de los trabajos
13httpswwwhashicorpcom
19
Nomad sigue una arquitectura maestro-esclavo similar a la de Apache Mesosmuacuteltiples servidores acuerdan entre siacute un liacuteder que gestiona la planificacioacuten detareas en los clientes que soacutelo conocen sus asignaciones y las ejecutan
Todos los servidores participan paralelamente en tareas de planificacioacuten derecursos y asignacioacuten de tareas y ademaacutes entre ellos eligen un liacuteder que seencarga de la coordinacioacuten de la suscripcioacuten de los clientes al cluster y de lagestioacuten de las peticiones
Los clientes estaacuten configurados para comunicarse con el servidor usando lla-madas a procedimiento remoto (RPC por sus siglas en ingleacutes) que permite unordenador ejecutar coacutedigo en otra maacutequina Mediante esta tecnologiacutea los nodosclientes avisan de su estado e informa de sus asignaciones recursos y controla-dores disponibles
Existe la posibilidad de gestionar varios centros de datos agrupados en regio-nes eacutestas son independientes pero permite definir tareas o comprobar el estadode todas ellas desde cualquier punto A continuacioacuten se muestra una figura dela arquitectura a alto nivel de esta configuracioacuten
Figura 10 Arquitectura multi-regioacuten en NomadFuente httpswwwnomadprojectio
La herramienta se sustenta sobre tres protocolos fundamentales un protocolode consenso entre los servidores para compartir informacioacuten sobre su estado yel liacuteder un protocolo Gossip para la gestioacuten entre regiones y el planificador detareas
521 Protocolo de consenso Raft
El objetivo es obtener consistencia en un conjunto de nodos que comparteninformacioacuten es decir si un cliente realiza un cambio que todos los nodos veanla misma informacioacuten a la vez y ademaacutes sea tolerante a fallos Para ello se basaen el algoritmo Raft[13] que se detalla brevemente a continuacioacuten
20
Los nodos participantes en el algoritmo pueden estar en tres estados
Liacuteder (Leader) Todos los cambios que realicen en el cluster pasan por eacutel pri-mero
Seguidor (Follower) Nodo pasivo cuya responsabilidad es responder a laspeticiones del nodo liacuteder
Candidato (Candidate) Maacutequina que no ha encontrado liacuteder y solicita sueleccioacuten
Supongamos que tenemos cinco equipos que acaban de arrancar el protocoloEn la figura 11 se observan los nodos y sus respectivos registros a la derecha
Figura 11 Equipos sin consenso ejecutando el protocolo RAFTFuente httpsgithubcomongardieraftscope
Al comenzar todos los nodos son seguidores esperando recibir comunicacioacutende un nodo que actuacutee como liacuteder Cada nodo tiene un tiempo de espera aleatoriodespueacutes del cual si no es informado por un liacuteder pasa a estado candidato y pideel ldquovotordquo al resto de los participantes El algoritmo divide el tiempo en plazos uncandidato pasa a liacuteder si recibe la mayoriacutea de los votos en un plazo determinadoSe define mayoriacutea o cuoacuterum (quorum) comolceil
N2rceil
+ 1 (1)
donde N representa el nuacutemero de nodos
Para el ejemplo propuesto de 5 equipos se requieren de 3 votos Soacutelo losnodos que se encuentren en estado seguidor pueden votar una uacutenica vez a laprimera solicitud que reciba dentro de un plazo
Supoacutengase que el nodo denotado con S1 ha cumplido su tiempo de espera yrealiza la peticioacuten de voto (figura 12) A partir de este momento se pueden dartres casos
La maacutequina gana la eleccioacuten y pasa a ser liacuteder informando al resto
Otro servidor se establece como liacuteder en el mismo momento
Varios nodos pasan a ser candidatos por lo que ninguno consigue los votos
21
Figura 12 Un equipo pasa a estado candidato (RAFT)
Si un candidato recibe un aviso de un liacuteder en el mismo plazo el primeropasa a ser seguidor y se acaba la eleccioacuten de liacuteder
Por otro lado si un equipo candidato no recibe los votos en el plazo y agotasu tiempo de espera avanza al siguiente plazo y repite el proceso de votacioacutenLa tercera posibilidad puede conllevar a un estado indefinido ya que varioscandidatos pueden agotar su tiempo de espera al mismo tiempo y repartir losvotos Para solventarlo el algoritmo establece tiempos de espera aleatorios paralos candidatos
Siguiendo con el ejemplo propuesto el servidor S1 pasa a ser el liacuteder Cadacierto tiempo eacuteste debe realizar avisos a los nodos seguidores para no agotar sutiempo de espera
En este momento el cluster de servidores estaacute en ldquoconsensordquo y la informacioacutenen todos los nodos estaacute actualizada Un cambio en la informacioacuten inicia unproceso de replicacioacuten el liacuteder registra el cambio lo pasa al resto de nodos yuna vez eacutestos responden el cambio se hace efectivo
Supoacutengase que se realiza un cambio en los datos en la figura 13 en la partederecha se observa el cambio en el registro del servidor S1 que informa a losnodos seguidores En consecuencia los nodos registran el cambio y responden aS1
Figura 13 Cambio en un registro (RAFT)
Una vez el cuoacuterum (en el ejemplo tres equipos) informa al liacuteder de que
22
ha registrado el cambio el liacuteder lo hace efectivo en su sistema y notifica a losnodos que hacen lo mismo En la figura 14 el enviacuteo todaviacutea no ha llegado ala maacutequina S3 y se observa que no ha hecho efectivo el cambio (en el registroaparece punteado)
Figura 14 Aprobacioacuten del resto de equipos (RAFT)
Este protocolo funcionaraacute correctamente mientras exista un nuacutemero de nodosen funcionamiento igual o superior al cuoacuterum en el ejemplo propuesto elcuoacuterum es tres por lo que el sistema puede tolerar la caiacuteda de dos de los equipos
522 Protocolo gossip SWIM
Nomad permite la gestioacuten simultaacutenea de varios centros de datos reparti-dos en regiones geograacuteficamente separadas requiriendo de un protocolo ligeroque mantenga a los miembros actualizados sobre los participantes del conjun-to Para ello usa una ligera variante del protocolo SWIM[3] (Scalable Weakly-consistent Infection-style Process Group Membership Protocol) desarrollada porHashiCorp Estaacute clasificado como un protocolo de tipo gossip que debe su nom-bre a la semejanza con coacutemo se distribuye un rumor en una red social
SWIM se sustenta en dos caracteriacutesticas fundamentales la deteccioacuten de fallosy la distribucioacuten de la informacioacuten relativa a los miembros A continuacioacuten sedetalla el funcionamiento de ambos componentes
Deteccioacuten de fallos
Este componente tiene dos paraacutemetros el periodo de protocolo T y el nuacutemerode subgrupos de deteccioacuten de fallos k en los que se dividen los nodos Paracomprobar la comunicacioacuten entre dos maacutequinas usa la utilidad ping basadaen el protocolo ICMP La deteccioacuten de caiacuteda de un servidor sigue el siguientealgoritmo
Durante el periodo T cada miembro Mi de un subgrupo elige otro al azar Mjdel mismo subgrupo y le enviacutea un mensaje ping para comprobar su estado Enel caso de que se cumpla un tiempo de espera determinado por una estimacioacuten
23
del tiempo de ida y vuelta (RTT por sus siglas en ingleacutes) de la red y no hayarespuesta Mi le vuelve a enviar un mensaje ping indirectamente a traveacutes deun nuacutemero k de miembros escogidos aleatoriamente De no recibir ninguna res-puesta Mi establece que Mj ha sufrido un fallo y lo etiqueta como ldquosospechosordquoinformando al componente de distribucioacuten
Figura 15 Diagrama de tiempo del protocolo SWIMFuente httpswwwcscornelledu
Componente de distribucioacuten
Se encarga de informar de cualquier cambio en los miembros a todo el con-junto Los eventos de nodo caiacutedo y la unioacuten o disociacioacuten de un miembro setransmiten a todos los servidores para que actualicen sus lista Para distribuirla informacioacuten a todos los nodos se podriacutea usar el meacutetodo de multicast perosuele estar deshabilitado Por ello se utiliza una teacutecnica de transmisioacuten denomi-nada Piggybacking mediante la cual se adjunta a los propios mensajes PINGy ACK del algoritmo la informacioacuten a distribuir reduciendo asiacute la congestioacutenen la red
523 Planificacioacuten
Proceso encargado de distribuir las tareas entre los nodos clientes de acuerdoa su estado
El planificador de Nomad estaacute basado en las publicaciones de Google sobresus herramientas de gestioacuten de clusters Borg y Omega14 y entiende los trabajosdescritos por el usuario como un estado deseado es decir su despliegue en unamaacutequina cliente de forma correcta y los clientes como el estado actual esto eslo que se encuentra en ejecucioacuten El registro actualizacioacuten o cancelacioacuten de un
14httpresearchgooglecompubspub43438html
24
trabajo asiacute como el fallo de un nodo cliente implican un cambio de estado atramitar por el sistema lo que se define como evaluacioacuten (evaluation) Esto uacutelti-mo supone comparar el estado actual (clientes) con el estado deseado (conjuntode trabajos registrados) y enviarlos a los planificadores correspondientes que seencargaraacuten de asignar las tareas a los nodos clientes
Figura 16 Procedimiento de asignacioacuten en NomadFuente httpswwwnomadprojectio
En la figura 16 se observa el flujo de trabajo en el que las distintas evalua-ciones se encolan en el evaluation broker que se ejecuta en el servidor liacuteder ygestiona las evaluaciones pendientes asignaacutendoles prioridades
A continuacioacuten los nodos servidores ejecutan los scheduling workers queprocesan las evaluaciones llamando a los distintos planificadores que generanun plan de asignacioacuten esto es un conjunto de relaciones entre las tareas y losnodos clientes donde se ejecutaraacuten Este proceso se divide en dos fases primerose descartan aquellos clientes que no cumplan los requisitos y posteriormentese asigna una calificacioacuten al resto Se selecciona el nodo con mayor puntuacioacuteny se encola el plan en el gestor que se ejecuta en el servidor liacuteder Existen tresplanificadores de acuerdo al tipo de trabajo
Service Incluye aquellos trabajos que estaacuten destinados a ejecutarse en un pe-riacuteodo largo de tiempo Para realizar las asignaciones el planificador evaluacuteala mayor parte de los nodos y usa una versioacuten del algoritmo Best fit in-fluenciada por el trabajo de Google en su herramienta Borg Se trata deun algoritmo de planificacioacuten que sacrifica tiempo a cambio de maximizarel rendimiento de los clientes asignando la tarea a la maacutequina que tengala mayor carga de trabajo con el objetivo de reducir equipos en funciona-
25
miento
Batch Tareas que incluyen listas de comandos en general de menor duracioacuteny que no requieren interaccioacuten con el usuario Se vale del algoritmo deSparrow desarrollado por la universidad de Berkeley15 para limitar losnodos clientes a evaluar
System Trabajos destinados a ejecutarse en todos los nodos incluso los que seunen al cluster posteriormente
Core Mantenimiento interno de Nomad
Una vez se ha realizado el proceso de planificacioacuten el nodo liacuteder lo registra enla cola de planes (plan queue) que se encarga de asignarles prioridad y manejarcondiciones de carrera es decir que no accedan a los recursos de los clientes sincontrol y evitar que eacutestos superen su capacidad
La maacutequina liacuteder del conjunto puede de este modo aceptar una asignacioacuteny ser ejecutada por los clientes o por el contrario rechazaacutersela al planificadorlo que implicariacutea realizar un plan parcial o totalmente nuevo
Finalmente el estado de las evaluaciones se actualizan y los clientes soninformados de las asignaciones ejecutaacutendose las tareas
15httppeopleeecsberkeleyedu~keopublicationssosp13-final17pdf
26
6 Casos de uso y despliegue
Con el objetivo de mostrar las posibles utilidades que este tipo de sistemaspueden tener en las infraestructuras TI actuales se han desplegado las dos he-rramientas en la nube Microsoft Azure usando su servicio cloud de instancias demaacutequinas virtuales Linux para simular un conjunto de ordenadores conectadosentre siacute por una red LAN Sobre ellas se ha implementado dos casos de usouna aplicacioacuten web con una arquitectura con cierta orientacioacuten a microserviciosy un sistema de integracioacuten continua
El coacutedigo y todos los ficheros de configuracioacuten se pueden encontrar en elrepositorio del proyecto en GitHub16
61 Aplicacioacuten Web
Se busca simular el proceso de adaptacioacuten de una solucioacuten web para su des-pliegue en un sistema distribuido con las herramientas anteriormente descritascon el objetivo de aumentar tanto su escalabilidad como disponibilidad medianteredundancia
Se ha partido de una aplicacioacuten ya existente17 un servicio de almacenamien-to y reproduccioacuten de canciones A grandes rasgos este servicio permite crearusuarios subir canciones con sus respectivas portadas tener playlists propias yescuchar las canciones a traveacutes de un navegador web
La solucioacuten estaacute dividida en 4 partes (figura 17)
Una vista web con la loacutegica
Un almacenamiento conectado en red (NAS por sus siglas en ingleacutes)
Una API REST para gestionar las peticiones al almacenamiento
Base de datos NoSQL basada en MongoDB
La nueva tendencia de los proyectos web es su implementacioacuten en contene-dores Docker ya que facilitan su portabilidad y ofrecen un procedimiento dedespliegue raacutepido sobre todo a la hora de desarrollar y realizar pruebas en en-tornos de produccioacuten simulados Por ello en este caso se va a hacer uso de los
16httpsgithubcomAntonioAlfrzCloud-Orchestrators17httpsgithubcomsonsoleslpCDPSfy
27
motores de orquestacioacuten de contenedores de ambas herramientas Marathon enDCOS y el controlador Docker en el caso de Nomad
Figura 17 Arquitectura aplicacioacuten web
A continuacioacuten vamos detallar el despliegue en ambas herramientas de es-ta solucioacuten y observar tanto queacute dificultades se encuentran como que ventajasofrecen El objetivo final es adaptar el proyecto modificaacutendolo lo menos posiblecon objeto de analizar la capacidad de estas herramientas para desplegar cual-quier aplicacioacuten sin que eso conlleve la modificacioacuten de la arquitectura de eacutestaes decir que no sea dependiente del entorno
611 DCOS
Se ha descrito DCOS como una herramienta que se despliega sobre un con-junto de ordenadores y que permite instalar gestionar el despliegue de sistemasdistribuidos
Microsoft Azure cuenta con una plantilla para desplegar en su servicio cloudun cluster de maacutequinas virtuales con DCOS ya instalado que cuenta con
Maacutequinas maestras (1 3 o 5 a seleccionar por el usuario) configuradascomo un conjunto de disponibilidad esto eso Azure da ciertas garantiacuteasde que al menos una maacutequina estaraacute en funcionamiento
Maacutequinas agentes Por motivos de seguridad se distinguen dos roles
bull Nodos privados solo accesibles desde la red interna y configuradoscomo un conjunto de escala un recurso de Azure para gestionar ydesplegar maacutequinas con configuraciones ideacutenticas para permitir unraacutepido escalado
bull Un equipo conectado accesible desde Internet a travntildees de un balan-ceador de carga puacuteblico y situado en una subred externa
28
Dos balanceadores de carga
bull La interfaz puacuteblica del cluster que se conecta con el cliente puacuteblicobull Acceso a los equipos maestros para el administrador que soacutelo permiteconexioacuten mediante SSH y credenciales
Almacenamiento para todas las maacutequinas
Configuraciones necesarias de red y seguridad
En la figura 18 se observa un diagrama de la infraestructura
Figura 18 Infraestructura en Azure
El primer obstaacuteculo es la persistencia de estado de la aplicacioacuten que seconsigue gracias a una base de datos no relacional basada en MongoDB asiacutecomo el almacenamiento de las canciones Para implementarla tenemos variasposibilidades
Montar un sistema externo de almacenamiento conectado en red en todoslos agentes donde se ejecuten las tareas de esta manera si una tarea pasade un nodo a otro por cualquier motivo puede tener acceso a los mismosficheros (opcioacuten del caso de uso original)
Implementar un sistema de ficheros distribuidos en los agentes
Usar los servicios de almacenamiento de las nubes puacuteblicas
Aprovechar el sistema de voluacutemenes persistentes de Apache Mesos Eacutestepermite reservar recursos de un agente de forma que al arrancar una tarease crea un volumen independiente del ciclo de vida de eacutesta con ello esosrecursos donde se ha almacenado la informacioacuten pueden volver a ofrecerseal mismo entorno de tal manera que otra tarea pueda acceder a ella
DCOS aprovecha este sistema de voluacutemenes persistentes y permite instalarbases de datos distribuidas como ArangoDB o Apache Cassandra sin embargoesto implicariacutea modificar todo el coacutedigo referente al modelo de la base de datos
29
Por motivos de eficiencia y latencia asiacute como de una mayor gobernabilidadde los datos la mejor opcioacuten es usar el recurso de voluacutemenes persistentes queofrece Apache Mesos ya que de esta manera se gestionariacutea la aplicacioacuten completamediante una uacutenica herramienta Sin embargo esto implica que la informacioacutense encuentra exclusivamente en el agente donde se haya ejecutado la tarea y porlo tanto se sigue requiriendo de software externo para distribuir la informacioacutenpara que se accesible para todos los agentes A la hora de realizar este proyectose encontraba en desarrollo Flocker una solucioacuten desarrollada por ClusterHQque permite compartir los voluacutemenes de Docker a traveacutes de un cluster quesi bien es compatible con el planificador de Mesos el proyecto se encontrabatodaviacutea en fases tempranas de desarrollo y los sistemas de almacenamiento quesoporta quedaban fuera del aacutembito de este trabajo
Por todo ello dado que las maacutequinas se han desplegado en la nube puacuteblicade Azure se decidioacute usar su servicio de almacenamiento de objetos para lascanciones y otra maacutequina para desplegar MongoDB y asiacute mantener el modelode datos original de la aplicacioacuten La diferencia del almacenamiento de obje-tos con respecto a nivel de fichero es que el primero no tiene jerarquiacutea paraorganizar los archivos eacutestos se guardan como objetos (con sus metadatos) enun mismo espacio soacutelo diferenciaacutendose por un identificador uacutenico esto implicaentre otras cosas que se puede acceder a un fichero dado uacutenicamente su IDindependientemente de la localizacioacuten fiacutesica de eacuteste facilitando pues la gestioacuteny el desarrollo
El coacutedigo del proyecto se ha modificado en los siguientes apartados
Las direcciones de la base de datos y los balanceadores de carga asiacute comosus puertos estaban originalmente fijos Se han configurado como variablesde entorno para facilitar el descubrimiento del servicio y hacer transpa-rente la aplicacioacuten al entorno de despliegue
La API REST se ha adaptado al almacenamiento en Azure en vez de enlocal
Estas modificaciones no suponen un cambio sustancial pero permiten separala persistencia de las tareas ejecutadas por DCOS lo que facilita en granmedida su ejecucioacuten al ser totalmente sin estado y ademaacutes implican tenerlos datos bajo un mayor control
Para la orquestacioacuten de contenedores se va a usar el entorno Marathondesarrollado tambieacuten por Mesosphere Eacuteste se puede usar a traveacutes de una interfazgraacutefica la interfaz de liacutenea de comandos (en lo que sigue CLI por sus siglas eningleacutes) de DCOS o con su API HTTP
Primero se han publicado la imaacutegenes de los contenedores que encapsulanla interfaz web y la api de la aplicacioacuten en el repositorio puacuteblico DockerHub
Los despliegues en este entorno se describen mediante ficheros JSON en losque se detalla entre otras opciones la imagen del contenedor los puertos a usar
30
los recursos que debe ocupar en un nodo o las instrucciones de monitorizacioacuten
Para el servicio de descubrimiento DCOS ofrece la posibilidad de asignardirecciones IP virtuales (VIP por sus siglas en ingleacutes) a tareas que se compartenen todos los nodos DCOS lleva integrado un balanceador de carga a nivel TCP(el componente denominado Minuteman) que balancea entre las direccionesvirtuales de las tareas y todas las instancias de eacutestas a lo largo del cluster Estoes necesario por dos motivos equilibrar la carga de los equipos con el fin deevitar un punto de uacutenico fallo mediante redundancia y evitar la contienda dedirecciones al ejecutar las tareas en puertos aleatorios
Este balanceador de carga estaacute basado en el trabajo de Michael Mitzenma-cher The Power of Two Choices in Randomized Load Balancing18 A grandesrasgos el algoritmo mantiene una media moacutevil exponencial de latencias paracada destino (backend) ademaacutes de las caiacutedas consecutivas Si un destino noresponde a una negociacioacuten en tres pasos (three way handshake) de forma con-secutiva en un periodo inferior a 5 ms se considera caiacutedo El algoritmo iterasobre los destinos disponibles en base a su histoacuterico de fallos y escoge dos deforma aleatoria de los cuales coge el de mejor meacutetrica
Las direcciones virtuales soacutelo se pueden resolver dentro del cluster porello para implementar la interfaz puacuteblica de la aplicacioacuten esto es el balancea-dor de carga de la interfaz web usaremos un paquete de DCOS denominadomarathon-lb un balanceador basado en HAProxy y adaptado por MesosphereEn este caso equilibra la carga de todas instancias de las tareas ejecutadas porel entorno Marathon por sus etiquetas y permite ademaacutes definir como puntode entrada muacuteltiples hosts virtuales definidos por sus nombres completos dedominio (FQDN por sus siglas en ingleacutes) en nuestro caso la interfaz puacuteblicadel balanceador de Azure para los agentes
Por motivos de seguridad todas las tareas se ejecutan en los agentes privadoses decir los que son exclusivamente accesibles desde la red interna Por su partemarathon-lb se ejecuta en el agente puacuteblico que cuenta con IP puacuteblica y lospuertos 80 (HTTP) y 8080 abiertos de forma que la aplicacioacuten sea accesibledesde Internet Esto es posible debido a que Apache Mesos permite reservarrecursos mediante roles asignados a nodos para un uso especiacutefico De esta formala arquitectura vista desde la aplicacioacuten quedariacutea como en la figura 19
18httpswwweecsharvardedu~michaelmpostscriptstpds2001pdf
31
Figura 19 Arquitectura de la aplicacioacuten web en DCOS
Ejecucioacuten
A la hora de desplegar la aplicacioacuten DCOS puede gestionarse medianteuna interfaz graacutefica o una interfaz de liacutenea de comandos La primera se accedea traveacutes de un navegador web en el puerto 80 (HTTP) y permite instalar losentornos disponibles observar el estado de los nodos y las tareas que se estaacutenejecutando y los ficheros de registros que eacutestas generan
La CLI permite el control desde un nodo o una maacutequina remota (suponiendoque los maestros tienen IP puacuteblica y el puerto 80 abierto) ya que DCOS tieneun sistema de autorizacioacuten que permite tener una interfaz puacuteblica con ciertasgarantiacuteas de seguridad
Por su parte cada entorno de trabajo puede ser controlado por la CLI peroademaacutes cuenta con sus propias interfaces Marathon expone una API HTTPen el puerto 8080 de la direccioacuten puacuteblica de los maestros del cluster asiacute comootra interfaz graacutefica Para desplegar un contenedor se podriacutea usar la CLI
$ dcos marathon app add lt f i l e j songt
O la API HTTP
$ cu r l minusX POST http lt ip_maestro gt8080v2apps minusd ltf i l e jsongt minusH Contentminustype app l i c a t i o n j son
32
612 Nomad
La arquitectura de Nomad es maacutes sencilla ya que solo requiere de un ficheroejecutable en todos los nodos para funcionar Si DCOS es la base de instala-cioacuten de entornos de terceros Nomad integra todas las funcionalidades baacutesicasesto es gestor de recursos planificador y ejecutor en los nodos cliente Estaherramienta cuenta con un menor tiempo de desarrollo y en el momento deescribir este documento cuenta exclusivamente con los siguientes controladoresen comparacioacuten con los entornos de DCOS
Motor Docker es decir funcioacuten de orquestacioacuten de contenedores
Ejecucioacuten de archivos binarios como comandos de Shell
Ejecucioacuten de aplicaciones Java
Virtualizacioacuten de maacutequinas mediante tecnologiacutea QEMU
Todos ellos necesitan que la tecnologiacutea subyacente esteacute instalada en las maacute-quinas clientes (Docker Java QEMU) Actualmente no permite el registro decontroladores por parte de terceros aunque estaacute planificado en un futuro ofreceruna interfaz para su desarrollo
Nomad no cuenta con el servicio de descubrimiento sin embargo puede inte-grarse con la herramienta Consul desarrollada por la misma empresa Por otrolado para el balanceo de carga usaremos un contenedor Docker con HAProxyuna herramienta de coacutedigo abierto que ofrece tanto servicios de proxy como debalanceador y cuyos ficheros de configuracioacuten completaremos con el proyectoConsul Template19
Consul
Consul sigue la misma arquitectura que Nomad es decir un nodo servidorque orquesta un conjunto de maacutequinas clientes y permite a los procesos que seejecutan en los equipos definirlos como servicios ofreciendo diversas caracteriacutes-ticas entorno a estos de los cuales vamos a usar dos
Descubrimiento de servicio Las maacutequinas clientes publican en el cataacutelogode servicios las tareas en ejecucioacuten y Consul les asigna nombres de dominioaccesibles por todos los miembros del cluster a traveacutes de la interfaz DNSincluida en esta herramientaConsul se integra con Nomad de forma que todas las tareas que se ejecu-ten en la segunda son automaacuteticamente publicados como servicios de laprimera de esta manera no hace falta conocer la direccioacuten de la maacutequinacliente donde se esteacute ejecutando el proceso ya que se puede acceder a eacutela traveacutes de su nombre de dominio de forma transparente Por ejemplo si
19[httpsgithubcomhashicorpconsul-template]
33
ejecutamos una tarea con ID web en el puerto 8080 se puede acceder aella en la direccioacuten webserviceconsul8080Para que las direcciones propias de Consul las resuelva su propio DNS y noel que esteacute asignado por defecto en la maacutequina usaremos la herramientadnsmasq20 que permite especificar la direccioacuten de un servidor DNS paraconsultas de direcciones especiacuteficas
Monitorizacioacuten Permite realizar comprobaciones del servicio y seguir su esta-do Aprovecharemos esta funcionalidad tanto para definir el propio procesode Nomad como servicio de Consul como las tareas desplegadas
HAProxy + Consul Template
HAProxy es una solucioacuten versaacutetil de coacutedigo abierto que ofrece solucionesde balanceo de carga y proxy Existen otras herramientas en el mercado comoNGINX o ldirectord sin embargo HAProxy suponiacutea una solucioacuten sencilla deconfigurar para mostrar el caso de uso
El uso de estas herramientas se debe a dos motivos para que no existacontienda con respecto a los puertos de los clientes usados por las tareas eacutestos sevan a asignar de forma dinaacutemica lo que en principio implicariacutea que la aplicacioacutendeberiacutea realizar consultas DNS de tipo SRV (que incluye puertos) a la interfazde Consul y balancear la carga entre tareas por redundancia y capacidad
Como la direccioacuten IP y puerto son variables cada vez que las tareas seactualicen o se reasignen es necesario volver a configurar HAProxy de formamanual Por ello HashiCorp ha desarrollado un programa denominado Con-sul Template que realiza peticiones sucesivas a la interfaz HTTP de Consul delas direcciones fiacutesicas de un servicio y reinicia automaacuteticamente el proceso deHAProxy Asiacute definiendo estas tareas como servicios Consul podremos tantomonitorizarlas como escalar las tareas dinaacutemicamente sin necesidad de cambiarel balanceador A partir del contenedor Docker oficial de HAProxy se ha desa-rrollado otro con la configuracioacuten baacutesica y con Consul Template para desplegarlocomo una tarea en Nomad
Despliegue
Se ha usado el mismo coacutedigo que en el apartado anterior con la persistenciaen el servicio de almacenamiento de Azure Desde la perspectiva del hardwarese implementaraacute la misma infraestructura que en el caso de DCOS (figura 18)estos es definiremos dos tipos de maacutequinas clientes un agente que se conectaraacutecon el balanceador de carga con nombre de dominio puacuteblico y donde se desple-garaacute el balanceador de carga de la vista web y agentes privados no accesiblesdesde fuera del cluster y donde se ejecutaraacuten el resto de tareas en la red inter-na La principal diferencia radica en las tareas que ejecutan HAproxy y ConsulTemplate que sustituye a las direcciones IP virtuales que ofrece DCOS
20httpwwwthekelleysorgukdnsmasqdochtml
34
Figura 20 Despliegue en Azure de Nomad+Consul
Cabe matizar que los balanceadores basados en HAProxy se implementanpor necesidad de la aplicacioacuten para el descubrimiento del servicio a diferenciade los de Azure que se implementan por motivos de seguridad y escalabilidaddel cluster en siacute
Configuracioacuten Nomad
Los ficheros de configuracioacuten de las maacutequinas maacutester y cliente son similaresy comparten la mayoriacutea de las opciones como por ejemplo el nombre del nodoo la interfaz de red donde escucha Nomad las peticiones Sus opciones son engeneral auto-explicativas sin embargo existen dos detalles que matizar
El proceso de Nomad escucha las peticiones tanto de los protocolos deconsenso como del usuario a traveacutes de una interfaz de red que se debeindicar en el fichero de configuracioacuten
En el caso de los clientes se deben indicar las direcciones de los servidoresdel cluster sin embargo se trata de un sistema dinaacutemico en el que losnodos pueden sufrir errores y cambiar de direccioacuten Por ello se ha definidoNomad como un servicio de Consul y asiacute poder definir la direccioacuten de losservidores como un nombre de dominio no por su direccioacuten fiacutesica que elservidor DNS de Consul se encargaraacute de resolver
Por defecto Nomad usa los siguientes puertos
API HTTP 4646 Peticiones HTTP y recepcioacuten de oacuterdenes mediante laliacutenea de comandos
RPC 4647 Protocolo de consenso entre los nodos del cluster
Serf 4648 Protocolo de gossip entre los servidores de los centros de datosgobernados por Nomad
35
Los dos uacuteltimos deben ser interfaces alcanzables por otros nodos sin embargo laAPI HTTP por motivos de seguridad deberiacutea ser local ya que en caso contrariocualquier persona con acceso a ella tiene el control sobre la herramienta Eacutestasolo deberiacutea estar accesible en un servidor o gestionarlo mediante una terminalSSH por ejemplo En este trabajo al ser una prueba de concepto se ha abiertoen todos los nodos
Trabajos de Nomad
Las tareas se detallan en ficheros con formato HashiCorp Configuration Lan-guage un derivado del formato JSON creado por la empresa que le da nombrecompatible con eacuteste y que permite comentarios
En estos ficheros se puede definir
La regioacuten y el centro de datos donde se ejecutaraacute (Nomad permite lagestioacuten de centros de datos geograacuteficamente distribuidos en regiones)
La poliacutetica de actualizacioacuten de la tarea
Grupo de tareas esto es que se ejecutaraacuten en el mismo nodo
El nuacutemero de grupos a ejecutarescalar asiacute como los liacutemite que debencumplir los nodos asignados
La poliacutetica de reinicio ante fallo o error
Tareas El controlador su configuracioacuten los paraacutemetros del servicio aso-ciado a registrar en Consul asiacute como los recursos que consume (puertosmemoria)
En nuestro caso usamos sobre todo el controlador Docker esto eso orques-tacioacuten de contenedores en los nodos clientes y tres de sus opciones
Imagen del contenedor Se han subido todas las imaacutegenes del proyecto a Doc-ker Hub donde por defecto se busca la imagen
Puertos Los puertos a usar por el contenedor que pueden ser estaacuteticos asigna-dos por el usuario o dinaacutemicos siendo Nomad el que se encarga de mapearun puerto libre del nodo cliente al expuesto por el contenedor
Servidores DNS Como usamos la interfaz DNS de Consul como descubri-miento de servicio se debe configurar el contenedor para que use cualquiernodo del cluster como servidor DNS
Configuracioacuten Consul
Al ser desarrolladas por la misma empresa los ficheros de configuracioacuten deConsul y Nomad comparten muchas opciones Consul tambieacuten acepta peticionesa traveacutes de una interfaz de red siendo los puertos usados por defecto
36
RPC 8300 8400 Maneja la peticiones del resto de nodos y usuarios
Serf 8301 8302 Protocolo gossip
HTTP API 8500
HTTPS API Desactivada por defecto
Interfaz DNS 8600
Se debe asignar a los protocolos internos del cluster esto es RPC y Serf unainterfaz alcanzable por los nodos y por el contrarioasignar a los dos uacuteltimos ala interfaz de loopback por motivos de seguridad
Cabe destacar que Consul tambieacuten cuenta con una interfaz graacutefica que per-mite ver el estado de los equipos y los servicios registrados y que se encuentra enel mismo puerto que la API HTTP en la direccioacuten httpIP_EQUIPO8500ui
Ejecucioacuten
Tanto Nomad como Consul requieren de la ejecucioacuten de un fichero en todoslos nodos integrantes del cluster Como prueba de concepto se ha decidido usardos servidores para ambos aunque cabe matizar que es un nuacutemero ineficienteya que la caiacuteda de uno de ellos supondriacutea la peacuterdida del cuoacuterum y por tantodel consenso del cluster
En primer lugar se arrancan los servidores que son los encargados de ejecu-tar el protocolo de consenso y gestionar el cluster y a continuacioacuten los clientesque no tienen praacutecticamente estado y dependen de los servidores
En el caso de Consul se debe indicar el directorio donde se guardan losficheros que describen los servicios asiacute como el archivo que especifica el resto delas opciones
1 Se inicia el primer servidor en uno de los equipos
$ consu l agent minuscon f i gminusd i r e t c consu l d s e r v i c e s minuscon f i gminus f i l e consu l_server j son
2 Los siguientes equipos deben unirse al anterior por lo que antildeadimos elargumento join con la direccioacuten del primer servidor Para el caso de otrosservidores
$ consu l agent minuscon f i gminusd i r e t c consu l d s e r v i c e s minuscon f i gminus f i l e consu l_server j son minus j o i n ltIP_servidor1gt
37
Una vez los servidores han alcanzado el consenso y elegido un liacuteder en losclientes
$ consu l agent minuscon f i gminusd i r e t c consu l d s e r v i c e s minuscon f i gminus f i l e c on su l_c l i en t j son minus j o i n ltIP_cualquierServ idorgt
El proceso para iniciar Nomad es igual y los comandos similares sin embargoya no es necesario indicar una direccioacuten IP fija en los equipos sino el nombre dedominio del servicio de Nomad registrado por Consul En el primer servidor
$ nomad agent minusc on f i g nomad_server j son
Y el resto de equipos (con su fichero de configuracioacuten correspondiente)$ nomad agent minusc on f i g nomad_server j son minus j o i n nomad s e r v i c e consu l
Por uacuteltimo para desplegar la aplicacioacuten web se han escrito tres ficherosque detallan las tareas de la interfaz web API y los balanceadores de cargaMediante la CLI
$ nomad run minusaddress=http lt ip_c lus te r gt4646 lt f i l e hclgt
O mediante la API HTTP de Nomad$ cu r l minusX POST minusd ltf i l e hclgthttp lt ip_c lus te r gt4646 jobltjob_namegt
Ansible
Como se puede comprobar con el aumento del nuacutemero de equipos pasa aser inviable manejar todos los nodos a traveacutes de terminal Ademaacutes como seha comentado con anterioridad Nomad requiere que en los nodos clientes es-teacuten instalados las herramientas que soporten las tareas por ejemplo el motorde Docker Por ello para facilitar tanto el arranque como la instalacioacuten de lasdependencias vamos a usar Ansible una herramienta de coacutedigo abierto desarro-llada en Python que permite gestionar configuraciones aprovisionar recursosdespliegue de aplicaciones de forma automaacutetica
A grandes rasgos esta herramienta funciona mediante ficheros en formatoYAML denominados play-books que describen un conjunto de pasos a ejecutaren una lista de equipos remotos Estos pasos son ejecutados por moacutedulos inde-pendientes a traveacutes de SSH es decir en cualquier ordenador con conexioacuten a los
38
hosts dado su contrasentildea o clave puacuteblica puede arrancar el script y realizariacutealos pasos de forma remota gestionando el cluster desde un solo equipo
Se han desarrollado guiones para lo siguiente
Descarga de los binarios de Nomad y Consul en todos los nodos copiade los ficheros de configuracioacuten baacutesicos y modificarlos de acuerdo a cadanodo (nombre del equipo direccioacuten IP)
Instalacioacuten de las dependencias
Arranque de Nomad y Consul
Ansible extiende su funcionalidad a traveacutes de moacutedulos independientes que per-miten por ejemplo instalar paquetes mediante herramientas de gestioacuten de pa-quetes (APT yum) aprovisionar automaacuteticamente maacutequinas virtuales de Ama-zon EC2
Algunas opciones de los ficheros de configuracioacuten de Nomad y Consul sondependientes del nodo particular por ejemplo la interfaz de red Para estetrabajo se ha realizado un moacutedulo para modificar los ficheros de configuracioacutende forma automaacutetica En el repositorio del proyecto se encuentra una carpetadonde se encuentran todos los ficheros necesarios para desplegar un clustertotalmente funcional solo requiere de una liacutenea de terminal con Ansible
$ ans ib l eminusplaybook minus i hos t s minusk ltssh_passgt minusu ltnode_usergt s i t e yml
39
62 Servicio de integracioacuten continua
Se ha implementado un sistema de integracioacuten continua que permite ejecu-tar tareas de compilacioacuten y pruebas de forma distribuida aumentando asiacute elrendimiento de los equipos En primer lugar se detallaraacute los motivos por los quepuede resultar beneficioso para las empresas una implementacioacuten de este tipo alo que seguiraacute los detalles del despliegue
621 DevOps
Metodologiacutea que defiende la comunicacioacuten y colaboracioacuten entre desarrolla-dores de software y los profesionales de operaciones a lo largo de todo el ciclo devida de una aplicacioacuten Estaacute muy relacionado con el desarrollo aacutegil de softwareesto es un enfoque para los proyectos que defiende el desarrollo iterativo e in-cremental donde los requisitos y soluciones evolucionan con el tiempo seguacuten lanecesidad del proyecto DevOps extiende esta filosofiacutea a todas los componentesde un servicio incluyendo sistemas y operaciones
Se trata de un concepto que cada organizacioacuten o empresa adapta a suspropias necesidades y procesos de negocio en este proyecto nos vamos a centraren la integracioacuten continua una praacutectica fundamental tanto del desarrollo aacutegilcomo de esta filosofiacutea
622 Integracioacuten Continua
Se define como una praacutectica de desarrollo software donde los miembros delequipo ponen en comuacuten su trabajo frecuentemente al menos una vez al diacutea21Cada integracioacuten se verifica con una compilacioacuten automaacutetica que incluye laejecucioacuten de pruebas para detectar errores de integracioacuten tan pronto como seaposible
Desde el punto de vista operativo esto supone automatizar la configuracioacutende equipos o el despliegue de maacutequinas virtuales donde compilar el proyecto yejecutar las pruebas y posteriormente eliminarlas Este flujo de trabajo se vebeneficiado en entornos distribuidos ya que el objetivo del desarrollador es com-probar el resultado de las pruebas raacutepidamente sin preocuparse del despliegueo los propios equipos
Para esta prueba de concepto vamos a usar Jenkins un servidor de integra-cioacuten continua escrito en Java que nos permite definir trabajos que contendraacutenla descripcioacuten tanto del entorno como su ejecucioacuten
Este sigue una estructura maestro-esclavo muy similar al de los gestores declusters usados en este proyecto el maestro contiene toda la loacutegica del servicio
21httpmartinfowlercomarticlescontinuousIntegrationhtml
40
trabajos autenticacioacuten y los esclavos son los encargados de la ejecucioacuten ensiacute Jenkins tiene varias viacuteas para aprovisionar los uacuteltimos
Mediante SSH
Interfaz graacutefica
Desarrollar un script propio
Ejecucioacuten de un fichero java
La ventaja de usar planificadores es que el despliegue de esclavos es dinaacutemicoes decir no tener una maacutequina especiacuteficamente configurada para ello DCOS yNomad se encargaraacuten de configurar estos despliegues en sus maacutequinas y poste-riormente eliminarlos Para ello se ha usado la uacuteltima opcioacuten definiendo tareasque descarguen el fichero java Con todo ello se consigue un entorno de inte-gracioacuten continua eficiente que ademaacutes permite la ejecucioacuten de otros servicios deforma independiente
Jenkins permite la creacioacuten de plugins que extienden sus funcionalidadesTanto Nomad22 como Apache Mesos cuentan con uno que permite su integra-cioacuten
Para esta prueba se va a usar el mismo proyecto que para el caso de usode orquestacioacuten de contenedores la aplicacioacuten web al que se le ha antildeadido untest para comprobar que se conecta correctamente a la base de datos medianteMocha un framework de Nodejs Por otro lado se antildeade el plugin de git ya queel coacutedigo se obtiene de GitHub el repositorio remoto de control de versiones delproyecto
El proceso general de ejecucioacuten seriacutea como sigue
1 Se ejecuta el maestro de Jenkins como tarea Docker partiendo de la imagenoficial
2 Al arrancar un trabajo se manda una tarea a los planificadores que laasignaraacuten a un nodo cliente Esta tarea consiste en la descarga del ficherode configuracioacuten Java y arrancarlo configurando el equipo como un clientede Jenkins temporalmente
3 Jenkins ejecuta el trabajo en el nuevo cliente en este caso iniciar la apli-cacioacuten web iniciar las pruebas y generar un informe
4 Se elimina el cliente
A continuacioacuten se detallan los matices de cada herramienta a la hora de imple-mentar este servicio
22Desarrollado por Ivo Verberk httpwwwivoverberknl
41
623 Jenkins con Nomad
El plugin permite la ejecucioacuten del fichero Java mediante dos controladorescontenedores Docker y Java En este proyecto nos hemos decantado por el pri-mero ya que nos ahorra instalar la maacutequina virtual de java en todos los nodoscliente Por ello se ha construido un contenedor base con Java para la ejecucioacutendel fichero de configuracioacuten y Nodejs para lanzar la aplicacioacuten web
El plugin se configura con la direccioacuten IP del cluster y el contenedor queejecuta el esclavo Jenkins Por su parte el trabajo en Jenkins se define conel repositorio en GitHub donde se aloja el coacutedigo del proyecto a probar y loscomandos a ejecutar en este caso npm update y npm test
624 Jenkins con DCOS
En el caso de DCOS su sistema de paquetes incluye Jenkins por lo queal instalarlo ya se tiene la configuracioacuten de Mesos totalmente funcional Sinembargo para ejecutar la aplicacioacuten en particular y las pruebas se requiere deNodejs en los equipos esclavos por ello debemos antildeadir un plugin de Jenkinsque permite instalar este entorno antes de ejecutar el trabajo Una vez hechoesto soacutelo queda definir la tarea igual que en el caso anterior
Cabe destacar que Mesosphere tambieacuten ha desarrollado un plugin que per-mite hacer despliegues en Marathon de tal manera que permitiriacutea con cadacommit del coacutedigo compilar la imagen del contenedor Docker y desplegarlaautomaacuteticamente aunque en este proyecto no se ha hecho pruebas de esta fun-cionalidad
42
7 Escalando la infraestructura
Uno de los factores clave que se busca a la hora de implementar sistemasdistribuidos es el poder escalar la infraestructura de forma maacutes sencilla estoes detectar que las maacutequinas estaacuten alcanzando el liacutemite de su capacidad yaumentar eacutesta ya sea mejorando sus caracteriacutesticas teacutecnicas o antildeadiendo maacutesnodos al cluster
El coacutedigo y todos los ficheros de configuracioacuten de esta seccioacuten tambieacuten sepueden encontrar en el repositorio del proyecto en GitHub23
71 Disentildeo
Microsoft Azure permite organizar los servicios cloud de forma loacutegica a traveacutesde grupos de recursos y asiacute poder crear o eliminar eacutestos en conjunto parauna aplicacioacuten determinada (por ejemplo una aplicacioacuten web suele requerir demaacutequinas virtuales bases de datos almacenamiento) Ademaacutes dispone dela opcioacuten de crear plantillas en formato JSON que permite al desarrolladordefinir los recursos y su interrelacioacuten para desplegar de forma automaacutetica unainfraestructura TI en la nube
Azure tambieacuten ofrece la posibilidad de monitorizar el estado de las maacutequinasvirtuales a traveacutes de extensiones lo que permite configurar el escalado automaacute-tico al alcanzar cierto liacutemite definido por el operador Eacutesta es a priori la formaen que deberiacutea implementarse hablando en teacuterminos de eficiencia sin embargoesta aproximacioacuten es totalmente dependiente de la plataforma es decir no sepuede extrapolar a otro proveedor o sobre recursos propios sin realizar un nue-vo disentildeo En este proyecto las tareas que son ejecutadas por estos equipos notienen estado ya que todo lo relativo a la persistencia lo hemos asignado fueradel cluster esto permite escalar la plataforma a traveacutes de otra aproximaciones
Las plantillas aceptan una serie de variables a indicar por el usuario entreotras los conjuntos de escala para definir los nodos aceptan una variable quedefine el nuacutemero de maacutequinas que los componen Por otro lado Azure ofreceuna API REST y kits de desarrollo software (SDK por sus siglas en ingleacutes) quepermiten su despliegue de forma programaacutetica Aprovechando estas facilidadesen este proyecto se va a aproximar la escalabilidad con el sucesivo desplieguede la infraestructura de forma automaacutetica se monitorizan los equipos y si sedetecta una maacutequina excesivamente cargada se aumenta el nuacutemero de equiposen la plantilla y se vuelve a desplegar
23httpsgithubcomAntonioAlfrzCloud-Orchestrators
43
En este proyecto se han disentildeado las plantillas para desplegar la arquitec-tura necesaria tanto de Nomad como de DCOS En el caso de la primera eldespliegue es maacutes descriptivo ya que incluye maacutequinas virtuales grupos de se-guridad redes En el caso de DCOS Azure cuenta con un servicio especiacuteficopara clusters gobernados por DCOS denominado Azure Container Service queincluye los componentes necesarios y la instalacioacuten ya realizada
72 Implementacioacuten
En primer lugar para monitorizar el estado de los equipos se va a usar laherramienta Nagios un sistema que permite controlar el estado del hardwarey los servicios de un equipo Se trata de una herramienta muy completa de laque se va a usar su capacidad para ejecutar comandos (plugins) en los nodospara detectar picos de carga generar alertas y ejecutar programas para estoseventos
Se ha desplegado una maacutequina virtual con esta herramienta en ambos siste-mas y se ha instalado una extensioacuten de Nagios (Nagios Remote Plugin Executor)en todos los nodos que permite ejecutar comprobaciones remotamente en con-creto para esta prueba de concepto medir el nivel de saturacioacuten de la unidadcentral de procesamiento (CPU por sus siglas del ingleacutes) Cuando sucede uncambio de estado de una maacutequina esto es cuando este paraacutemetro supera el liacutemi-te definido por el operador Nagios permite actuar en consecuencia ejecutandoprogramas por ello se ha desarrollado un script que ejecuta lo siguiente
Un programa desarrollado en Python con el SDK de Azure que modificalas plantillas y despliega los recursos
Un guioacuten de Ansible para instalar todos los componentes necesarios en lasnuevas maacutequinas y arrancar de nuevo el cluster y las aplicaciones
44
8 Resultados y conclusiones
En este uacuteltimo apartado se da una visioacuten global del proyecto asiacute como a lasconclusiones maacutes importantes a las que se ha llegado y posibles temas futurosde desarrollo
81 Comparacioacuten
Ambas herramientas ofrecen las funcionalidades para gestionar los recursoseficientemente ofreciendo a los desarrolladores una plataforma donde desplegarsus aplicaciones de forma distribuida independientemente de los equipos fiacutesicosy el hardware que las soporten
DCOS es una herramienta que en un comienzo fue privativa pero cuyos res-ponsables la empresa Mesosphere decidieron publicar una versioacuten de coacutedigoEacutesta nos permite gestionar un cluster de una forma sencilla y usable ademaacutes decomplementarlo con otras herramientas como el balanceador de carga integradoo la autenticacioacuten de usuarios ademaacutes estaacute basada en Apache Mesos un pro-yecto de relativa madurez y con el soporte de la Apache Software FoundationDe forma resumida DCOS ofrece muchas posibilidades y servicios a cambiode una arquitectura e instalacioacuten maacutes compleja
Por su parte HashiCorp con menor tiempo de desarrollo ha conseguidouna herramienta muy sencilla de desplegar que ademaacutes cumple con todas lasfuncionalidades baacutesicas ejecutando un simple binario en cada nodo se puededesplegar un gestor de clusters totalmente funcional Sin embargo no cuentacon todas las posibilidades de Mesos (Nomad cuenta con menos controladoresque entornos posibles de Mesos) ni con los antildeadidos de DCOS lo que implicael uso de otras herramientas para complementar el servicio (Consul HAProxy)
De entre las dificultades encontradas al usar estas herramientas y desplegaraplicaciones sobre ellas se puede destacar la depuracioacuten en ocasiones se desco-noce si un error viene de la propia herramienta de la aplicacioacuten desplegada o delequipo fiacutesico si no se cuenta con un sistema de procesamiento de registro unose puede encontrar con muacuteltiples terminales abiertas inspeccionando numerososficheros de registro buscando posibles errores Ademaacutes no dejan de ser solucio-nes que para usar eficientemente se debe conocer parte de su funcionamientoy sintaxis a la hora de describir la tareas lo que supone un esfuerzo antildeadido yaque cada una tiene sus particularidades y liacutemites
45
82 Conclusiones
En una sociedad cada vez maacutes digital las empresas deben adaptarse a unmercado cuya demanda de contenido no deja de crecer Las nuevas arquitecturascomo microservicios asiacute como la gran cantidad de datos generada implica queuna mejor gestioacuten de los recursos y la rapidez para desplegar o escalar solucionesdando valor al cliente lo maacutes raacutepido posible es uno de los objetivos de todas lasempresas de base tecnoloacutegica
Las ventajas que ofrecen los planificadores con aplicaciones distribuidas sonnumerosas sin ir maacutes lejos empresas tan punteras como Google llevan maacutesde 10 antildeos orquestando contenedores24 Por un lado permiten aumentar elrendimiento de los equipos propios y por otro implementar un servicio comoplataforma para despliegues distribuidos sobre cualquier conjunto hardware deesta forma se provee un servicio similar al de la nube puacuteblica pero con laprincipal diferencia de que se elimina la independencia con el proveedor (vendorlock-in) esto es las aplicaciones no tienen limitaciones impuestas por eacuteste talescomo lenguaje de programacioacuten o herramientas y permite despliegues hiacutebridosentre recursos propios y la nube
83 Objetivos conseguidos
Implementacioacuten de los planificadores propuestos en la nube Se ha en-tendido y detallado el funcionamiento de estas herramientas y se hanimplementado en el servicio de infraestructura de Microsoft Azure
Despliegue de aplicaciones y servicios distribuidos Servicios que se usanactualmente en la industria del desarrollo software asiacute como una aplica-cioacuten web con una arquitectura moderna han sido desplegados de formadistribuida en los equipos cumpliendo con la funcionalidad esperada ade-maacutes de consiguiendo una alta disponibilidad
Aproximacioacuten de arquitectura escalable Se ha hecho una aproximacioacutende infraestructura escalable de forma que sea parcialmente extrapolable aotros proveedores
24httpwwwnextplatformcom20160322decade-container-control-google
46
84 Liacuteneas de investigacioacuten
Siguiendo con la materia de este proyecto se presentan posibles liacuteneas deinvestigacioacuten
Analizar el despliegue con estas herramientas de aplicaciones de Big Datay comparar la eficiencia con respecto a soluciones especializadas
Analizar el rendimiento de los algoritmos de planificacioacuten antes pruebasde estreacutes y situaciones de alta contienda
Comparar el uso de estas herramientas con las praacutecticas actuales de laindustria o implementacioacuten en un sistema de produccioacuten real
47
Referencias
[1] LA Barroso y U Houmllzle laquoThe Datacenter as a Computer An Introduc-tion to the Design of Warehouse-Scale Machinesraquo En Morgan amp ClaypoolPublishers ()
[2] Systems Research Group ndash NetOS (University of Cambridge) The evolu-tion of cluster scheduler architectures 2016 url httpswwwclcamacukresearchsrgnetoscamsasblog2016-03-09-scheduler-architectureshtml
[3] A Das I Gupta y A Motivala SWIM Scalable Weakly-consistent Infection-style Process Group Membership Protocol Inf teacutec Dept of ComputerScience Cornell University url https www cs cornell edu ~asdasresearchdsn02-swimpdf
[4] D Dubhashi y A Das Mastering Mesos PACKT Publishing mayo de2016
[5] The Apache Software Foundation Apache Mesos documentation urlhttpsmesosapacheorg
[6] David Greenberg Building Applications on Mesos OrsquoReilly Media 2016[7] Armand Grillet Comparison of Container Schedulers Inf teacutec Technische
Universitaumlt Berlin[8] HashiCorp Consul documentation url httpswwwconsulio[9] HashiCorp Nomad documentation url httpsdcosio[10] Dan C Marinescu Cloud computing theory and practice Morgan Kauf-
mann 2013[11] Mesosphere DCOS documentation url httpswwwnomadproject
io[12] Microsoft Azure documentation url httpsazuremicrosoftcom
es-esdocumentation[13] D Ongaro y J Ousterhout In Search of an Understandable Consensus
Algorithm Inf teacutec Stanford University url httpsraftgithubioraftpdf
[14] Fei Teng laquoRessource allocation and schelduling models for cloud compu-tingraquo Tesis de mtriacutea Ecole Centrale Paris 2011
[15] A Williams y col Automation and Orchestration with Docker and Contai-ners A Comprehensive Overview of the Docker and Container Ecosystem3 The New Stack 2016
48
- Resumen
- Summary
- Iacutendice de figuras
- Introduccioacuten y objetivos
-
- Contexto
- Objetivos
- Estructura del documento
-
- Cloud Computing
- Nuevas cargas de trabajo
- Gestioacuten de recursos Planificadores
-
- Sistemas distribuidos
-
- Clasificacioacuten
-
- Herramientas
-
- DCOS
-
- Apache Mesos
- Ejemplos de uso
-
- Nomad
-
- Protocolo de consenso Raft
- Protocolo gossip SWIM
- Planificacioacuten
-
- Casos de uso y despliegue
-
- Aplicacioacuten Web
-
- DCOS
- Nomad
-
- Servicio de integracioacuten continua
-
- DevOps
- Integracioacuten Continua
- Jenkins con Nomad
- Jenkins con DCOS
-
- Escalando la infraestructura
-
- Disentildeo
- Implementacioacuten
-
- Resultados y conclusiones
-
- Comparacioacuten
- Conclusiones
- Objetivos conseguidos
- Liacuteneas de investigacioacuten
-
Iacutendice
Resumen III
Summary V
Iacutendice de figuras IX
1 Introduccioacuten y objetivos 1
11 Contexto 1
12 Objetivos 2
13 Estructura del documento 2
2 Cloud Computing 3
3 Nuevas cargas de trabajo 5
4 Gestioacuten de recursos Planificadores 8
41 Sistemas distribuidos 8
411 Clasificacioacuten 10
5 Herramientas 13
51 DCOS 14
511 Apache Mesos 15
512 Ejemplos de uso 18
52 Nomad 19
521 Protocolo de consenso Raft 20
vii
522 Protocolo gossip SWIM 23
523 Planificacioacuten 24
6 Casos de uso y despliegue 27
61 Aplicacioacuten Web 27
611 DCOS 28
612 Nomad 33
62 Servicio de integracioacuten continua 40
621 DevOps 40
622 Integracioacuten Continua 40
623 Jenkins con Nomad 42
624 Jenkins con DCOS 42
7 Escalando la infraestructura 43
71 Disentildeo 43
72 Implementacioacuten 44
8 Resultados y conclusiones 45
81 Comparacioacuten 45
82 Conclusiones 46
83 Objetivos conseguidos 46
84 Liacuteneas de investigacioacuten 47
viii
Iacutendice de figuras
1 Comparacioacuten Centro de datos - Computacioacuten en la nube 4
2 Arquitectura Docker 6
3 Planificador monoliacutetico 11
4 Planificador de dos niveles 11
5 Planificador de estado compartido 12
6 Planificador distribuido 12
7 Arquitectura DCOS 14
8 Servicios DCOS 15
9 Arquitectura de Apache Mesos 17
10 Arquitectura multi-regioacuten en Nomad 20
11 Equipos sin consenso ejecutando el protocolo RAFT 21
12 Un equipo pasa a estado candidato (RAFT) 22
13 Cambio en un registro (RAFT) 22
14 Aprobacioacuten del resto de equipos (RAFT) 23
15 Diagrama de tiempo del protocolo SWIM 24
16 Procedimiento de asignacioacuten en Nomad 25
17 Arquitectura aplicacioacuten web 28
18 Infraestructura en Azure 29
19 Arquitectura de la aplicacioacuten web en DCOS 32
20 Despliegue en Azure de Nomad+Consul 35
ix
1 Introduccioacuten y objetivos
11 Contexto
Las tecnologiacuteas de la informacioacuten y la comunicacioacuten estaacuten suponiendo uncambio draacutestico en la sociedad en 2007 comenzaron a aparecer los teleacutefonosinteligentes tal y como los conocemos y nueves antildeos despueacutes se empieza a con-cebir la idea de dar conectividad a todo dispositivo electroacutenico movimiento queha tomado el nombre de Internet de las cosas Para hacerse una idea de la rapi-dez y magnitud de esta evolucioacuten la consultora Excelacom1 ha estimado que enun minuto se realizan 24 millones de buacutesquedas en Google o se ven 278 millonesde viacutedeos en Youtube En una eacutepoca en la que los recursos tecnoloacutegicos crecenexponencialmente y los usuarios demandan mayor contenido y movilidad nocabe duda que las empresas deben adaptarse lo maacutes raacutepidamente posible a esteproceso de digitalizacioacuten movidas por las nuevas necesidades de las personas
Dado el gran volumen de informacioacuten a lo largo de estos antildeos la compu-tacioacuten y el almacenamiento estaacuten pasando de clientes locales a concentrarse engrandes centros de datos una tendencia que Google ha denominado ldquoWarehouse-scale computingrdquo en 2009[1] Este movimiento hacia la computacioacuten desde ser-vidor no solo viene de la necesidad de mejorar la experiencia de los usuariossino tambieacuten de facilitar la gestioacuten y configuracioacuten de los recursos asiacute como laubicuidad de acceso que permite
En 2006 Amazon lanza Amazon Web Services siendo uno de los pionerosen el mercado de los recursos virtuales ofreciendo capacidad de computacioacutencon un coste proporcional exclusivamente a los recursos utilizados Todo ellocambioacute la perspectiva de los modelos tradicionales de TI a la conocida comocomputacioacuten en la nube recursos informaacuteticos que antes suponiacutean barrerasde entrada en ciertos mercados han pasado a ser condicioacuten necesaria para laconstante evolucioacuten de la tecnologiacutea y la sociedad De hecho Cisco estima quepara el antildeo 2019 maacutes del 86 de las cargas de trabajo seraacuten procesadas porcentros de datos en la nube2
1httpwwwexcelacomcomresourcesblog2016-update-what-happens-in-one-internet-minute2httpwwwciscocomcenussolutionscollateralservice-provider
global-cloud-index-gciCloud_Index_White_Paperpdf
1
12 Objetivos
El propoacutesito de este proyecto es estudiar la viabilidad del uso de planifica-dores de recursos para aumentar la eficiencia de eacutestos y facilitar al desarrolladorel despliegue de aplicaciones de forma distribuida y asiacute ofrecer un servicio ca-racterizado por una alta disponibilidad y escalabilidad
A lo largo de este trabajo se han usado algunas de las herramientas quese estaacuten comenzando a desarrollar para hacer frente a este nuevo enfoque degestioacuten de infraestructuras de las tecnologiacuteas de la informacioacuten (en adelanteinfraestructuras TI) realizando pruebas de concepto sobre cada una de ellas
13 Estructura del documento
A continuacioacuten se detalla las secciones que componen este trabajo La es-tructura queda como sigue
Cloud computing Se entra en detalle en este nuevo modelo de negocio queha originado nuevos enfoques y disentildeos de las infraestructuras TI dentrode las organizaciones
Nuevas cargas de trabajo Se explican algunas tecnologiacuteas representativasque estaacuten suponiendo un desafiacuteo para los profesionales de TI a la horade planificar los recursos y que se ven beneficiadas por entornos de tipocloud
Gestioacuten de recursos Planificadores Estado del arte de las tecnologiacuteas degestioacuten de clusters y planificacioacuten de recursos
Herramientas Descripcioacuten detallada del funcionamiento y arquitectura de lasherramientas usadas a lo largo del proyecto
Casos de uso y despliegue Se describe el proceso de implementacioacuten de unaaplicacioacuten web y un servicio de integracioacuten continua con el software pro-puesto
Escalando la infraestructura Se propone un procedimiento con cierta inde-pendencia del proveedor cloud
Resultados y conclusiones Resume las ideas y hechos a los que se ha llegadoademaacutes de introducir liacuteneas de investigacioacuten futuras
2
2 Cloud Computing
El NIST (National Insitute of Standards and Technology) define este con-cepto como un modelo que permite un acceso ubicuo y bajo demanda de formaremota a un conjunto compartido de recursos de computacioacuten que pueden seraprovisionados y liberados con unos miacutenimos esfuerzos de gestioacuten por parte delproveedor del servicio3
Clasificacioacuten
La computacioacuten en la nube abarca una amplia variedad de servicios y enfo-ques por lo que en primer lugar se va a dar una clasificacioacuten para posterior-mente entrar maacutes en detalle Existen distintos modelos de nube atendiendo a lagobernabilidad de la infraestructura seguacuten el NIST
Nubes puacuteblicas Los servicios y recursos son ofertados de forma puacuteblica yson provistos por una organizacioacuten que los comercializa bajo demanda
Nube privada Los recursos son gestionados por una uacutenica organizacioacutenpara su propio uso
Nube comunitaria En este caso la infraestructura es administrada por unconjunto de organizaciones con objetivos comunes
Nube hiacutebrida Una combinacioacuten de las anteriores
A su vez los distintos servicios que ofrece se pueden clasificar atendiendo algrado de control del usuario
Servicios de software (Software as a Service SaaS) El proveedor se encargade toda la gestioacuten de la infraestructura y oferta aplicaciones a las cuales elcliente puede acceder de forma ubicua a traveacutes de diversos clientes comoun navegador web Por ejemplo Office 365 o Google docs
Servicios de plataforma (Platform as a Service PaaS) Modelo de distribu-cioacuten que ofrece la capacidad de desplegar aplicaciones desarrolladas por elcliente usando las herramientas y lenguajes de programacioacuten soportadaspor el proveedor pero sin la posibilidad de gestionar los recursos consu-midos En este caso el cliente solo tiene control sobre la propia aplicacioacuteny algunas configuraciones del entorno Es el caso de Heroku o Google AppEngine
3httpnvlpubsnistgovnistpubsLegacySPnistspecialpublication800-145pdf
3
Servicios de infraestructura (Infrastructure as a Service IaaS) Se ofertanrecursos de computacioacuten puros como procesamiento o almacenamientomediante una plataforma de virtualizacioacuten El cliente puede controlar elsistema operativo componentes de red y aplicaciones
Figura 1 Comparacioacuten Centro de datos - Computacioacuten en la nubeFuente httpsad-hocnet
De entre las numerosas ventajas que ofrece la computacioacuten en la nube se puededestacar su flexibilidad ya que permite aprovisionar recursos y adaptarlos deacuerdo a la demanda reduce el capital inmovilizado y su amortizacioacuten laubicuidad que permite su consumo desde cualquier parte con conexioacuten a la redy la seguridad y fiabilidad que ofrece el proveedor que normalmente cuenta conrecursos geograacuteficamente distribuidos frente a la gestioacuten y mantenimiento derecursos propios
4
3 Nuevas cargas de trabajo
Las organizaciones que cuentan con sus propios infraestructuras TI han co-menzado a adoptar un enfoque de nube privada para gestionar las tareas ofunciones informaacuteticas sobre las que se sustentan el negocio ya que una es-tructura virtualizada puede ofrecer ventajas con respecto a las adaptaciones decentros de datos tradicionales en los aacutembitos de rendimiento escalabilidad eincluso seguridad4
A su vez se han desarrollado nuevas tecnologiacuteas que suponen cargas detrabajo dinaacutemicas y con gran intensidad de consumo de datos para las empresasque se ven beneficiadas al desplegarlas en recursos virtualizados
Big data
Con la creciente aceptacioacuten de las tecnologiacuteas TIC por parte de la sociedadla cantidad de datos generados en la red es ingente Las profesionales de TI tienecomo objetivo extraer valor de eacutestos para por ejemplo prever las tendencias delmercado Sin embargo este incremento exponencial hace que su procesamientoy almacenamiento requiera de un sistema con gran escalabilidad dado el hechode que una sola maacutequina no puede proveer de la capacidad necesaria
Integracioacuten continua
Modelo informaacutetico que consiste en hacer integraciones automaacuteticas de unproyecto con cualquier cambio en el coacutedigo con el objetivo de detectar fallosde forma temprana Esto implica la compilacioacuten del coacutedigo y su ejecucioacuten enun entorno de pruebas automaacuteticamente un proceso que mediante tecnologiacuteasde virtualizacioacuten permiten simular entornos con eficiencia y rapidez Su imple-mentacioacuten en sistemas distribuidos permite tanto una mejor planificacioacuten comoun mejor rendimiento de los recursos
Arquitectura de microservicios
Enfoque para desarrollar aplicaciones software como un conjunto de serviciosautoacutenomos que se comunican entre siacute a diferencia de aproximaciones monoliacuteti-cas donde la loacutegica del servicio estaacute desarrollada como una unidad Un sistemadistribuido permite el despliegue de los componentes en distintas maacutequinas loque mejora tanto su escalabilidad como la tolerancia a fallos
4httpswwwakamaicomesesresourcespublic-private-cloudjsp
5
Docker
Proyecto de coacutedigo abierto que facilita y automatiza el despliegue de aplica-ciones al encapsular el entorno de trabajo en contenedores Linux una tecnologiacuteaque permite a un sistema fiacutesico ejecutar muacuteltiples instancias de sistemas opera-tivos aislados mediante entornos virtuales con sus propios espacios de procesosy redes pero compartiendo el nuacutecleo (kernel) con el equipo anfitrioacuten
En la figura 2 se compara la pila de una virtualizacioacuten tradicional con res-pecto a los contenedores no se simula el sistema operativo por lo que el procesoes mucho maacutes ligero
Docker se caracteriza por
Autosuficiencia Los contenedores cuentan con las libreriacuteas y configuracio-nes necesarias para ejecutarse de manera autoacutenoma al compartir el nuacutecleo
Portabilidad El hecho de que sean autosuficientes implica que es inde-pendiente del host es decir se puede desplegar en cualquier equipo quesoporte esta tecnologiacutea
Tamantildeo El peso de un contenedor es sustancialmente inferior a otrastecnologiacuteas de virtualizacioacuten
Figura 2 Arquitectura DockerFuente httpsdockercom
6
Los componentes fundamentales de esta herramienta son
Imaacutegenes Describen el entorno de base sobre el que ejecutar el contene-dor por ejemplo la imagen del sistema operativo Ubuntu Sobre eacutesta seconstruyen las aplicaciones particulares del usuario dando lugar a otraimagen
Contenedores Se crean a partir de las imaacutegenes y comprenden todo aquellonecesario para arrancar la aplicacioacuten decir su entorno de ejecucioacuten
bull Voluacutemenes Encargados de gestionar la persistencia de datos e inde-pendientes del ciclo de vida del contenedor
Registros Pueden ser puacuteblicos o privados y almacenan las imaacutegenes elregistro puacuteblico oficial de Docker es Docker Hub
Dadas estas caracteriacutesticas los profesionales TI estaacuten comenzando a adoptarDocker ya que facilita tanto los despliegues como el trabajo compartido en dis-tintos entornos Sin embargo esto requiere de un software que permita desplegarlos distintos contenedores de forma que puedan trabajar en conjunto procesoque se ha denominado orquestacioacuten de contenedores
7
4 Gestioacuten de recursos Planificadores
Para sacar el maacuteximo provecho a las tecnologiacuteas anteriormente descritaslo ideal es desplegarlas en sistemas distribuidos sin embargo esto aumenta lacomplejidad del propio despliegue asiacute como la necesidad de software especiali-zado para ello Se necesitan algoritmos de planificacioacuten que permitan obtener elmaacuteximo rendimiento de los recursos por un lado y dar ciertas garantiacuteas de quetodas las tareas y procesos se van a ejecuta por otro
41 Sistemas distribuidos
En primer lugar se definen los sistemas distribuidos o clusters como unconjunto de ordenadores conectados entre siacute cuyo objetivo es trabajar como unauacutenica instancia de gran capacidad5
Su clasificacioacuten variacutea de acuerdo a cada autor pero en general se puedendividir seguacuten su objetivo en alto rendimiento aquellos cuyo objetivos es proveerde gran capacidad de coacutemputo gracias al conjunto de los nodos y alta disponi-bilidad con los cuales se busca la fiabilidad del sistema mediante redundanciayo balanceo de carga
El intereacutes de este proyecto recae en los uacuteltimos ya que el objetivo es porun lado ofrecer al desarrollador un entorno donde desplegar sus aplicaciones deforma distribuida y por otro maximizar el rendimiento de los recursos
De forma general las caracteriacutesticas que se buscan son las siguientes
Elasticidad Adaptacioacuten a cargas dinaacutemicas de trabajo aumentando (o dis-minuyendo) recursos de manera automaacutetica de tal forma que la utilizacioacutensea lo maacutes cercana a la demanda
Disponibilidad Capacidad de un sistema para mantener el servicio fun-cional
Tolerancia a fallos Recuperacioacuten del servicio ante el fallo de un compo-nente
Balanceo de carga Compartir las tareas entre las diferentes maacutequinasredundadas evitando asiacute puntos de uacutenico fallo
5httpsenwikipediaorgwikiComputer_cluster
8
Los programas que se implementan en entornos distribuidos se caracterizanpor ejecutarse de forma concurrente en equipos independientes estar conectadospor una red que introduce fallos aleatorios y no compartir memoria ni reloj Estoimplica entre otras cosas que
Los nodos soacutelo tienen un acceso raacutepido a su memoria local por lo quecualquier informacioacuten relativa al estado global puede ser potencialmenteerroacutenea
Las maacutequinas pueden sufrir caiacutedas de forma aleatoria
El intercambio de informacioacuten puede fallar ya sea por error en transmisioacuteno por caiacuteda de los nodos
Estas dificultades se ponen de manifiesto en el teorema de CAP en cienciasde la computacioacuten el teorema de CAP que lanzado inicialmente como conjetu-ra en el antildeo 2000 por Eric Brewer (motivo por el cual al teorema se le conoceformalmente como teorema de Brewer) y posteriormente demostrado en el antildeo20026 establece que es imposible para un sistema de coacutemputo distribuido ga-rantizar simultaacuteneamente dos de las tres propiedades siguientes
Consistencia (Consistency) es decir que todos los nodos vean la mismainformacioacuten al mismo tiempo Se busca que un cambio en el sistema soacutelose ejecute satisfactoriamente si y soacutelo si se efectuacutea a todos las maacutequinasde tal forma que los datos entre ellos nunca difieren y la respuesta a unapeticioacuten sea la misma independientemente del nodo que la atienda
Disponibilidad (Availability) esto es la garantiacutea de que toda peticioacuten debeobtener una respuesta (servicio funcional) aunque exista inconsistenciaentre nodos
Tolerancia al particionado (Partition Tolerance) es decir que el sistemasiga funcionado a pesar de un fallo en la comunicacioacuten entre los equipos
Por todo lo expresado anteriormente conseguir un sistema distribuido capazde ofrecer procesamiento de forma transparente implica una arquitectura TIcompleja Se requieren de subsistemas y herramientas que permitan la cohesioacutenentre todos los nodos
Gestor de los recursos de las diferentes maacutequinas
Monitorizacioacuten tanto de los servicios activos como de la funcionalidad delsistema ademaacutes de poliacuteticas para recuperacioacuten de fallo
Protocolos de consenso que permitan a los nodos ser consistentes con elestado global del cluster
6urlhttpsgroupscsailmitedutdspapersGilbertBrewer2pdf
9
Herramientas de descubrimiento de servicios que permita la comunicacioacutenentre tareas distribuidas
Planificadores Encargados de distribuir las tareas y procesos en las dife-rentes maacutequinas asignaacutendole parte de su capacidad
Los planificadores del ingleacutes cluster schedulers son un componente funda-mental por lo que vamos a entrar un poco maacutes en detalle en ellos
Planificadores (Cluster Schedulers)
Es el software encargado de monitorizar los recursos usados por cada maacute-quina perteneciente a un cluster y distribuir la carga de trabajo entre ellas deacuerdo a un poliacutetica o reglas
Este tipo de herramientas comparten cierta terminologiacutea que es relevantedefinir
Tarea Unidad de trabajo computacional comprendida por una secuenciade instrucciones datos de entrada y recursos asociados Por ejemplo laejecucioacuten de un comando o el arranque de una base de datos
Nodo Cualquier maacutequina integrante de un cluster En una arquitecturamaestro-esclavo se definen dos roles
bull Cliente Agente Esclavo Aquellos ordenadores que se encargan deejecutar las tareas
bull Maestro Servidor Su objetivo es mantener el estado del cluster ygestionar sus recursos
411 Clasificacioacuten
A lo largo de los uacuteltimos antildeos se han desarrollado diferentes tipos de plani-ficadores[2]
Monoliacutetico
Un solo planificador que se encarga de distribuir todas las tareas entran-tes La mayoriacutea de los planificadores en computacioacuten de alto rendimiento asiacutecomo Borg desarrollado por Google son de este tipo En la figura 3 se pue-de observar de forma graacutefica el procedimiento siendo las cajas grises maacutequinaspertenecientes al cluster y los ciacuterculos las tareas a asignar
10
Figura 3 Planificador monoliacuteticoFuente httpswwwclcamacuk
Planificacioacuten de dos niveles
La mayoriacutea de los clusters ejecutan aplicaciones con distintas necesidadesdesde procesos casi instantaacuteneos hasta servicios persistenteslo que implica dis-tintas necesidades de recursos
Por ello la planificacioacuten a dos niveles distingue dos funciones la gestioacutende recursos (gestor) y la disposicioacuten de las tareas (planificador) Cada serviciotiene su propio planificador de tal manera que el gestor les ldquoofertardquo recursosde acuerdo a una poliacutetica y los planificadores se encargan de escoger la maacutesadecuada Esto permite que el proceso de distribucioacuten sea maacutes acorde con lasnecesidades de los diferentes servicios Apache Mesos que detallaremos maacutesadelante sigue este esquema
Como desventaja cabriacutea sentildealar que esta programacioacuten implica que los pla-nificadores pierden la vista general de la infraestructura y las tareas soacutelo puedenejecutarse con los recursos que les son ofrecidos lo que dificulta la implementa-cioacuten de prioridades de ejecucioacuten de tareas entre otras
Figura 4 Planificador de dos niveles
11
Planificacioacuten de estado compartido
Muacuteltiples reacuteplicas del estado del cluster se actualizan independientementepara cada planificador como se observa en la figura 5 cuando sucede un cambiode forma local el planificador se encarga de informar al resto
Ejemplo de este tipo son Omega la evolucioacuten de Borg por parte de GoogleMicrosoft Apollo y Nomad que usaremos para los casos de uso
De entre las desventajas se puede destacar el hecho de que en general losnodos trabajan con informacioacuten desactualizada lo que conlleva una degradacioacutendel rendimiento en situaciones de alta contienda
Figura 5 Planificador de estado compartido
Planificacioacuten distribuida
En este caso no existe coordinacioacuten entre los distintos planificadores Cadauno de ellos funciona con su propia vista del cluster Las tareas pueden serorganizadas por cualquiera de ellos y desplegadas en cualquier parte del clusteren base a la aleatoriedad y multiplexacioacuten estadiacutestica de los flujos de trabajosin ninguacuten control central
Figura 6 Planificador distribuido
12
5 Herramientas
En la industria comienzan a aparecer soluciones software de coacutedigo abiertoque aglutinan los servicios necesarios para gestionar la infraestructura TI de ma-nera maacutes eficaz El objetivo es doble se busca facilitar la gestioacuten de los recursosde computacioacuten para organizaciones con instalaciones propias mediante su usocon un enfoque cloud esto es desplegar aplicaciones a traveacutes de un conjuntode ordenadores de forma transparente y sin tener en cuenta la infraestructurasubyacente o aprovechar el maacuteximo rendimiento de la infraestructura de losproveedores cloud puacuteblicos de forma que se tiene el maacuteximo control sobre eacutestapero no se depende de las soluciones propietarias permitiendo asiacute despliegueshiacutebridos
Entre estas herramientas se pueden destacar
OpenStack Proyecto desarrollado por la fundacioacuten del mismo nombre paraproporcionar servicios de infraestructuras (IaaS) basado en componentesque se comunican a traveacutes de APIs El componente Magnum incluye mo-tores de orquestacioacuten de contenedores
Kubernetes Sistema de orquestacioacuten de contenedores Docker creado por Goo-gle
CoreOs Sistema operativo basado en Linux disentildeado para despliegues distri-buidos sobre contenedores incluyendo mecanismos de descubrimiento deservicio y comparticioacuten de configuracioacuten
Docker Swarm Herramienta nativa de orquestacioacuten de contenedores Docker
YARN Entorno de gestioacuten de recursos y aplicaciones distribuidas de Hadoopuna libreriacutea software de procesamiento de grandes conjuntos de datos
Como podemos observar existe un gran rango de opciones para gestionar lainfraestructura desde un bajo nivel como puede ser OpenStack hasta Kuberne-tes o Docker Swarm que ofrecen exclusivamente orquestacioacuten de contenedores
En este trabajo se ha optado por Mesosphere DCOS y HashiCorp Nomadque se encuentran en el teacutermino medio su objetivo es proporcionar serviciosde plataforma que permitan la coexistencia dediferentes cargas de trabajo en elcluster
13
51 DCOS
DCOS es un proyecto de coacutedigo abierto7 creado y desarrollado por la empre-sa Mesosphere Se describe como un sistema operativo distribuido que abstraelos recursos de un cluster (capacidad de procesamiento memoria) permite lagestioacuten de muacuteltiples ordenadores de forma transparente y simplifica la instala-cioacuten de aplicaciones distribuidas
Su arquitectura se puede comparar a la de Linux en teacuterminos de nuacutecleo(kernel) y espacio de usuario El primero consta de recursos protegidos a losque no puede acceder el usuario e involucra operaciones de bajo nivel comoasignacioacuten de recursos o aislamiento de procesos En el espacio de usuario seejecutan las aplicaciones y servicios de maacutes alto nivel
Siguiendo con este siacutemil el nuacutecleo de DCOS estaacute basado en Apache Mesosque se explicaraacute en un apartado posterior y el espacio de usuario que estaacute com-prendido por los componentes del sistema esto es las diferentes herramientasque en conjunto conforman DCOS y los servicios encargados de planificar yejecutar las aplicaciones y tareas del usuario
Figura 7 Arquitectura DCOSFuente httpsdcosio
De entre los componentes que conforman DCOS destacan
Admin Router Balanceador de carga central basado en NGINX que dis-pone un proxy entre todos los servicios en el puerto 80 permitiendo sugestioacuten mediante la interfaz graacutefica Ademaacutes se encarga de la autenticacioacutenpara acceder al panel de administracioacuten
Cosmos Gestor de paquetes de las aplicaciones
Diagnostics Se ejecuta en todos los nodos y se encarga de monitorizar elestado de los daemons que sustentan DCOS
7Desde abril de 2016 httpsmesospherecomblog20160419open-source-dcos
14
Exhibitor Gestiona y automatiza el despliegue de ZooKeper la herra-mienta que provee de configuracioacuten centralizada y registro de nombres
Marathon Equivale al proceso init de los sistemas tipo Unix esto es elprimer proceso en ejecucioacuten tras la carga del kernel y que genera los demaacutesprocesos Se encarga de arrancar y monitorizar las aplicaciones y servicios
Mesos-DNS Servicio de DNS interno que define el dominio mesos pa-ra nodos y tareas en el cluster es decir permite resolver nombres conindependencia de la direccioacuten fiacutesica
Minuteman Balanceador de carga integrado a nivel TCPUDP disponiblepara las propias aplicaciones
Por otra parte se definen como servicios a las diferentes aplicaciones dis-tribuidas que DCOS permite instalar en el cluster y que pueden haber sidodesarrollados por la misma empresa Mesosphere o por terceros por ejemploApache Spark Jenkins o Apache Hadoop En la figura 8 se muestra un diagramade los servicios disponibles incluyendo algunos de las aplicaciones distribuidasque soporta DCOS
Figura 8 Servicios DCOSFuente httpsdcosio
511 Apache Mesos
El nuacutecleo de DCOS estaacute basado en Apache Mesos un proyecto de coacutedigoabierto creado por la Universidad de California Berkeley y desarrollado actual-mente por la fundacioacuten Apache Se trata de un administrador de clusters queabstrae los recursos y los dispone para diferentes aplicaciones y entornos de tra-bajo distribuidos (frameworks) mediante una interfaz comuacuten En el momento deredaccioacuten de este proyecto Apache Mesos soportaba una variedad de entornosque abarcaba desde Big Data (Apache Spark Hadoop) hasta bases de datos(Cassandra Hypertable)
15
Arquitectura
Mesos se basa en la asignacioacuten de dos roles diferentes a los nodos
Maestros (Masters) Se encargan de la gestioacuten y reparticioacuten de los recursospara los diferentes entornos de trabajo mediante ldquoofertas de recursosrdquo deacuerdo a los disponibles y a la poliacutetica de asignacioacuten (planificacioacuten en dosniveles)
Esclavos (Slaves) Ordenadores donde se ejecutaraacuten las aplicaciones y cu-yos recursos son ofertados por los maestros
En el caso de fallo del maestro las tareas pueden seguir ejecutaacutendose perono se podraacute asignar nuevos recursos ni tareas por ello pueden existir varios enel cluster para configuraciones de alta disponibilidad pero soacutelo uno orquesta alos esclavos
Para la eleccioacuten del master liacuteder Mesos usa Apache ZooKeeper un proyectode software desarrollado por la misma fundacioacuten cuyo objetivo es proveer deun servicio de configuracioacuten centralizado y registro de nombres8
Por otra parte los entornos de trabajo son los programas que deciden final-mente queacute recursos se van a usar y se encargan de que los esclavos ejecuten lastareas Eacutestos se ejecutan sobre Mesos y constan de dos componentes
Planificador (Scheduler) Optimiza y decide los recursos a utilizar de losofertados informando a los Masters
Procesador (Executor) Ejecuta las aplicaciones o servicios en los esclavos
El objetivo final es conseguir una interfaz liviana tolerante a fallos paracualquier tipo de entorno de trabajo de tal manera que en los esclavos del clusterpuedan ejecutarse simultaacuteneamente tareas con necesidades y duracioacuten diferentesPara ello se basa en dos conceptos asignacioacuten y aislamiento de recursos
Asignacioacuten de recursos
En el cluster pueden coexistir entornos de trabajo con tareas de larga dura-cioacuten y con gran consumo de recursos con tareas cortas que los ocupan y liberancon rapidez El maestro integra un moacutedulo de asignacioacuten de recursos (allocationmodule) que se encarga del algoritmo de distribucioacuten
En el momento de escribir este proyecto estaban desarrollados dos moacutedulosuno mediante el cual el usuario puede asignar prioridades y otro que implementa
8httpszookeeperapacheorg
16
el algoritmo Dominant Resource Fairness9 a grandes rasgos se determina entodos los esclavos la tarea en ejecucioacuten que necesita maacutes recursos y se calcula laproporcioacuten del recurso de mayor peso con respecto al total por ejemplo si unatarea ocupa 2 GB de memoria con respecto a 10 GB totales que tiene el clusterse le asigna un dominant share del 20 la tarea se asignaraacute al nodo con menordominant share
Aislamiento de recursos
Para conseguir que tareas de diferentes entornos de trabajo y con distin-ta naturaleza se ejecuten simultaacuteneamente en un mismo nodo Mesos usa loscontenedores Linux (descritos en la seccioacuten 3)
Funcionamiento
La figura 9 muestra el esquema de la arquitectura de Apache Mesos conalta disponibilidad (tres maestros) y con dos entornos de trabajo ejecutaacutendo-se Hadoop que permite el almacenamiento y procesamiento de gran cantidadde datos para proyectos de big data y un sistema que implementa la interfazsistema de paso de mensajes MPI
Como se puede observar el sistema ZooKeeper elige a un solo maestro comoliacuteder y eacuteste orquesta el cluster comunicando los esclavos con los planificadoresde los diferentes entornos de trabajo Tambieacuten se puede observar como las tareasde los distintos entornos estaacuten distribuidas entre los tres esclavos disponibles
Figura 9 Arquitectura de Apache MesosFuente httpsmesosapacheorg
El proceso de asignacioacuten se realiza como sigue en primer lugar un usuariosolicita la ejecucioacuten de una tarea mediante la interfaz de cada entorno de traba-jo (interfaz graacutefica API HTTP ) De forma paralela un esclavo informa almaestro de los recursos que tiene libres En consecuencia eacuteste se lo notifica almoacutedulo de asignacioacuten que en funcioacuten de su configuracioacuten decide cuaacutento ofertar
9httpspeopleeecsberkeleyedu~aligpapersdrfpdf
17
y a queacute entorno de trabajo y enviacutea la oferta a los planificadores Eacutestos respondenal maestro con queacute recursos ha decidido usar para cada tarea Finalmente lastareas son enviadas al esclavo seleccionado el cual asigna los recursos indicadosal procesador (executor) quien finalmente las ejecuta
Cabriacutea pensar que esta metodologiacutea puede conducir a situaciones en lasque un entorno podriacutea quedarse con tareas sin ejecutarse a la espera de unaoferta satisfactoria para ello Mesos implementa un sistema de filtros medianteel cual los entornos especifican los requisitos miacutenimos que debe cumplir unaoferta por ejemplo se puede especificar en queacute nodos debe desplegarse la tareaEste sistema estaacute disentildeado asiacute con el objetivo de mantener lo maacutes transparenteposible esta herramientas de forma que acepte entornos de trabajo de distintasnaturalezas
512 Ejemplos de uso
Grandes empresas estaacuten usando Apache Mesos con eficacia de acuerdo a susnecesidades e infraestructuras Caben destacar
Ebay En el modelo de implementacioacuten continua en esta empresa10 cadadesarrollador cuenta con su propia instancia que se ejecuta en una maacutequinavirtual dedicada lo que ha conllevado un uso de los recursos poco eficiente Enuna prueba de concepto consiguieron realizar una herramienta de integracioacutencontinua distribuida basada en un cluster con Apache mesos y con el entornoMarathon y Jenkins
Apple Anuncioacute que el motor de su famosa herramienta de asistencia per-sonal para iPhones Siri estaacute desplegada sobre Apache Mesos11 Para ello handesarrollado su propio entorno para facilitar a los ingenieros a desplegar los ser-vicios que la herramienta necesita para resolver las peticiones de los usuarios
Twitter Desarrolloacute su propio entorno denominado Aurora y actualmentegestionan sus recursos y miden el coste de las tareas que los empleados usancon el objetivo de que sean conscientes del gasto que puede suponer un usoinadecuado de la infraestructura12
10httpwwwebaytechblogcom20140404delivering-ebays-ci-solution-with-apache-mesos-part-i11httpwwwbusinessinsidercomapple-siri-uses-apache-mesos-2015-812httpswwwlinuxcomNEWS4-UNIQUE-WAYS-UBER-TWITTER-PAYPAL-AND-HUBSPOT-USE-APACHE-MESOS
18
52 Nomad
Herramienta de coacutedigo abierto de gestioacuten de clusters creada y desarrolladapor Hashicorp13 que permite el despliegue de aplicaciones y procesos de formadistribuida
Las principales diferencias con Apache Mesos a grandes rasgos son
Arquitectura maacutes ligera Nomad soacutelo requiere de un fichero para funcionarejecutaacutendolo con las correspondientes configuraciones en todos los nodosrealiza las funciones de gestioacuten del cluster eleccioacuten de liacuteder planificacioacutende recursos y ejecucioacuten de las tareas
Centro de datos y regiones muacuteltiples Su arquitectura estaacute orientada afacilitar la gestioacuten de diferentes centros de datos geograacuteficamente distri-buidos
Entorno de ejecucioacuten Las tareas se definen y son interpretadas mediantecontroladores integrados en Nomad que se valen de los recursos y herra-mientas de los nodos clientes para ejecutarlas Esta integracioacuten dificultael desarrollo de controladores por parte de terceros a diferencia de Mesosque delega dicha responsabilidad en los entornos de trabajo externos alproyecto
Usa un planificador de estado compartido con respecto a la planificacioacutenen dos niveles de Mesos
Antes de entrar en maacutes detalle en la arquitectura es importante definir lossiguientes teacuterminos
Controlador (Driver) Software que se encarga de interpretar las definicionesde las tareas y ejecutarlas semejante a los procesadores de los entornosde trabajo de Mesos A la hora de redactar este proyecto Nomad contabacon controladores para contenedores Docker virtualizacioacuten de maacutequinasmediante el emulador QEMU aplicaciones java y archivos binarios
Grupo de trabajo (Task Group) Conjunto de tareas que se ejecutan en elmismo nodo cliente
Trabajo (Job) Conjunto loacutegico de tareas y grupos de trabajo que se despliegana la vez
Asignacioacuten (Allocation) Relacioacuten entre un grupo de trabajo y el cliente don-de se ejecuta
Evaluacioacuten (Evaluation) Proceso mediante el cual Nomad planifica y ges-tiona el registro o actualizaciones de los trabajos
13httpswwwhashicorpcom
19
Nomad sigue una arquitectura maestro-esclavo similar a la de Apache Mesosmuacuteltiples servidores acuerdan entre siacute un liacuteder que gestiona la planificacioacuten detareas en los clientes que soacutelo conocen sus asignaciones y las ejecutan
Todos los servidores participan paralelamente en tareas de planificacioacuten derecursos y asignacioacuten de tareas y ademaacutes entre ellos eligen un liacuteder que seencarga de la coordinacioacuten de la suscripcioacuten de los clientes al cluster y de lagestioacuten de las peticiones
Los clientes estaacuten configurados para comunicarse con el servidor usando lla-madas a procedimiento remoto (RPC por sus siglas en ingleacutes) que permite unordenador ejecutar coacutedigo en otra maacutequina Mediante esta tecnologiacutea los nodosclientes avisan de su estado e informa de sus asignaciones recursos y controla-dores disponibles
Existe la posibilidad de gestionar varios centros de datos agrupados en regio-nes eacutestas son independientes pero permite definir tareas o comprobar el estadode todas ellas desde cualquier punto A continuacioacuten se muestra una figura dela arquitectura a alto nivel de esta configuracioacuten
Figura 10 Arquitectura multi-regioacuten en NomadFuente httpswwwnomadprojectio
La herramienta se sustenta sobre tres protocolos fundamentales un protocolode consenso entre los servidores para compartir informacioacuten sobre su estado yel liacuteder un protocolo Gossip para la gestioacuten entre regiones y el planificador detareas
521 Protocolo de consenso Raft
El objetivo es obtener consistencia en un conjunto de nodos que comparteninformacioacuten es decir si un cliente realiza un cambio que todos los nodos veanla misma informacioacuten a la vez y ademaacutes sea tolerante a fallos Para ello se basaen el algoritmo Raft[13] que se detalla brevemente a continuacioacuten
20
Los nodos participantes en el algoritmo pueden estar en tres estados
Liacuteder (Leader) Todos los cambios que realicen en el cluster pasan por eacutel pri-mero
Seguidor (Follower) Nodo pasivo cuya responsabilidad es responder a laspeticiones del nodo liacuteder
Candidato (Candidate) Maacutequina que no ha encontrado liacuteder y solicita sueleccioacuten
Supongamos que tenemos cinco equipos que acaban de arrancar el protocoloEn la figura 11 se observan los nodos y sus respectivos registros a la derecha
Figura 11 Equipos sin consenso ejecutando el protocolo RAFTFuente httpsgithubcomongardieraftscope
Al comenzar todos los nodos son seguidores esperando recibir comunicacioacutende un nodo que actuacutee como liacuteder Cada nodo tiene un tiempo de espera aleatoriodespueacutes del cual si no es informado por un liacuteder pasa a estado candidato y pideel ldquovotordquo al resto de los participantes El algoritmo divide el tiempo en plazos uncandidato pasa a liacuteder si recibe la mayoriacutea de los votos en un plazo determinadoSe define mayoriacutea o cuoacuterum (quorum) comolceil
N2rceil
+ 1 (1)
donde N representa el nuacutemero de nodos
Para el ejemplo propuesto de 5 equipos se requieren de 3 votos Soacutelo losnodos que se encuentren en estado seguidor pueden votar una uacutenica vez a laprimera solicitud que reciba dentro de un plazo
Supoacutengase que el nodo denotado con S1 ha cumplido su tiempo de espera yrealiza la peticioacuten de voto (figura 12) A partir de este momento se pueden dartres casos
La maacutequina gana la eleccioacuten y pasa a ser liacuteder informando al resto
Otro servidor se establece como liacuteder en el mismo momento
Varios nodos pasan a ser candidatos por lo que ninguno consigue los votos
21
Figura 12 Un equipo pasa a estado candidato (RAFT)
Si un candidato recibe un aviso de un liacuteder en el mismo plazo el primeropasa a ser seguidor y se acaba la eleccioacuten de liacuteder
Por otro lado si un equipo candidato no recibe los votos en el plazo y agotasu tiempo de espera avanza al siguiente plazo y repite el proceso de votacioacutenLa tercera posibilidad puede conllevar a un estado indefinido ya que varioscandidatos pueden agotar su tiempo de espera al mismo tiempo y repartir losvotos Para solventarlo el algoritmo establece tiempos de espera aleatorios paralos candidatos
Siguiendo con el ejemplo propuesto el servidor S1 pasa a ser el liacuteder Cadacierto tiempo eacuteste debe realizar avisos a los nodos seguidores para no agotar sutiempo de espera
En este momento el cluster de servidores estaacute en ldquoconsensordquo y la informacioacutenen todos los nodos estaacute actualizada Un cambio en la informacioacuten inicia unproceso de replicacioacuten el liacuteder registra el cambio lo pasa al resto de nodos yuna vez eacutestos responden el cambio se hace efectivo
Supoacutengase que se realiza un cambio en los datos en la figura 13 en la partederecha se observa el cambio en el registro del servidor S1 que informa a losnodos seguidores En consecuencia los nodos registran el cambio y responden aS1
Figura 13 Cambio en un registro (RAFT)
Una vez el cuoacuterum (en el ejemplo tres equipos) informa al liacuteder de que
22
ha registrado el cambio el liacuteder lo hace efectivo en su sistema y notifica a losnodos que hacen lo mismo En la figura 14 el enviacuteo todaviacutea no ha llegado ala maacutequina S3 y se observa que no ha hecho efectivo el cambio (en el registroaparece punteado)
Figura 14 Aprobacioacuten del resto de equipos (RAFT)
Este protocolo funcionaraacute correctamente mientras exista un nuacutemero de nodosen funcionamiento igual o superior al cuoacuterum en el ejemplo propuesto elcuoacuterum es tres por lo que el sistema puede tolerar la caiacuteda de dos de los equipos
522 Protocolo gossip SWIM
Nomad permite la gestioacuten simultaacutenea de varios centros de datos reparti-dos en regiones geograacuteficamente separadas requiriendo de un protocolo ligeroque mantenga a los miembros actualizados sobre los participantes del conjun-to Para ello usa una ligera variante del protocolo SWIM[3] (Scalable Weakly-consistent Infection-style Process Group Membership Protocol) desarrollada porHashiCorp Estaacute clasificado como un protocolo de tipo gossip que debe su nom-bre a la semejanza con coacutemo se distribuye un rumor en una red social
SWIM se sustenta en dos caracteriacutesticas fundamentales la deteccioacuten de fallosy la distribucioacuten de la informacioacuten relativa a los miembros A continuacioacuten sedetalla el funcionamiento de ambos componentes
Deteccioacuten de fallos
Este componente tiene dos paraacutemetros el periodo de protocolo T y el nuacutemerode subgrupos de deteccioacuten de fallos k en los que se dividen los nodos Paracomprobar la comunicacioacuten entre dos maacutequinas usa la utilidad ping basadaen el protocolo ICMP La deteccioacuten de caiacuteda de un servidor sigue el siguientealgoritmo
Durante el periodo T cada miembro Mi de un subgrupo elige otro al azar Mjdel mismo subgrupo y le enviacutea un mensaje ping para comprobar su estado Enel caso de que se cumpla un tiempo de espera determinado por una estimacioacuten
23
del tiempo de ida y vuelta (RTT por sus siglas en ingleacutes) de la red y no hayarespuesta Mi le vuelve a enviar un mensaje ping indirectamente a traveacutes deun nuacutemero k de miembros escogidos aleatoriamente De no recibir ninguna res-puesta Mi establece que Mj ha sufrido un fallo y lo etiqueta como ldquosospechosordquoinformando al componente de distribucioacuten
Figura 15 Diagrama de tiempo del protocolo SWIMFuente httpswwwcscornelledu
Componente de distribucioacuten
Se encarga de informar de cualquier cambio en los miembros a todo el con-junto Los eventos de nodo caiacutedo y la unioacuten o disociacioacuten de un miembro setransmiten a todos los servidores para que actualicen sus lista Para distribuirla informacioacuten a todos los nodos se podriacutea usar el meacutetodo de multicast perosuele estar deshabilitado Por ello se utiliza una teacutecnica de transmisioacuten denomi-nada Piggybacking mediante la cual se adjunta a los propios mensajes PINGy ACK del algoritmo la informacioacuten a distribuir reduciendo asiacute la congestioacutenen la red
523 Planificacioacuten
Proceso encargado de distribuir las tareas entre los nodos clientes de acuerdoa su estado
El planificador de Nomad estaacute basado en las publicaciones de Google sobresus herramientas de gestioacuten de clusters Borg y Omega14 y entiende los trabajosdescritos por el usuario como un estado deseado es decir su despliegue en unamaacutequina cliente de forma correcta y los clientes como el estado actual esto eslo que se encuentra en ejecucioacuten El registro actualizacioacuten o cancelacioacuten de un
14httpresearchgooglecompubspub43438html
24
trabajo asiacute como el fallo de un nodo cliente implican un cambio de estado atramitar por el sistema lo que se define como evaluacioacuten (evaluation) Esto uacutelti-mo supone comparar el estado actual (clientes) con el estado deseado (conjuntode trabajos registrados) y enviarlos a los planificadores correspondientes que seencargaraacuten de asignar las tareas a los nodos clientes
Figura 16 Procedimiento de asignacioacuten en NomadFuente httpswwwnomadprojectio
En la figura 16 se observa el flujo de trabajo en el que las distintas evalua-ciones se encolan en el evaluation broker que se ejecuta en el servidor liacuteder ygestiona las evaluaciones pendientes asignaacutendoles prioridades
A continuacioacuten los nodos servidores ejecutan los scheduling workers queprocesan las evaluaciones llamando a los distintos planificadores que generanun plan de asignacioacuten esto es un conjunto de relaciones entre las tareas y losnodos clientes donde se ejecutaraacuten Este proceso se divide en dos fases primerose descartan aquellos clientes que no cumplan los requisitos y posteriormentese asigna una calificacioacuten al resto Se selecciona el nodo con mayor puntuacioacuteny se encola el plan en el gestor que se ejecuta en el servidor liacuteder Existen tresplanificadores de acuerdo al tipo de trabajo
Service Incluye aquellos trabajos que estaacuten destinados a ejecutarse en un pe-riacuteodo largo de tiempo Para realizar las asignaciones el planificador evaluacuteala mayor parte de los nodos y usa una versioacuten del algoritmo Best fit in-fluenciada por el trabajo de Google en su herramienta Borg Se trata deun algoritmo de planificacioacuten que sacrifica tiempo a cambio de maximizarel rendimiento de los clientes asignando la tarea a la maacutequina que tengala mayor carga de trabajo con el objetivo de reducir equipos en funciona-
25
miento
Batch Tareas que incluyen listas de comandos en general de menor duracioacuteny que no requieren interaccioacuten con el usuario Se vale del algoritmo deSparrow desarrollado por la universidad de Berkeley15 para limitar losnodos clientes a evaluar
System Trabajos destinados a ejecutarse en todos los nodos incluso los que seunen al cluster posteriormente
Core Mantenimiento interno de Nomad
Una vez se ha realizado el proceso de planificacioacuten el nodo liacuteder lo registra enla cola de planes (plan queue) que se encarga de asignarles prioridad y manejarcondiciones de carrera es decir que no accedan a los recursos de los clientes sincontrol y evitar que eacutestos superen su capacidad
La maacutequina liacuteder del conjunto puede de este modo aceptar una asignacioacuteny ser ejecutada por los clientes o por el contrario rechazaacutersela al planificadorlo que implicariacutea realizar un plan parcial o totalmente nuevo
Finalmente el estado de las evaluaciones se actualizan y los clientes soninformados de las asignaciones ejecutaacutendose las tareas
15httppeopleeecsberkeleyedu~keopublicationssosp13-final17pdf
26
6 Casos de uso y despliegue
Con el objetivo de mostrar las posibles utilidades que este tipo de sistemaspueden tener en las infraestructuras TI actuales se han desplegado las dos he-rramientas en la nube Microsoft Azure usando su servicio cloud de instancias demaacutequinas virtuales Linux para simular un conjunto de ordenadores conectadosentre siacute por una red LAN Sobre ellas se ha implementado dos casos de usouna aplicacioacuten web con una arquitectura con cierta orientacioacuten a microserviciosy un sistema de integracioacuten continua
El coacutedigo y todos los ficheros de configuracioacuten se pueden encontrar en elrepositorio del proyecto en GitHub16
61 Aplicacioacuten Web
Se busca simular el proceso de adaptacioacuten de una solucioacuten web para su des-pliegue en un sistema distribuido con las herramientas anteriormente descritascon el objetivo de aumentar tanto su escalabilidad como disponibilidad medianteredundancia
Se ha partido de una aplicacioacuten ya existente17 un servicio de almacenamien-to y reproduccioacuten de canciones A grandes rasgos este servicio permite crearusuarios subir canciones con sus respectivas portadas tener playlists propias yescuchar las canciones a traveacutes de un navegador web
La solucioacuten estaacute dividida en 4 partes (figura 17)
Una vista web con la loacutegica
Un almacenamiento conectado en red (NAS por sus siglas en ingleacutes)
Una API REST para gestionar las peticiones al almacenamiento
Base de datos NoSQL basada en MongoDB
La nueva tendencia de los proyectos web es su implementacioacuten en contene-dores Docker ya que facilitan su portabilidad y ofrecen un procedimiento dedespliegue raacutepido sobre todo a la hora de desarrollar y realizar pruebas en en-tornos de produccioacuten simulados Por ello en este caso se va a hacer uso de los
16httpsgithubcomAntonioAlfrzCloud-Orchestrators17httpsgithubcomsonsoleslpCDPSfy
27
motores de orquestacioacuten de contenedores de ambas herramientas Marathon enDCOS y el controlador Docker en el caso de Nomad
Figura 17 Arquitectura aplicacioacuten web
A continuacioacuten vamos detallar el despliegue en ambas herramientas de es-ta solucioacuten y observar tanto queacute dificultades se encuentran como que ventajasofrecen El objetivo final es adaptar el proyecto modificaacutendolo lo menos posiblecon objeto de analizar la capacidad de estas herramientas para desplegar cual-quier aplicacioacuten sin que eso conlleve la modificacioacuten de la arquitectura de eacutestaes decir que no sea dependiente del entorno
611 DCOS
Se ha descrito DCOS como una herramienta que se despliega sobre un con-junto de ordenadores y que permite instalar gestionar el despliegue de sistemasdistribuidos
Microsoft Azure cuenta con una plantilla para desplegar en su servicio cloudun cluster de maacutequinas virtuales con DCOS ya instalado que cuenta con
Maacutequinas maestras (1 3 o 5 a seleccionar por el usuario) configuradascomo un conjunto de disponibilidad esto eso Azure da ciertas garantiacuteasde que al menos una maacutequina estaraacute en funcionamiento
Maacutequinas agentes Por motivos de seguridad se distinguen dos roles
bull Nodos privados solo accesibles desde la red interna y configuradoscomo un conjunto de escala un recurso de Azure para gestionar ydesplegar maacutequinas con configuraciones ideacutenticas para permitir unraacutepido escalado
bull Un equipo conectado accesible desde Internet a travntildees de un balan-ceador de carga puacuteblico y situado en una subred externa
28
Dos balanceadores de carga
bull La interfaz puacuteblica del cluster que se conecta con el cliente puacuteblicobull Acceso a los equipos maestros para el administrador que soacutelo permiteconexioacuten mediante SSH y credenciales
Almacenamiento para todas las maacutequinas
Configuraciones necesarias de red y seguridad
En la figura 18 se observa un diagrama de la infraestructura
Figura 18 Infraestructura en Azure
El primer obstaacuteculo es la persistencia de estado de la aplicacioacuten que seconsigue gracias a una base de datos no relacional basada en MongoDB asiacutecomo el almacenamiento de las canciones Para implementarla tenemos variasposibilidades
Montar un sistema externo de almacenamiento conectado en red en todoslos agentes donde se ejecuten las tareas de esta manera si una tarea pasade un nodo a otro por cualquier motivo puede tener acceso a los mismosficheros (opcioacuten del caso de uso original)
Implementar un sistema de ficheros distribuidos en los agentes
Usar los servicios de almacenamiento de las nubes puacuteblicas
Aprovechar el sistema de voluacutemenes persistentes de Apache Mesos Eacutestepermite reservar recursos de un agente de forma que al arrancar una tarease crea un volumen independiente del ciclo de vida de eacutesta con ello esosrecursos donde se ha almacenado la informacioacuten pueden volver a ofrecerseal mismo entorno de tal manera que otra tarea pueda acceder a ella
DCOS aprovecha este sistema de voluacutemenes persistentes y permite instalarbases de datos distribuidas como ArangoDB o Apache Cassandra sin embargoesto implicariacutea modificar todo el coacutedigo referente al modelo de la base de datos
29
Por motivos de eficiencia y latencia asiacute como de una mayor gobernabilidadde los datos la mejor opcioacuten es usar el recurso de voluacutemenes persistentes queofrece Apache Mesos ya que de esta manera se gestionariacutea la aplicacioacuten completamediante una uacutenica herramienta Sin embargo esto implica que la informacioacutense encuentra exclusivamente en el agente donde se haya ejecutado la tarea y porlo tanto se sigue requiriendo de software externo para distribuir la informacioacutenpara que se accesible para todos los agentes A la hora de realizar este proyectose encontraba en desarrollo Flocker una solucioacuten desarrollada por ClusterHQque permite compartir los voluacutemenes de Docker a traveacutes de un cluster quesi bien es compatible con el planificador de Mesos el proyecto se encontrabatodaviacutea en fases tempranas de desarrollo y los sistemas de almacenamiento quesoporta quedaban fuera del aacutembito de este trabajo
Por todo ello dado que las maacutequinas se han desplegado en la nube puacuteblicade Azure se decidioacute usar su servicio de almacenamiento de objetos para lascanciones y otra maacutequina para desplegar MongoDB y asiacute mantener el modelode datos original de la aplicacioacuten La diferencia del almacenamiento de obje-tos con respecto a nivel de fichero es que el primero no tiene jerarquiacutea paraorganizar los archivos eacutestos se guardan como objetos (con sus metadatos) enun mismo espacio soacutelo diferenciaacutendose por un identificador uacutenico esto implicaentre otras cosas que se puede acceder a un fichero dado uacutenicamente su IDindependientemente de la localizacioacuten fiacutesica de eacuteste facilitando pues la gestioacuteny el desarrollo
El coacutedigo del proyecto se ha modificado en los siguientes apartados
Las direcciones de la base de datos y los balanceadores de carga asiacute comosus puertos estaban originalmente fijos Se han configurado como variablesde entorno para facilitar el descubrimiento del servicio y hacer transpa-rente la aplicacioacuten al entorno de despliegue
La API REST se ha adaptado al almacenamiento en Azure en vez de enlocal
Estas modificaciones no suponen un cambio sustancial pero permiten separala persistencia de las tareas ejecutadas por DCOS lo que facilita en granmedida su ejecucioacuten al ser totalmente sin estado y ademaacutes implican tenerlos datos bajo un mayor control
Para la orquestacioacuten de contenedores se va a usar el entorno Marathondesarrollado tambieacuten por Mesosphere Eacuteste se puede usar a traveacutes de una interfazgraacutefica la interfaz de liacutenea de comandos (en lo que sigue CLI por sus siglas eningleacutes) de DCOS o con su API HTTP
Primero se han publicado la imaacutegenes de los contenedores que encapsulanla interfaz web y la api de la aplicacioacuten en el repositorio puacuteblico DockerHub
Los despliegues en este entorno se describen mediante ficheros JSON en losque se detalla entre otras opciones la imagen del contenedor los puertos a usar
30
los recursos que debe ocupar en un nodo o las instrucciones de monitorizacioacuten
Para el servicio de descubrimiento DCOS ofrece la posibilidad de asignardirecciones IP virtuales (VIP por sus siglas en ingleacutes) a tareas que se compartenen todos los nodos DCOS lleva integrado un balanceador de carga a nivel TCP(el componente denominado Minuteman) que balancea entre las direccionesvirtuales de las tareas y todas las instancias de eacutestas a lo largo del cluster Estoes necesario por dos motivos equilibrar la carga de los equipos con el fin deevitar un punto de uacutenico fallo mediante redundancia y evitar la contienda dedirecciones al ejecutar las tareas en puertos aleatorios
Este balanceador de carga estaacute basado en el trabajo de Michael Mitzenma-cher The Power of Two Choices in Randomized Load Balancing18 A grandesrasgos el algoritmo mantiene una media moacutevil exponencial de latencias paracada destino (backend) ademaacutes de las caiacutedas consecutivas Si un destino noresponde a una negociacioacuten en tres pasos (three way handshake) de forma con-secutiva en un periodo inferior a 5 ms se considera caiacutedo El algoritmo iterasobre los destinos disponibles en base a su histoacuterico de fallos y escoge dos deforma aleatoria de los cuales coge el de mejor meacutetrica
Las direcciones virtuales soacutelo se pueden resolver dentro del cluster porello para implementar la interfaz puacuteblica de la aplicacioacuten esto es el balancea-dor de carga de la interfaz web usaremos un paquete de DCOS denominadomarathon-lb un balanceador basado en HAProxy y adaptado por MesosphereEn este caso equilibra la carga de todas instancias de las tareas ejecutadas porel entorno Marathon por sus etiquetas y permite ademaacutes definir como puntode entrada muacuteltiples hosts virtuales definidos por sus nombres completos dedominio (FQDN por sus siglas en ingleacutes) en nuestro caso la interfaz puacuteblicadel balanceador de Azure para los agentes
Por motivos de seguridad todas las tareas se ejecutan en los agentes privadoses decir los que son exclusivamente accesibles desde la red interna Por su partemarathon-lb se ejecuta en el agente puacuteblico que cuenta con IP puacuteblica y lospuertos 80 (HTTP) y 8080 abiertos de forma que la aplicacioacuten sea accesibledesde Internet Esto es posible debido a que Apache Mesos permite reservarrecursos mediante roles asignados a nodos para un uso especiacutefico De esta formala arquitectura vista desde la aplicacioacuten quedariacutea como en la figura 19
18httpswwweecsharvardedu~michaelmpostscriptstpds2001pdf
31
Figura 19 Arquitectura de la aplicacioacuten web en DCOS
Ejecucioacuten
A la hora de desplegar la aplicacioacuten DCOS puede gestionarse medianteuna interfaz graacutefica o una interfaz de liacutenea de comandos La primera se accedea traveacutes de un navegador web en el puerto 80 (HTTP) y permite instalar losentornos disponibles observar el estado de los nodos y las tareas que se estaacutenejecutando y los ficheros de registros que eacutestas generan
La CLI permite el control desde un nodo o una maacutequina remota (suponiendoque los maestros tienen IP puacuteblica y el puerto 80 abierto) ya que DCOS tieneun sistema de autorizacioacuten que permite tener una interfaz puacuteblica con ciertasgarantiacuteas de seguridad
Por su parte cada entorno de trabajo puede ser controlado por la CLI peroademaacutes cuenta con sus propias interfaces Marathon expone una API HTTPen el puerto 8080 de la direccioacuten puacuteblica de los maestros del cluster asiacute comootra interfaz graacutefica Para desplegar un contenedor se podriacutea usar la CLI
$ dcos marathon app add lt f i l e j songt
O la API HTTP
$ cu r l minusX POST http lt ip_maestro gt8080v2apps minusd ltf i l e jsongt minusH Contentminustype app l i c a t i o n j son
32
612 Nomad
La arquitectura de Nomad es maacutes sencilla ya que solo requiere de un ficheroejecutable en todos los nodos para funcionar Si DCOS es la base de instala-cioacuten de entornos de terceros Nomad integra todas las funcionalidades baacutesicasesto es gestor de recursos planificador y ejecutor en los nodos cliente Estaherramienta cuenta con un menor tiempo de desarrollo y en el momento deescribir este documento cuenta exclusivamente con los siguientes controladoresen comparacioacuten con los entornos de DCOS
Motor Docker es decir funcioacuten de orquestacioacuten de contenedores
Ejecucioacuten de archivos binarios como comandos de Shell
Ejecucioacuten de aplicaciones Java
Virtualizacioacuten de maacutequinas mediante tecnologiacutea QEMU
Todos ellos necesitan que la tecnologiacutea subyacente esteacute instalada en las maacute-quinas clientes (Docker Java QEMU) Actualmente no permite el registro decontroladores por parte de terceros aunque estaacute planificado en un futuro ofreceruna interfaz para su desarrollo
Nomad no cuenta con el servicio de descubrimiento sin embargo puede inte-grarse con la herramienta Consul desarrollada por la misma empresa Por otrolado para el balanceo de carga usaremos un contenedor Docker con HAProxyuna herramienta de coacutedigo abierto que ofrece tanto servicios de proxy como debalanceador y cuyos ficheros de configuracioacuten completaremos con el proyectoConsul Template19
Consul
Consul sigue la misma arquitectura que Nomad es decir un nodo servidorque orquesta un conjunto de maacutequinas clientes y permite a los procesos que seejecutan en los equipos definirlos como servicios ofreciendo diversas caracteriacutes-ticas entorno a estos de los cuales vamos a usar dos
Descubrimiento de servicio Las maacutequinas clientes publican en el cataacutelogode servicios las tareas en ejecucioacuten y Consul les asigna nombres de dominioaccesibles por todos los miembros del cluster a traveacutes de la interfaz DNSincluida en esta herramientaConsul se integra con Nomad de forma que todas las tareas que se ejecu-ten en la segunda son automaacuteticamente publicados como servicios de laprimera de esta manera no hace falta conocer la direccioacuten de la maacutequinacliente donde se esteacute ejecutando el proceso ya que se puede acceder a eacutela traveacutes de su nombre de dominio de forma transparente Por ejemplo si
19[httpsgithubcomhashicorpconsul-template]
33
ejecutamos una tarea con ID web en el puerto 8080 se puede acceder aella en la direccioacuten webserviceconsul8080Para que las direcciones propias de Consul las resuelva su propio DNS y noel que esteacute asignado por defecto en la maacutequina usaremos la herramientadnsmasq20 que permite especificar la direccioacuten de un servidor DNS paraconsultas de direcciones especiacuteficas
Monitorizacioacuten Permite realizar comprobaciones del servicio y seguir su esta-do Aprovecharemos esta funcionalidad tanto para definir el propio procesode Nomad como servicio de Consul como las tareas desplegadas
HAProxy + Consul Template
HAProxy es una solucioacuten versaacutetil de coacutedigo abierto que ofrece solucionesde balanceo de carga y proxy Existen otras herramientas en el mercado comoNGINX o ldirectord sin embargo HAProxy suponiacutea una solucioacuten sencilla deconfigurar para mostrar el caso de uso
El uso de estas herramientas se debe a dos motivos para que no existacontienda con respecto a los puertos de los clientes usados por las tareas eacutestos sevan a asignar de forma dinaacutemica lo que en principio implicariacutea que la aplicacioacutendeberiacutea realizar consultas DNS de tipo SRV (que incluye puertos) a la interfazde Consul y balancear la carga entre tareas por redundancia y capacidad
Como la direccioacuten IP y puerto son variables cada vez que las tareas seactualicen o se reasignen es necesario volver a configurar HAProxy de formamanual Por ello HashiCorp ha desarrollado un programa denominado Con-sul Template que realiza peticiones sucesivas a la interfaz HTTP de Consul delas direcciones fiacutesicas de un servicio y reinicia automaacuteticamente el proceso deHAProxy Asiacute definiendo estas tareas como servicios Consul podremos tantomonitorizarlas como escalar las tareas dinaacutemicamente sin necesidad de cambiarel balanceador A partir del contenedor Docker oficial de HAProxy se ha desa-rrollado otro con la configuracioacuten baacutesica y con Consul Template para desplegarlocomo una tarea en Nomad
Despliegue
Se ha usado el mismo coacutedigo que en el apartado anterior con la persistenciaen el servicio de almacenamiento de Azure Desde la perspectiva del hardwarese implementaraacute la misma infraestructura que en el caso de DCOS (figura 18)estos es definiremos dos tipos de maacutequinas clientes un agente que se conectaraacutecon el balanceador de carga con nombre de dominio puacuteblico y donde se desple-garaacute el balanceador de carga de la vista web y agentes privados no accesiblesdesde fuera del cluster y donde se ejecutaraacuten el resto de tareas en la red inter-na La principal diferencia radica en las tareas que ejecutan HAproxy y ConsulTemplate que sustituye a las direcciones IP virtuales que ofrece DCOS
20httpwwwthekelleysorgukdnsmasqdochtml
34
Figura 20 Despliegue en Azure de Nomad+Consul
Cabe matizar que los balanceadores basados en HAProxy se implementanpor necesidad de la aplicacioacuten para el descubrimiento del servicio a diferenciade los de Azure que se implementan por motivos de seguridad y escalabilidaddel cluster en siacute
Configuracioacuten Nomad
Los ficheros de configuracioacuten de las maacutequinas maacutester y cliente son similaresy comparten la mayoriacutea de las opciones como por ejemplo el nombre del nodoo la interfaz de red donde escucha Nomad las peticiones Sus opciones son engeneral auto-explicativas sin embargo existen dos detalles que matizar
El proceso de Nomad escucha las peticiones tanto de los protocolos deconsenso como del usuario a traveacutes de una interfaz de red que se debeindicar en el fichero de configuracioacuten
En el caso de los clientes se deben indicar las direcciones de los servidoresdel cluster sin embargo se trata de un sistema dinaacutemico en el que losnodos pueden sufrir errores y cambiar de direccioacuten Por ello se ha definidoNomad como un servicio de Consul y asiacute poder definir la direccioacuten de losservidores como un nombre de dominio no por su direccioacuten fiacutesica que elservidor DNS de Consul se encargaraacute de resolver
Por defecto Nomad usa los siguientes puertos
API HTTP 4646 Peticiones HTTP y recepcioacuten de oacuterdenes mediante laliacutenea de comandos
RPC 4647 Protocolo de consenso entre los nodos del cluster
Serf 4648 Protocolo de gossip entre los servidores de los centros de datosgobernados por Nomad
35
Los dos uacuteltimos deben ser interfaces alcanzables por otros nodos sin embargo laAPI HTTP por motivos de seguridad deberiacutea ser local ya que en caso contrariocualquier persona con acceso a ella tiene el control sobre la herramienta Eacutestasolo deberiacutea estar accesible en un servidor o gestionarlo mediante una terminalSSH por ejemplo En este trabajo al ser una prueba de concepto se ha abiertoen todos los nodos
Trabajos de Nomad
Las tareas se detallan en ficheros con formato HashiCorp Configuration Lan-guage un derivado del formato JSON creado por la empresa que le da nombrecompatible con eacuteste y que permite comentarios
En estos ficheros se puede definir
La regioacuten y el centro de datos donde se ejecutaraacute (Nomad permite lagestioacuten de centros de datos geograacuteficamente distribuidos en regiones)
La poliacutetica de actualizacioacuten de la tarea
Grupo de tareas esto es que se ejecutaraacuten en el mismo nodo
El nuacutemero de grupos a ejecutarescalar asiacute como los liacutemite que debencumplir los nodos asignados
La poliacutetica de reinicio ante fallo o error
Tareas El controlador su configuracioacuten los paraacutemetros del servicio aso-ciado a registrar en Consul asiacute como los recursos que consume (puertosmemoria)
En nuestro caso usamos sobre todo el controlador Docker esto eso orques-tacioacuten de contenedores en los nodos clientes y tres de sus opciones
Imagen del contenedor Se han subido todas las imaacutegenes del proyecto a Doc-ker Hub donde por defecto se busca la imagen
Puertos Los puertos a usar por el contenedor que pueden ser estaacuteticos asigna-dos por el usuario o dinaacutemicos siendo Nomad el que se encarga de mapearun puerto libre del nodo cliente al expuesto por el contenedor
Servidores DNS Como usamos la interfaz DNS de Consul como descubri-miento de servicio se debe configurar el contenedor para que use cualquiernodo del cluster como servidor DNS
Configuracioacuten Consul
Al ser desarrolladas por la misma empresa los ficheros de configuracioacuten deConsul y Nomad comparten muchas opciones Consul tambieacuten acepta peticionesa traveacutes de una interfaz de red siendo los puertos usados por defecto
36
RPC 8300 8400 Maneja la peticiones del resto de nodos y usuarios
Serf 8301 8302 Protocolo gossip
HTTP API 8500
HTTPS API Desactivada por defecto
Interfaz DNS 8600
Se debe asignar a los protocolos internos del cluster esto es RPC y Serf unainterfaz alcanzable por los nodos y por el contrarioasignar a los dos uacuteltimos ala interfaz de loopback por motivos de seguridad
Cabe destacar que Consul tambieacuten cuenta con una interfaz graacutefica que per-mite ver el estado de los equipos y los servicios registrados y que se encuentra enel mismo puerto que la API HTTP en la direccioacuten httpIP_EQUIPO8500ui
Ejecucioacuten
Tanto Nomad como Consul requieren de la ejecucioacuten de un fichero en todoslos nodos integrantes del cluster Como prueba de concepto se ha decidido usardos servidores para ambos aunque cabe matizar que es un nuacutemero ineficienteya que la caiacuteda de uno de ellos supondriacutea la peacuterdida del cuoacuterum y por tantodel consenso del cluster
En primer lugar se arrancan los servidores que son los encargados de ejecu-tar el protocolo de consenso y gestionar el cluster y a continuacioacuten los clientesque no tienen praacutecticamente estado y dependen de los servidores
En el caso de Consul se debe indicar el directorio donde se guardan losficheros que describen los servicios asiacute como el archivo que especifica el resto delas opciones
1 Se inicia el primer servidor en uno de los equipos
$ consu l agent minuscon f i gminusd i r e t c consu l d s e r v i c e s minuscon f i gminus f i l e consu l_server j son
2 Los siguientes equipos deben unirse al anterior por lo que antildeadimos elargumento join con la direccioacuten del primer servidor Para el caso de otrosservidores
$ consu l agent minuscon f i gminusd i r e t c consu l d s e r v i c e s minuscon f i gminus f i l e consu l_server j son minus j o i n ltIP_servidor1gt
37
Una vez los servidores han alcanzado el consenso y elegido un liacuteder en losclientes
$ consu l agent minuscon f i gminusd i r e t c consu l d s e r v i c e s minuscon f i gminus f i l e c on su l_c l i en t j son minus j o i n ltIP_cualquierServ idorgt
El proceso para iniciar Nomad es igual y los comandos similares sin embargoya no es necesario indicar una direccioacuten IP fija en los equipos sino el nombre dedominio del servicio de Nomad registrado por Consul En el primer servidor
$ nomad agent minusc on f i g nomad_server j son
Y el resto de equipos (con su fichero de configuracioacuten correspondiente)$ nomad agent minusc on f i g nomad_server j son minus j o i n nomad s e r v i c e consu l
Por uacuteltimo para desplegar la aplicacioacuten web se han escrito tres ficherosque detallan las tareas de la interfaz web API y los balanceadores de cargaMediante la CLI
$ nomad run minusaddress=http lt ip_c lus te r gt4646 lt f i l e hclgt
O mediante la API HTTP de Nomad$ cu r l minusX POST minusd ltf i l e hclgthttp lt ip_c lus te r gt4646 jobltjob_namegt
Ansible
Como se puede comprobar con el aumento del nuacutemero de equipos pasa aser inviable manejar todos los nodos a traveacutes de terminal Ademaacutes como seha comentado con anterioridad Nomad requiere que en los nodos clientes es-teacuten instalados las herramientas que soporten las tareas por ejemplo el motorde Docker Por ello para facilitar tanto el arranque como la instalacioacuten de lasdependencias vamos a usar Ansible una herramienta de coacutedigo abierto desarro-llada en Python que permite gestionar configuraciones aprovisionar recursosdespliegue de aplicaciones de forma automaacutetica
A grandes rasgos esta herramienta funciona mediante ficheros en formatoYAML denominados play-books que describen un conjunto de pasos a ejecutaren una lista de equipos remotos Estos pasos son ejecutados por moacutedulos inde-pendientes a traveacutes de SSH es decir en cualquier ordenador con conexioacuten a los
38
hosts dado su contrasentildea o clave puacuteblica puede arrancar el script y realizariacutealos pasos de forma remota gestionando el cluster desde un solo equipo
Se han desarrollado guiones para lo siguiente
Descarga de los binarios de Nomad y Consul en todos los nodos copiade los ficheros de configuracioacuten baacutesicos y modificarlos de acuerdo a cadanodo (nombre del equipo direccioacuten IP)
Instalacioacuten de las dependencias
Arranque de Nomad y Consul
Ansible extiende su funcionalidad a traveacutes de moacutedulos independientes que per-miten por ejemplo instalar paquetes mediante herramientas de gestioacuten de pa-quetes (APT yum) aprovisionar automaacuteticamente maacutequinas virtuales de Ama-zon EC2
Algunas opciones de los ficheros de configuracioacuten de Nomad y Consul sondependientes del nodo particular por ejemplo la interfaz de red Para estetrabajo se ha realizado un moacutedulo para modificar los ficheros de configuracioacutende forma automaacutetica En el repositorio del proyecto se encuentra una carpetadonde se encuentran todos los ficheros necesarios para desplegar un clustertotalmente funcional solo requiere de una liacutenea de terminal con Ansible
$ ans ib l eminusplaybook minus i hos t s minusk ltssh_passgt minusu ltnode_usergt s i t e yml
39
62 Servicio de integracioacuten continua
Se ha implementado un sistema de integracioacuten continua que permite ejecu-tar tareas de compilacioacuten y pruebas de forma distribuida aumentando asiacute elrendimiento de los equipos En primer lugar se detallaraacute los motivos por los quepuede resultar beneficioso para las empresas una implementacioacuten de este tipo alo que seguiraacute los detalles del despliegue
621 DevOps
Metodologiacutea que defiende la comunicacioacuten y colaboracioacuten entre desarrolla-dores de software y los profesionales de operaciones a lo largo de todo el ciclo devida de una aplicacioacuten Estaacute muy relacionado con el desarrollo aacutegil de softwareesto es un enfoque para los proyectos que defiende el desarrollo iterativo e in-cremental donde los requisitos y soluciones evolucionan con el tiempo seguacuten lanecesidad del proyecto DevOps extiende esta filosofiacutea a todas los componentesde un servicio incluyendo sistemas y operaciones
Se trata de un concepto que cada organizacioacuten o empresa adapta a suspropias necesidades y procesos de negocio en este proyecto nos vamos a centraren la integracioacuten continua una praacutectica fundamental tanto del desarrollo aacutegilcomo de esta filosofiacutea
622 Integracioacuten Continua
Se define como una praacutectica de desarrollo software donde los miembros delequipo ponen en comuacuten su trabajo frecuentemente al menos una vez al diacutea21Cada integracioacuten se verifica con una compilacioacuten automaacutetica que incluye laejecucioacuten de pruebas para detectar errores de integracioacuten tan pronto como seaposible
Desde el punto de vista operativo esto supone automatizar la configuracioacutende equipos o el despliegue de maacutequinas virtuales donde compilar el proyecto yejecutar las pruebas y posteriormente eliminarlas Este flujo de trabajo se vebeneficiado en entornos distribuidos ya que el objetivo del desarrollador es com-probar el resultado de las pruebas raacutepidamente sin preocuparse del despliegueo los propios equipos
Para esta prueba de concepto vamos a usar Jenkins un servidor de integra-cioacuten continua escrito en Java que nos permite definir trabajos que contendraacutenla descripcioacuten tanto del entorno como su ejecucioacuten
Este sigue una estructura maestro-esclavo muy similar al de los gestores declusters usados en este proyecto el maestro contiene toda la loacutegica del servicio
21httpmartinfowlercomarticlescontinuousIntegrationhtml
40
trabajos autenticacioacuten y los esclavos son los encargados de la ejecucioacuten ensiacute Jenkins tiene varias viacuteas para aprovisionar los uacuteltimos
Mediante SSH
Interfaz graacutefica
Desarrollar un script propio
Ejecucioacuten de un fichero java
La ventaja de usar planificadores es que el despliegue de esclavos es dinaacutemicoes decir no tener una maacutequina especiacuteficamente configurada para ello DCOS yNomad se encargaraacuten de configurar estos despliegues en sus maacutequinas y poste-riormente eliminarlos Para ello se ha usado la uacuteltima opcioacuten definiendo tareasque descarguen el fichero java Con todo ello se consigue un entorno de inte-gracioacuten continua eficiente que ademaacutes permite la ejecucioacuten de otros servicios deforma independiente
Jenkins permite la creacioacuten de plugins que extienden sus funcionalidadesTanto Nomad22 como Apache Mesos cuentan con uno que permite su integra-cioacuten
Para esta prueba se va a usar el mismo proyecto que para el caso de usode orquestacioacuten de contenedores la aplicacioacuten web al que se le ha antildeadido untest para comprobar que se conecta correctamente a la base de datos medianteMocha un framework de Nodejs Por otro lado se antildeade el plugin de git ya queel coacutedigo se obtiene de GitHub el repositorio remoto de control de versiones delproyecto
El proceso general de ejecucioacuten seriacutea como sigue
1 Se ejecuta el maestro de Jenkins como tarea Docker partiendo de la imagenoficial
2 Al arrancar un trabajo se manda una tarea a los planificadores que laasignaraacuten a un nodo cliente Esta tarea consiste en la descarga del ficherode configuracioacuten Java y arrancarlo configurando el equipo como un clientede Jenkins temporalmente
3 Jenkins ejecuta el trabajo en el nuevo cliente en este caso iniciar la apli-cacioacuten web iniciar las pruebas y generar un informe
4 Se elimina el cliente
A continuacioacuten se detallan los matices de cada herramienta a la hora de imple-mentar este servicio
22Desarrollado por Ivo Verberk httpwwwivoverberknl
41
623 Jenkins con Nomad
El plugin permite la ejecucioacuten del fichero Java mediante dos controladorescontenedores Docker y Java En este proyecto nos hemos decantado por el pri-mero ya que nos ahorra instalar la maacutequina virtual de java en todos los nodoscliente Por ello se ha construido un contenedor base con Java para la ejecucioacutendel fichero de configuracioacuten y Nodejs para lanzar la aplicacioacuten web
El plugin se configura con la direccioacuten IP del cluster y el contenedor queejecuta el esclavo Jenkins Por su parte el trabajo en Jenkins se define conel repositorio en GitHub donde se aloja el coacutedigo del proyecto a probar y loscomandos a ejecutar en este caso npm update y npm test
624 Jenkins con DCOS
En el caso de DCOS su sistema de paquetes incluye Jenkins por lo queal instalarlo ya se tiene la configuracioacuten de Mesos totalmente funcional Sinembargo para ejecutar la aplicacioacuten en particular y las pruebas se requiere deNodejs en los equipos esclavos por ello debemos antildeadir un plugin de Jenkinsque permite instalar este entorno antes de ejecutar el trabajo Una vez hechoesto soacutelo queda definir la tarea igual que en el caso anterior
Cabe destacar que Mesosphere tambieacuten ha desarrollado un plugin que per-mite hacer despliegues en Marathon de tal manera que permitiriacutea con cadacommit del coacutedigo compilar la imagen del contenedor Docker y desplegarlaautomaacuteticamente aunque en este proyecto no se ha hecho pruebas de esta fun-cionalidad
42
7 Escalando la infraestructura
Uno de los factores clave que se busca a la hora de implementar sistemasdistribuidos es el poder escalar la infraestructura de forma maacutes sencilla estoes detectar que las maacutequinas estaacuten alcanzando el liacutemite de su capacidad yaumentar eacutesta ya sea mejorando sus caracteriacutesticas teacutecnicas o antildeadiendo maacutesnodos al cluster
El coacutedigo y todos los ficheros de configuracioacuten de esta seccioacuten tambieacuten sepueden encontrar en el repositorio del proyecto en GitHub23
71 Disentildeo
Microsoft Azure permite organizar los servicios cloud de forma loacutegica a traveacutesde grupos de recursos y asiacute poder crear o eliminar eacutestos en conjunto parauna aplicacioacuten determinada (por ejemplo una aplicacioacuten web suele requerir demaacutequinas virtuales bases de datos almacenamiento) Ademaacutes dispone dela opcioacuten de crear plantillas en formato JSON que permite al desarrolladordefinir los recursos y su interrelacioacuten para desplegar de forma automaacutetica unainfraestructura TI en la nube
Azure tambieacuten ofrece la posibilidad de monitorizar el estado de las maacutequinasvirtuales a traveacutes de extensiones lo que permite configurar el escalado automaacute-tico al alcanzar cierto liacutemite definido por el operador Eacutesta es a priori la formaen que deberiacutea implementarse hablando en teacuterminos de eficiencia sin embargoesta aproximacioacuten es totalmente dependiente de la plataforma es decir no sepuede extrapolar a otro proveedor o sobre recursos propios sin realizar un nue-vo disentildeo En este proyecto las tareas que son ejecutadas por estos equipos notienen estado ya que todo lo relativo a la persistencia lo hemos asignado fueradel cluster esto permite escalar la plataforma a traveacutes de otra aproximaciones
Las plantillas aceptan una serie de variables a indicar por el usuario entreotras los conjuntos de escala para definir los nodos aceptan una variable quedefine el nuacutemero de maacutequinas que los componen Por otro lado Azure ofreceuna API REST y kits de desarrollo software (SDK por sus siglas en ingleacutes) quepermiten su despliegue de forma programaacutetica Aprovechando estas facilidadesen este proyecto se va a aproximar la escalabilidad con el sucesivo desplieguede la infraestructura de forma automaacutetica se monitorizan los equipos y si sedetecta una maacutequina excesivamente cargada se aumenta el nuacutemero de equiposen la plantilla y se vuelve a desplegar
23httpsgithubcomAntonioAlfrzCloud-Orchestrators
43
En este proyecto se han disentildeado las plantillas para desplegar la arquitec-tura necesaria tanto de Nomad como de DCOS En el caso de la primera eldespliegue es maacutes descriptivo ya que incluye maacutequinas virtuales grupos de se-guridad redes En el caso de DCOS Azure cuenta con un servicio especiacuteficopara clusters gobernados por DCOS denominado Azure Container Service queincluye los componentes necesarios y la instalacioacuten ya realizada
72 Implementacioacuten
En primer lugar para monitorizar el estado de los equipos se va a usar laherramienta Nagios un sistema que permite controlar el estado del hardwarey los servicios de un equipo Se trata de una herramienta muy completa de laque se va a usar su capacidad para ejecutar comandos (plugins) en los nodospara detectar picos de carga generar alertas y ejecutar programas para estoseventos
Se ha desplegado una maacutequina virtual con esta herramienta en ambos siste-mas y se ha instalado una extensioacuten de Nagios (Nagios Remote Plugin Executor)en todos los nodos que permite ejecutar comprobaciones remotamente en con-creto para esta prueba de concepto medir el nivel de saturacioacuten de la unidadcentral de procesamiento (CPU por sus siglas del ingleacutes) Cuando sucede uncambio de estado de una maacutequina esto es cuando este paraacutemetro supera el liacutemi-te definido por el operador Nagios permite actuar en consecuencia ejecutandoprogramas por ello se ha desarrollado un script que ejecuta lo siguiente
Un programa desarrollado en Python con el SDK de Azure que modificalas plantillas y despliega los recursos
Un guioacuten de Ansible para instalar todos los componentes necesarios en lasnuevas maacutequinas y arrancar de nuevo el cluster y las aplicaciones
44
8 Resultados y conclusiones
En este uacuteltimo apartado se da una visioacuten global del proyecto asiacute como a lasconclusiones maacutes importantes a las que se ha llegado y posibles temas futurosde desarrollo
81 Comparacioacuten
Ambas herramientas ofrecen las funcionalidades para gestionar los recursoseficientemente ofreciendo a los desarrolladores una plataforma donde desplegarsus aplicaciones de forma distribuida independientemente de los equipos fiacutesicosy el hardware que las soporten
DCOS es una herramienta que en un comienzo fue privativa pero cuyos res-ponsables la empresa Mesosphere decidieron publicar una versioacuten de coacutedigoEacutesta nos permite gestionar un cluster de una forma sencilla y usable ademaacutes decomplementarlo con otras herramientas como el balanceador de carga integradoo la autenticacioacuten de usuarios ademaacutes estaacute basada en Apache Mesos un pro-yecto de relativa madurez y con el soporte de la Apache Software FoundationDe forma resumida DCOS ofrece muchas posibilidades y servicios a cambiode una arquitectura e instalacioacuten maacutes compleja
Por su parte HashiCorp con menor tiempo de desarrollo ha conseguidouna herramienta muy sencilla de desplegar que ademaacutes cumple con todas lasfuncionalidades baacutesicas ejecutando un simple binario en cada nodo se puededesplegar un gestor de clusters totalmente funcional Sin embargo no cuentacon todas las posibilidades de Mesos (Nomad cuenta con menos controladoresque entornos posibles de Mesos) ni con los antildeadidos de DCOS lo que implicael uso de otras herramientas para complementar el servicio (Consul HAProxy)
De entre las dificultades encontradas al usar estas herramientas y desplegaraplicaciones sobre ellas se puede destacar la depuracioacuten en ocasiones se desco-noce si un error viene de la propia herramienta de la aplicacioacuten desplegada o delequipo fiacutesico si no se cuenta con un sistema de procesamiento de registro unose puede encontrar con muacuteltiples terminales abiertas inspeccionando numerososficheros de registro buscando posibles errores Ademaacutes no dejan de ser solucio-nes que para usar eficientemente se debe conocer parte de su funcionamientoy sintaxis a la hora de describir la tareas lo que supone un esfuerzo antildeadido yaque cada una tiene sus particularidades y liacutemites
45
82 Conclusiones
En una sociedad cada vez maacutes digital las empresas deben adaptarse a unmercado cuya demanda de contenido no deja de crecer Las nuevas arquitecturascomo microservicios asiacute como la gran cantidad de datos generada implica queuna mejor gestioacuten de los recursos y la rapidez para desplegar o escalar solucionesdando valor al cliente lo maacutes raacutepido posible es uno de los objetivos de todas lasempresas de base tecnoloacutegica
Las ventajas que ofrecen los planificadores con aplicaciones distribuidas sonnumerosas sin ir maacutes lejos empresas tan punteras como Google llevan maacutesde 10 antildeos orquestando contenedores24 Por un lado permiten aumentar elrendimiento de los equipos propios y por otro implementar un servicio comoplataforma para despliegues distribuidos sobre cualquier conjunto hardware deesta forma se provee un servicio similar al de la nube puacuteblica pero con laprincipal diferencia de que se elimina la independencia con el proveedor (vendorlock-in) esto es las aplicaciones no tienen limitaciones impuestas por eacuteste talescomo lenguaje de programacioacuten o herramientas y permite despliegues hiacutebridosentre recursos propios y la nube
83 Objetivos conseguidos
Implementacioacuten de los planificadores propuestos en la nube Se ha en-tendido y detallado el funcionamiento de estas herramientas y se hanimplementado en el servicio de infraestructura de Microsoft Azure
Despliegue de aplicaciones y servicios distribuidos Servicios que se usanactualmente en la industria del desarrollo software asiacute como una aplica-cioacuten web con una arquitectura moderna han sido desplegados de formadistribuida en los equipos cumpliendo con la funcionalidad esperada ade-maacutes de consiguiendo una alta disponibilidad
Aproximacioacuten de arquitectura escalable Se ha hecho una aproximacioacutende infraestructura escalable de forma que sea parcialmente extrapolable aotros proveedores
24httpwwwnextplatformcom20160322decade-container-control-google
46
84 Liacuteneas de investigacioacuten
Siguiendo con la materia de este proyecto se presentan posibles liacuteneas deinvestigacioacuten
Analizar el despliegue con estas herramientas de aplicaciones de Big Datay comparar la eficiencia con respecto a soluciones especializadas
Analizar el rendimiento de los algoritmos de planificacioacuten antes pruebasde estreacutes y situaciones de alta contienda
Comparar el uso de estas herramientas con las praacutecticas actuales de laindustria o implementacioacuten en un sistema de produccioacuten real
47
Referencias
[1] LA Barroso y U Houmllzle laquoThe Datacenter as a Computer An Introduc-tion to the Design of Warehouse-Scale Machinesraquo En Morgan amp ClaypoolPublishers ()
[2] Systems Research Group ndash NetOS (University of Cambridge) The evolu-tion of cluster scheduler architectures 2016 url httpswwwclcamacukresearchsrgnetoscamsasblog2016-03-09-scheduler-architectureshtml
[3] A Das I Gupta y A Motivala SWIM Scalable Weakly-consistent Infection-style Process Group Membership Protocol Inf teacutec Dept of ComputerScience Cornell University url https www cs cornell edu ~asdasresearchdsn02-swimpdf
[4] D Dubhashi y A Das Mastering Mesos PACKT Publishing mayo de2016
[5] The Apache Software Foundation Apache Mesos documentation urlhttpsmesosapacheorg
[6] David Greenberg Building Applications on Mesos OrsquoReilly Media 2016[7] Armand Grillet Comparison of Container Schedulers Inf teacutec Technische
Universitaumlt Berlin[8] HashiCorp Consul documentation url httpswwwconsulio[9] HashiCorp Nomad documentation url httpsdcosio[10] Dan C Marinescu Cloud computing theory and practice Morgan Kauf-
mann 2013[11] Mesosphere DCOS documentation url httpswwwnomadproject
io[12] Microsoft Azure documentation url httpsazuremicrosoftcom
es-esdocumentation[13] D Ongaro y J Ousterhout In Search of an Understandable Consensus
Algorithm Inf teacutec Stanford University url httpsraftgithubioraftpdf
[14] Fei Teng laquoRessource allocation and schelduling models for cloud compu-tingraquo Tesis de mtriacutea Ecole Centrale Paris 2011
[15] A Williams y col Automation and Orchestration with Docker and Contai-ners A Comprehensive Overview of the Docker and Container Ecosystem3 The New Stack 2016
48
- Resumen
- Summary
- Iacutendice de figuras
- Introduccioacuten y objetivos
-
- Contexto
- Objetivos
- Estructura del documento
-
- Cloud Computing
- Nuevas cargas de trabajo
- Gestioacuten de recursos Planificadores
-
- Sistemas distribuidos
-
- Clasificacioacuten
-
- Herramientas
-
- DCOS
-
- Apache Mesos
- Ejemplos de uso
-
- Nomad
-
- Protocolo de consenso Raft
- Protocolo gossip SWIM
- Planificacioacuten
-
- Casos de uso y despliegue
-
- Aplicacioacuten Web
-
- DCOS
- Nomad
-
- Servicio de integracioacuten continua
-
- DevOps
- Integracioacuten Continua
- Jenkins con Nomad
- Jenkins con DCOS
-
- Escalando la infraestructura
-
- Disentildeo
- Implementacioacuten
-
- Resultados y conclusiones
-
- Comparacioacuten
- Conclusiones
- Objetivos conseguidos
- Liacuteneas de investigacioacuten
-
522 Protocolo gossip SWIM 23
523 Planificacioacuten 24
6 Casos de uso y despliegue 27
61 Aplicacioacuten Web 27
611 DCOS 28
612 Nomad 33
62 Servicio de integracioacuten continua 40
621 DevOps 40
622 Integracioacuten Continua 40
623 Jenkins con Nomad 42
624 Jenkins con DCOS 42
7 Escalando la infraestructura 43
71 Disentildeo 43
72 Implementacioacuten 44
8 Resultados y conclusiones 45
81 Comparacioacuten 45
82 Conclusiones 46
83 Objetivos conseguidos 46
84 Liacuteneas de investigacioacuten 47
viii
Iacutendice de figuras
1 Comparacioacuten Centro de datos - Computacioacuten en la nube 4
2 Arquitectura Docker 6
3 Planificador monoliacutetico 11
4 Planificador de dos niveles 11
5 Planificador de estado compartido 12
6 Planificador distribuido 12
7 Arquitectura DCOS 14
8 Servicios DCOS 15
9 Arquitectura de Apache Mesos 17
10 Arquitectura multi-regioacuten en Nomad 20
11 Equipos sin consenso ejecutando el protocolo RAFT 21
12 Un equipo pasa a estado candidato (RAFT) 22
13 Cambio en un registro (RAFT) 22
14 Aprobacioacuten del resto de equipos (RAFT) 23
15 Diagrama de tiempo del protocolo SWIM 24
16 Procedimiento de asignacioacuten en Nomad 25
17 Arquitectura aplicacioacuten web 28
18 Infraestructura en Azure 29
19 Arquitectura de la aplicacioacuten web en DCOS 32
20 Despliegue en Azure de Nomad+Consul 35
ix
1 Introduccioacuten y objetivos
11 Contexto
Las tecnologiacuteas de la informacioacuten y la comunicacioacuten estaacuten suponiendo uncambio draacutestico en la sociedad en 2007 comenzaron a aparecer los teleacutefonosinteligentes tal y como los conocemos y nueves antildeos despueacutes se empieza a con-cebir la idea de dar conectividad a todo dispositivo electroacutenico movimiento queha tomado el nombre de Internet de las cosas Para hacerse una idea de la rapi-dez y magnitud de esta evolucioacuten la consultora Excelacom1 ha estimado que enun minuto se realizan 24 millones de buacutesquedas en Google o se ven 278 millonesde viacutedeos en Youtube En una eacutepoca en la que los recursos tecnoloacutegicos crecenexponencialmente y los usuarios demandan mayor contenido y movilidad nocabe duda que las empresas deben adaptarse lo maacutes raacutepidamente posible a esteproceso de digitalizacioacuten movidas por las nuevas necesidades de las personas
Dado el gran volumen de informacioacuten a lo largo de estos antildeos la compu-tacioacuten y el almacenamiento estaacuten pasando de clientes locales a concentrarse engrandes centros de datos una tendencia que Google ha denominado ldquoWarehouse-scale computingrdquo en 2009[1] Este movimiento hacia la computacioacuten desde ser-vidor no solo viene de la necesidad de mejorar la experiencia de los usuariossino tambieacuten de facilitar la gestioacuten y configuracioacuten de los recursos asiacute como laubicuidad de acceso que permite
En 2006 Amazon lanza Amazon Web Services siendo uno de los pionerosen el mercado de los recursos virtuales ofreciendo capacidad de computacioacutencon un coste proporcional exclusivamente a los recursos utilizados Todo ellocambioacute la perspectiva de los modelos tradicionales de TI a la conocida comocomputacioacuten en la nube recursos informaacuteticos que antes suponiacutean barrerasde entrada en ciertos mercados han pasado a ser condicioacuten necesaria para laconstante evolucioacuten de la tecnologiacutea y la sociedad De hecho Cisco estima quepara el antildeo 2019 maacutes del 86 de las cargas de trabajo seraacuten procesadas porcentros de datos en la nube2
1httpwwwexcelacomcomresourcesblog2016-update-what-happens-in-one-internet-minute2httpwwwciscocomcenussolutionscollateralservice-provider
global-cloud-index-gciCloud_Index_White_Paperpdf
1
12 Objetivos
El propoacutesito de este proyecto es estudiar la viabilidad del uso de planifica-dores de recursos para aumentar la eficiencia de eacutestos y facilitar al desarrolladorel despliegue de aplicaciones de forma distribuida y asiacute ofrecer un servicio ca-racterizado por una alta disponibilidad y escalabilidad
A lo largo de este trabajo se han usado algunas de las herramientas quese estaacuten comenzando a desarrollar para hacer frente a este nuevo enfoque degestioacuten de infraestructuras de las tecnologiacuteas de la informacioacuten (en adelanteinfraestructuras TI) realizando pruebas de concepto sobre cada una de ellas
13 Estructura del documento
A continuacioacuten se detalla las secciones que componen este trabajo La es-tructura queda como sigue
Cloud computing Se entra en detalle en este nuevo modelo de negocio queha originado nuevos enfoques y disentildeos de las infraestructuras TI dentrode las organizaciones
Nuevas cargas de trabajo Se explican algunas tecnologiacuteas representativasque estaacuten suponiendo un desafiacuteo para los profesionales de TI a la horade planificar los recursos y que se ven beneficiadas por entornos de tipocloud
Gestioacuten de recursos Planificadores Estado del arte de las tecnologiacuteas degestioacuten de clusters y planificacioacuten de recursos
Herramientas Descripcioacuten detallada del funcionamiento y arquitectura de lasherramientas usadas a lo largo del proyecto
Casos de uso y despliegue Se describe el proceso de implementacioacuten de unaaplicacioacuten web y un servicio de integracioacuten continua con el software pro-puesto
Escalando la infraestructura Se propone un procedimiento con cierta inde-pendencia del proveedor cloud
Resultados y conclusiones Resume las ideas y hechos a los que se ha llegadoademaacutes de introducir liacuteneas de investigacioacuten futuras
2
2 Cloud Computing
El NIST (National Insitute of Standards and Technology) define este con-cepto como un modelo que permite un acceso ubicuo y bajo demanda de formaremota a un conjunto compartido de recursos de computacioacuten que pueden seraprovisionados y liberados con unos miacutenimos esfuerzos de gestioacuten por parte delproveedor del servicio3
Clasificacioacuten
La computacioacuten en la nube abarca una amplia variedad de servicios y enfo-ques por lo que en primer lugar se va a dar una clasificacioacuten para posterior-mente entrar maacutes en detalle Existen distintos modelos de nube atendiendo a lagobernabilidad de la infraestructura seguacuten el NIST
Nubes puacuteblicas Los servicios y recursos son ofertados de forma puacuteblica yson provistos por una organizacioacuten que los comercializa bajo demanda
Nube privada Los recursos son gestionados por una uacutenica organizacioacutenpara su propio uso
Nube comunitaria En este caso la infraestructura es administrada por unconjunto de organizaciones con objetivos comunes
Nube hiacutebrida Una combinacioacuten de las anteriores
A su vez los distintos servicios que ofrece se pueden clasificar atendiendo algrado de control del usuario
Servicios de software (Software as a Service SaaS) El proveedor se encargade toda la gestioacuten de la infraestructura y oferta aplicaciones a las cuales elcliente puede acceder de forma ubicua a traveacutes de diversos clientes comoun navegador web Por ejemplo Office 365 o Google docs
Servicios de plataforma (Platform as a Service PaaS) Modelo de distribu-cioacuten que ofrece la capacidad de desplegar aplicaciones desarrolladas por elcliente usando las herramientas y lenguajes de programacioacuten soportadaspor el proveedor pero sin la posibilidad de gestionar los recursos consu-midos En este caso el cliente solo tiene control sobre la propia aplicacioacuteny algunas configuraciones del entorno Es el caso de Heroku o Google AppEngine
3httpnvlpubsnistgovnistpubsLegacySPnistspecialpublication800-145pdf
3
Servicios de infraestructura (Infrastructure as a Service IaaS) Se ofertanrecursos de computacioacuten puros como procesamiento o almacenamientomediante una plataforma de virtualizacioacuten El cliente puede controlar elsistema operativo componentes de red y aplicaciones
Figura 1 Comparacioacuten Centro de datos - Computacioacuten en la nubeFuente httpsad-hocnet
De entre las numerosas ventajas que ofrece la computacioacuten en la nube se puededestacar su flexibilidad ya que permite aprovisionar recursos y adaptarlos deacuerdo a la demanda reduce el capital inmovilizado y su amortizacioacuten laubicuidad que permite su consumo desde cualquier parte con conexioacuten a la redy la seguridad y fiabilidad que ofrece el proveedor que normalmente cuenta conrecursos geograacuteficamente distribuidos frente a la gestioacuten y mantenimiento derecursos propios
4
3 Nuevas cargas de trabajo
Las organizaciones que cuentan con sus propios infraestructuras TI han co-menzado a adoptar un enfoque de nube privada para gestionar las tareas ofunciones informaacuteticas sobre las que se sustentan el negocio ya que una es-tructura virtualizada puede ofrecer ventajas con respecto a las adaptaciones decentros de datos tradicionales en los aacutembitos de rendimiento escalabilidad eincluso seguridad4
A su vez se han desarrollado nuevas tecnologiacuteas que suponen cargas detrabajo dinaacutemicas y con gran intensidad de consumo de datos para las empresasque se ven beneficiadas al desplegarlas en recursos virtualizados
Big data
Con la creciente aceptacioacuten de las tecnologiacuteas TIC por parte de la sociedadla cantidad de datos generados en la red es ingente Las profesionales de TI tienecomo objetivo extraer valor de eacutestos para por ejemplo prever las tendencias delmercado Sin embargo este incremento exponencial hace que su procesamientoy almacenamiento requiera de un sistema con gran escalabilidad dado el hechode que una sola maacutequina no puede proveer de la capacidad necesaria
Integracioacuten continua
Modelo informaacutetico que consiste en hacer integraciones automaacuteticas de unproyecto con cualquier cambio en el coacutedigo con el objetivo de detectar fallosde forma temprana Esto implica la compilacioacuten del coacutedigo y su ejecucioacuten enun entorno de pruebas automaacuteticamente un proceso que mediante tecnologiacuteasde virtualizacioacuten permiten simular entornos con eficiencia y rapidez Su imple-mentacioacuten en sistemas distribuidos permite tanto una mejor planificacioacuten comoun mejor rendimiento de los recursos
Arquitectura de microservicios
Enfoque para desarrollar aplicaciones software como un conjunto de serviciosautoacutenomos que se comunican entre siacute a diferencia de aproximaciones monoliacuteti-cas donde la loacutegica del servicio estaacute desarrollada como una unidad Un sistemadistribuido permite el despliegue de los componentes en distintas maacutequinas loque mejora tanto su escalabilidad como la tolerancia a fallos
4httpswwwakamaicomesesresourcespublic-private-cloudjsp
5
Docker
Proyecto de coacutedigo abierto que facilita y automatiza el despliegue de aplica-ciones al encapsular el entorno de trabajo en contenedores Linux una tecnologiacuteaque permite a un sistema fiacutesico ejecutar muacuteltiples instancias de sistemas opera-tivos aislados mediante entornos virtuales con sus propios espacios de procesosy redes pero compartiendo el nuacutecleo (kernel) con el equipo anfitrioacuten
En la figura 2 se compara la pila de una virtualizacioacuten tradicional con res-pecto a los contenedores no se simula el sistema operativo por lo que el procesoes mucho maacutes ligero
Docker se caracteriza por
Autosuficiencia Los contenedores cuentan con las libreriacuteas y configuracio-nes necesarias para ejecutarse de manera autoacutenoma al compartir el nuacutecleo
Portabilidad El hecho de que sean autosuficientes implica que es inde-pendiente del host es decir se puede desplegar en cualquier equipo quesoporte esta tecnologiacutea
Tamantildeo El peso de un contenedor es sustancialmente inferior a otrastecnologiacuteas de virtualizacioacuten
Figura 2 Arquitectura DockerFuente httpsdockercom
6
Los componentes fundamentales de esta herramienta son
Imaacutegenes Describen el entorno de base sobre el que ejecutar el contene-dor por ejemplo la imagen del sistema operativo Ubuntu Sobre eacutesta seconstruyen las aplicaciones particulares del usuario dando lugar a otraimagen
Contenedores Se crean a partir de las imaacutegenes y comprenden todo aquellonecesario para arrancar la aplicacioacuten decir su entorno de ejecucioacuten
bull Voluacutemenes Encargados de gestionar la persistencia de datos e inde-pendientes del ciclo de vida del contenedor
Registros Pueden ser puacuteblicos o privados y almacenan las imaacutegenes elregistro puacuteblico oficial de Docker es Docker Hub
Dadas estas caracteriacutesticas los profesionales TI estaacuten comenzando a adoptarDocker ya que facilita tanto los despliegues como el trabajo compartido en dis-tintos entornos Sin embargo esto requiere de un software que permita desplegarlos distintos contenedores de forma que puedan trabajar en conjunto procesoque se ha denominado orquestacioacuten de contenedores
7
4 Gestioacuten de recursos Planificadores
Para sacar el maacuteximo provecho a las tecnologiacuteas anteriormente descritaslo ideal es desplegarlas en sistemas distribuidos sin embargo esto aumenta lacomplejidad del propio despliegue asiacute como la necesidad de software especiali-zado para ello Se necesitan algoritmos de planificacioacuten que permitan obtener elmaacuteximo rendimiento de los recursos por un lado y dar ciertas garantiacuteas de quetodas las tareas y procesos se van a ejecuta por otro
41 Sistemas distribuidos
En primer lugar se definen los sistemas distribuidos o clusters como unconjunto de ordenadores conectados entre siacute cuyo objetivo es trabajar como unauacutenica instancia de gran capacidad5
Su clasificacioacuten variacutea de acuerdo a cada autor pero en general se puedendividir seguacuten su objetivo en alto rendimiento aquellos cuyo objetivos es proveerde gran capacidad de coacutemputo gracias al conjunto de los nodos y alta disponi-bilidad con los cuales se busca la fiabilidad del sistema mediante redundanciayo balanceo de carga
El intereacutes de este proyecto recae en los uacuteltimos ya que el objetivo es porun lado ofrecer al desarrollador un entorno donde desplegar sus aplicaciones deforma distribuida y por otro maximizar el rendimiento de los recursos
De forma general las caracteriacutesticas que se buscan son las siguientes
Elasticidad Adaptacioacuten a cargas dinaacutemicas de trabajo aumentando (o dis-minuyendo) recursos de manera automaacutetica de tal forma que la utilizacioacutensea lo maacutes cercana a la demanda
Disponibilidad Capacidad de un sistema para mantener el servicio fun-cional
Tolerancia a fallos Recuperacioacuten del servicio ante el fallo de un compo-nente
Balanceo de carga Compartir las tareas entre las diferentes maacutequinasredundadas evitando asiacute puntos de uacutenico fallo
5httpsenwikipediaorgwikiComputer_cluster
8
Los programas que se implementan en entornos distribuidos se caracterizanpor ejecutarse de forma concurrente en equipos independientes estar conectadospor una red que introduce fallos aleatorios y no compartir memoria ni reloj Estoimplica entre otras cosas que
Los nodos soacutelo tienen un acceso raacutepido a su memoria local por lo quecualquier informacioacuten relativa al estado global puede ser potencialmenteerroacutenea
Las maacutequinas pueden sufrir caiacutedas de forma aleatoria
El intercambio de informacioacuten puede fallar ya sea por error en transmisioacuteno por caiacuteda de los nodos
Estas dificultades se ponen de manifiesto en el teorema de CAP en cienciasde la computacioacuten el teorema de CAP que lanzado inicialmente como conjetu-ra en el antildeo 2000 por Eric Brewer (motivo por el cual al teorema se le conoceformalmente como teorema de Brewer) y posteriormente demostrado en el antildeo20026 establece que es imposible para un sistema de coacutemputo distribuido ga-rantizar simultaacuteneamente dos de las tres propiedades siguientes
Consistencia (Consistency) es decir que todos los nodos vean la mismainformacioacuten al mismo tiempo Se busca que un cambio en el sistema soacutelose ejecute satisfactoriamente si y soacutelo si se efectuacutea a todos las maacutequinasde tal forma que los datos entre ellos nunca difieren y la respuesta a unapeticioacuten sea la misma independientemente del nodo que la atienda
Disponibilidad (Availability) esto es la garantiacutea de que toda peticioacuten debeobtener una respuesta (servicio funcional) aunque exista inconsistenciaentre nodos
Tolerancia al particionado (Partition Tolerance) es decir que el sistemasiga funcionado a pesar de un fallo en la comunicacioacuten entre los equipos
Por todo lo expresado anteriormente conseguir un sistema distribuido capazde ofrecer procesamiento de forma transparente implica una arquitectura TIcompleja Se requieren de subsistemas y herramientas que permitan la cohesioacutenentre todos los nodos
Gestor de los recursos de las diferentes maacutequinas
Monitorizacioacuten tanto de los servicios activos como de la funcionalidad delsistema ademaacutes de poliacuteticas para recuperacioacuten de fallo
Protocolos de consenso que permitan a los nodos ser consistentes con elestado global del cluster
6urlhttpsgroupscsailmitedutdspapersGilbertBrewer2pdf
9
Herramientas de descubrimiento de servicios que permita la comunicacioacutenentre tareas distribuidas
Planificadores Encargados de distribuir las tareas y procesos en las dife-rentes maacutequinas asignaacutendole parte de su capacidad
Los planificadores del ingleacutes cluster schedulers son un componente funda-mental por lo que vamos a entrar un poco maacutes en detalle en ellos
Planificadores (Cluster Schedulers)
Es el software encargado de monitorizar los recursos usados por cada maacute-quina perteneciente a un cluster y distribuir la carga de trabajo entre ellas deacuerdo a un poliacutetica o reglas
Este tipo de herramientas comparten cierta terminologiacutea que es relevantedefinir
Tarea Unidad de trabajo computacional comprendida por una secuenciade instrucciones datos de entrada y recursos asociados Por ejemplo laejecucioacuten de un comando o el arranque de una base de datos
Nodo Cualquier maacutequina integrante de un cluster En una arquitecturamaestro-esclavo se definen dos roles
bull Cliente Agente Esclavo Aquellos ordenadores que se encargan deejecutar las tareas
bull Maestro Servidor Su objetivo es mantener el estado del cluster ygestionar sus recursos
411 Clasificacioacuten
A lo largo de los uacuteltimos antildeos se han desarrollado diferentes tipos de plani-ficadores[2]
Monoliacutetico
Un solo planificador que se encarga de distribuir todas las tareas entran-tes La mayoriacutea de los planificadores en computacioacuten de alto rendimiento asiacutecomo Borg desarrollado por Google son de este tipo En la figura 3 se pue-de observar de forma graacutefica el procedimiento siendo las cajas grises maacutequinaspertenecientes al cluster y los ciacuterculos las tareas a asignar
10
Figura 3 Planificador monoliacuteticoFuente httpswwwclcamacuk
Planificacioacuten de dos niveles
La mayoriacutea de los clusters ejecutan aplicaciones con distintas necesidadesdesde procesos casi instantaacuteneos hasta servicios persistenteslo que implica dis-tintas necesidades de recursos
Por ello la planificacioacuten a dos niveles distingue dos funciones la gestioacutende recursos (gestor) y la disposicioacuten de las tareas (planificador) Cada serviciotiene su propio planificador de tal manera que el gestor les ldquoofertardquo recursosde acuerdo a una poliacutetica y los planificadores se encargan de escoger la maacutesadecuada Esto permite que el proceso de distribucioacuten sea maacutes acorde con lasnecesidades de los diferentes servicios Apache Mesos que detallaremos maacutesadelante sigue este esquema
Como desventaja cabriacutea sentildealar que esta programacioacuten implica que los pla-nificadores pierden la vista general de la infraestructura y las tareas soacutelo puedenejecutarse con los recursos que les son ofrecidos lo que dificulta la implementa-cioacuten de prioridades de ejecucioacuten de tareas entre otras
Figura 4 Planificador de dos niveles
11
Planificacioacuten de estado compartido
Muacuteltiples reacuteplicas del estado del cluster se actualizan independientementepara cada planificador como se observa en la figura 5 cuando sucede un cambiode forma local el planificador se encarga de informar al resto
Ejemplo de este tipo son Omega la evolucioacuten de Borg por parte de GoogleMicrosoft Apollo y Nomad que usaremos para los casos de uso
De entre las desventajas se puede destacar el hecho de que en general losnodos trabajan con informacioacuten desactualizada lo que conlleva una degradacioacutendel rendimiento en situaciones de alta contienda
Figura 5 Planificador de estado compartido
Planificacioacuten distribuida
En este caso no existe coordinacioacuten entre los distintos planificadores Cadauno de ellos funciona con su propia vista del cluster Las tareas pueden serorganizadas por cualquiera de ellos y desplegadas en cualquier parte del clusteren base a la aleatoriedad y multiplexacioacuten estadiacutestica de los flujos de trabajosin ninguacuten control central
Figura 6 Planificador distribuido
12
5 Herramientas
En la industria comienzan a aparecer soluciones software de coacutedigo abiertoque aglutinan los servicios necesarios para gestionar la infraestructura TI de ma-nera maacutes eficaz El objetivo es doble se busca facilitar la gestioacuten de los recursosde computacioacuten para organizaciones con instalaciones propias mediante su usocon un enfoque cloud esto es desplegar aplicaciones a traveacutes de un conjuntode ordenadores de forma transparente y sin tener en cuenta la infraestructurasubyacente o aprovechar el maacuteximo rendimiento de la infraestructura de losproveedores cloud puacuteblicos de forma que se tiene el maacuteximo control sobre eacutestapero no se depende de las soluciones propietarias permitiendo asiacute despliegueshiacutebridos
Entre estas herramientas se pueden destacar
OpenStack Proyecto desarrollado por la fundacioacuten del mismo nombre paraproporcionar servicios de infraestructuras (IaaS) basado en componentesque se comunican a traveacutes de APIs El componente Magnum incluye mo-tores de orquestacioacuten de contenedores
Kubernetes Sistema de orquestacioacuten de contenedores Docker creado por Goo-gle
CoreOs Sistema operativo basado en Linux disentildeado para despliegues distri-buidos sobre contenedores incluyendo mecanismos de descubrimiento deservicio y comparticioacuten de configuracioacuten
Docker Swarm Herramienta nativa de orquestacioacuten de contenedores Docker
YARN Entorno de gestioacuten de recursos y aplicaciones distribuidas de Hadoopuna libreriacutea software de procesamiento de grandes conjuntos de datos
Como podemos observar existe un gran rango de opciones para gestionar lainfraestructura desde un bajo nivel como puede ser OpenStack hasta Kuberne-tes o Docker Swarm que ofrecen exclusivamente orquestacioacuten de contenedores
En este trabajo se ha optado por Mesosphere DCOS y HashiCorp Nomadque se encuentran en el teacutermino medio su objetivo es proporcionar serviciosde plataforma que permitan la coexistencia dediferentes cargas de trabajo en elcluster
13
51 DCOS
DCOS es un proyecto de coacutedigo abierto7 creado y desarrollado por la empre-sa Mesosphere Se describe como un sistema operativo distribuido que abstraelos recursos de un cluster (capacidad de procesamiento memoria) permite lagestioacuten de muacuteltiples ordenadores de forma transparente y simplifica la instala-cioacuten de aplicaciones distribuidas
Su arquitectura se puede comparar a la de Linux en teacuterminos de nuacutecleo(kernel) y espacio de usuario El primero consta de recursos protegidos a losque no puede acceder el usuario e involucra operaciones de bajo nivel comoasignacioacuten de recursos o aislamiento de procesos En el espacio de usuario seejecutan las aplicaciones y servicios de maacutes alto nivel
Siguiendo con este siacutemil el nuacutecleo de DCOS estaacute basado en Apache Mesosque se explicaraacute en un apartado posterior y el espacio de usuario que estaacute com-prendido por los componentes del sistema esto es las diferentes herramientasque en conjunto conforman DCOS y los servicios encargados de planificar yejecutar las aplicaciones y tareas del usuario
Figura 7 Arquitectura DCOSFuente httpsdcosio
De entre los componentes que conforman DCOS destacan
Admin Router Balanceador de carga central basado en NGINX que dis-pone un proxy entre todos los servicios en el puerto 80 permitiendo sugestioacuten mediante la interfaz graacutefica Ademaacutes se encarga de la autenticacioacutenpara acceder al panel de administracioacuten
Cosmos Gestor de paquetes de las aplicaciones
Diagnostics Se ejecuta en todos los nodos y se encarga de monitorizar elestado de los daemons que sustentan DCOS
7Desde abril de 2016 httpsmesospherecomblog20160419open-source-dcos
14
Exhibitor Gestiona y automatiza el despliegue de ZooKeper la herra-mienta que provee de configuracioacuten centralizada y registro de nombres
Marathon Equivale al proceso init de los sistemas tipo Unix esto es elprimer proceso en ejecucioacuten tras la carga del kernel y que genera los demaacutesprocesos Se encarga de arrancar y monitorizar las aplicaciones y servicios
Mesos-DNS Servicio de DNS interno que define el dominio mesos pa-ra nodos y tareas en el cluster es decir permite resolver nombres conindependencia de la direccioacuten fiacutesica
Minuteman Balanceador de carga integrado a nivel TCPUDP disponiblepara las propias aplicaciones
Por otra parte se definen como servicios a las diferentes aplicaciones dis-tribuidas que DCOS permite instalar en el cluster y que pueden haber sidodesarrollados por la misma empresa Mesosphere o por terceros por ejemploApache Spark Jenkins o Apache Hadoop En la figura 8 se muestra un diagramade los servicios disponibles incluyendo algunos de las aplicaciones distribuidasque soporta DCOS
Figura 8 Servicios DCOSFuente httpsdcosio
511 Apache Mesos
El nuacutecleo de DCOS estaacute basado en Apache Mesos un proyecto de coacutedigoabierto creado por la Universidad de California Berkeley y desarrollado actual-mente por la fundacioacuten Apache Se trata de un administrador de clusters queabstrae los recursos y los dispone para diferentes aplicaciones y entornos de tra-bajo distribuidos (frameworks) mediante una interfaz comuacuten En el momento deredaccioacuten de este proyecto Apache Mesos soportaba una variedad de entornosque abarcaba desde Big Data (Apache Spark Hadoop) hasta bases de datos(Cassandra Hypertable)
15
Arquitectura
Mesos se basa en la asignacioacuten de dos roles diferentes a los nodos
Maestros (Masters) Se encargan de la gestioacuten y reparticioacuten de los recursospara los diferentes entornos de trabajo mediante ldquoofertas de recursosrdquo deacuerdo a los disponibles y a la poliacutetica de asignacioacuten (planificacioacuten en dosniveles)
Esclavos (Slaves) Ordenadores donde se ejecutaraacuten las aplicaciones y cu-yos recursos son ofertados por los maestros
En el caso de fallo del maestro las tareas pueden seguir ejecutaacutendose perono se podraacute asignar nuevos recursos ni tareas por ello pueden existir varios enel cluster para configuraciones de alta disponibilidad pero soacutelo uno orquesta alos esclavos
Para la eleccioacuten del master liacuteder Mesos usa Apache ZooKeeper un proyectode software desarrollado por la misma fundacioacuten cuyo objetivo es proveer deun servicio de configuracioacuten centralizado y registro de nombres8
Por otra parte los entornos de trabajo son los programas que deciden final-mente queacute recursos se van a usar y se encargan de que los esclavos ejecuten lastareas Eacutestos se ejecutan sobre Mesos y constan de dos componentes
Planificador (Scheduler) Optimiza y decide los recursos a utilizar de losofertados informando a los Masters
Procesador (Executor) Ejecuta las aplicaciones o servicios en los esclavos
El objetivo final es conseguir una interfaz liviana tolerante a fallos paracualquier tipo de entorno de trabajo de tal manera que en los esclavos del clusterpuedan ejecutarse simultaacuteneamente tareas con necesidades y duracioacuten diferentesPara ello se basa en dos conceptos asignacioacuten y aislamiento de recursos
Asignacioacuten de recursos
En el cluster pueden coexistir entornos de trabajo con tareas de larga dura-cioacuten y con gran consumo de recursos con tareas cortas que los ocupan y liberancon rapidez El maestro integra un moacutedulo de asignacioacuten de recursos (allocationmodule) que se encarga del algoritmo de distribucioacuten
En el momento de escribir este proyecto estaban desarrollados dos moacutedulosuno mediante el cual el usuario puede asignar prioridades y otro que implementa
8httpszookeeperapacheorg
16
el algoritmo Dominant Resource Fairness9 a grandes rasgos se determina entodos los esclavos la tarea en ejecucioacuten que necesita maacutes recursos y se calcula laproporcioacuten del recurso de mayor peso con respecto al total por ejemplo si unatarea ocupa 2 GB de memoria con respecto a 10 GB totales que tiene el clusterse le asigna un dominant share del 20 la tarea se asignaraacute al nodo con menordominant share
Aislamiento de recursos
Para conseguir que tareas de diferentes entornos de trabajo y con distin-ta naturaleza se ejecuten simultaacuteneamente en un mismo nodo Mesos usa loscontenedores Linux (descritos en la seccioacuten 3)
Funcionamiento
La figura 9 muestra el esquema de la arquitectura de Apache Mesos conalta disponibilidad (tres maestros) y con dos entornos de trabajo ejecutaacutendo-se Hadoop que permite el almacenamiento y procesamiento de gran cantidadde datos para proyectos de big data y un sistema que implementa la interfazsistema de paso de mensajes MPI
Como se puede observar el sistema ZooKeeper elige a un solo maestro comoliacuteder y eacuteste orquesta el cluster comunicando los esclavos con los planificadoresde los diferentes entornos de trabajo Tambieacuten se puede observar como las tareasde los distintos entornos estaacuten distribuidas entre los tres esclavos disponibles
Figura 9 Arquitectura de Apache MesosFuente httpsmesosapacheorg
El proceso de asignacioacuten se realiza como sigue en primer lugar un usuariosolicita la ejecucioacuten de una tarea mediante la interfaz de cada entorno de traba-jo (interfaz graacutefica API HTTP ) De forma paralela un esclavo informa almaestro de los recursos que tiene libres En consecuencia eacuteste se lo notifica almoacutedulo de asignacioacuten que en funcioacuten de su configuracioacuten decide cuaacutento ofertar
9httpspeopleeecsberkeleyedu~aligpapersdrfpdf
17
y a queacute entorno de trabajo y enviacutea la oferta a los planificadores Eacutestos respondenal maestro con queacute recursos ha decidido usar para cada tarea Finalmente lastareas son enviadas al esclavo seleccionado el cual asigna los recursos indicadosal procesador (executor) quien finalmente las ejecuta
Cabriacutea pensar que esta metodologiacutea puede conducir a situaciones en lasque un entorno podriacutea quedarse con tareas sin ejecutarse a la espera de unaoferta satisfactoria para ello Mesos implementa un sistema de filtros medianteel cual los entornos especifican los requisitos miacutenimos que debe cumplir unaoferta por ejemplo se puede especificar en queacute nodos debe desplegarse la tareaEste sistema estaacute disentildeado asiacute con el objetivo de mantener lo maacutes transparenteposible esta herramientas de forma que acepte entornos de trabajo de distintasnaturalezas
512 Ejemplos de uso
Grandes empresas estaacuten usando Apache Mesos con eficacia de acuerdo a susnecesidades e infraestructuras Caben destacar
Ebay En el modelo de implementacioacuten continua en esta empresa10 cadadesarrollador cuenta con su propia instancia que se ejecuta en una maacutequinavirtual dedicada lo que ha conllevado un uso de los recursos poco eficiente Enuna prueba de concepto consiguieron realizar una herramienta de integracioacutencontinua distribuida basada en un cluster con Apache mesos y con el entornoMarathon y Jenkins
Apple Anuncioacute que el motor de su famosa herramienta de asistencia per-sonal para iPhones Siri estaacute desplegada sobre Apache Mesos11 Para ello handesarrollado su propio entorno para facilitar a los ingenieros a desplegar los ser-vicios que la herramienta necesita para resolver las peticiones de los usuarios
Twitter Desarrolloacute su propio entorno denominado Aurora y actualmentegestionan sus recursos y miden el coste de las tareas que los empleados usancon el objetivo de que sean conscientes del gasto que puede suponer un usoinadecuado de la infraestructura12
10httpwwwebaytechblogcom20140404delivering-ebays-ci-solution-with-apache-mesos-part-i11httpwwwbusinessinsidercomapple-siri-uses-apache-mesos-2015-812httpswwwlinuxcomNEWS4-UNIQUE-WAYS-UBER-TWITTER-PAYPAL-AND-HUBSPOT-USE-APACHE-MESOS
18
52 Nomad
Herramienta de coacutedigo abierto de gestioacuten de clusters creada y desarrolladapor Hashicorp13 que permite el despliegue de aplicaciones y procesos de formadistribuida
Las principales diferencias con Apache Mesos a grandes rasgos son
Arquitectura maacutes ligera Nomad soacutelo requiere de un fichero para funcionarejecutaacutendolo con las correspondientes configuraciones en todos los nodosrealiza las funciones de gestioacuten del cluster eleccioacuten de liacuteder planificacioacutende recursos y ejecucioacuten de las tareas
Centro de datos y regiones muacuteltiples Su arquitectura estaacute orientada afacilitar la gestioacuten de diferentes centros de datos geograacuteficamente distri-buidos
Entorno de ejecucioacuten Las tareas se definen y son interpretadas mediantecontroladores integrados en Nomad que se valen de los recursos y herra-mientas de los nodos clientes para ejecutarlas Esta integracioacuten dificultael desarrollo de controladores por parte de terceros a diferencia de Mesosque delega dicha responsabilidad en los entornos de trabajo externos alproyecto
Usa un planificador de estado compartido con respecto a la planificacioacutenen dos niveles de Mesos
Antes de entrar en maacutes detalle en la arquitectura es importante definir lossiguientes teacuterminos
Controlador (Driver) Software que se encarga de interpretar las definicionesde las tareas y ejecutarlas semejante a los procesadores de los entornosde trabajo de Mesos A la hora de redactar este proyecto Nomad contabacon controladores para contenedores Docker virtualizacioacuten de maacutequinasmediante el emulador QEMU aplicaciones java y archivos binarios
Grupo de trabajo (Task Group) Conjunto de tareas que se ejecutan en elmismo nodo cliente
Trabajo (Job) Conjunto loacutegico de tareas y grupos de trabajo que se despliegana la vez
Asignacioacuten (Allocation) Relacioacuten entre un grupo de trabajo y el cliente don-de se ejecuta
Evaluacioacuten (Evaluation) Proceso mediante el cual Nomad planifica y ges-tiona el registro o actualizaciones de los trabajos
13httpswwwhashicorpcom
19
Nomad sigue una arquitectura maestro-esclavo similar a la de Apache Mesosmuacuteltiples servidores acuerdan entre siacute un liacuteder que gestiona la planificacioacuten detareas en los clientes que soacutelo conocen sus asignaciones y las ejecutan
Todos los servidores participan paralelamente en tareas de planificacioacuten derecursos y asignacioacuten de tareas y ademaacutes entre ellos eligen un liacuteder que seencarga de la coordinacioacuten de la suscripcioacuten de los clientes al cluster y de lagestioacuten de las peticiones
Los clientes estaacuten configurados para comunicarse con el servidor usando lla-madas a procedimiento remoto (RPC por sus siglas en ingleacutes) que permite unordenador ejecutar coacutedigo en otra maacutequina Mediante esta tecnologiacutea los nodosclientes avisan de su estado e informa de sus asignaciones recursos y controla-dores disponibles
Existe la posibilidad de gestionar varios centros de datos agrupados en regio-nes eacutestas son independientes pero permite definir tareas o comprobar el estadode todas ellas desde cualquier punto A continuacioacuten se muestra una figura dela arquitectura a alto nivel de esta configuracioacuten
Figura 10 Arquitectura multi-regioacuten en NomadFuente httpswwwnomadprojectio
La herramienta se sustenta sobre tres protocolos fundamentales un protocolode consenso entre los servidores para compartir informacioacuten sobre su estado yel liacuteder un protocolo Gossip para la gestioacuten entre regiones y el planificador detareas
521 Protocolo de consenso Raft
El objetivo es obtener consistencia en un conjunto de nodos que comparteninformacioacuten es decir si un cliente realiza un cambio que todos los nodos veanla misma informacioacuten a la vez y ademaacutes sea tolerante a fallos Para ello se basaen el algoritmo Raft[13] que se detalla brevemente a continuacioacuten
20
Los nodos participantes en el algoritmo pueden estar en tres estados
Liacuteder (Leader) Todos los cambios que realicen en el cluster pasan por eacutel pri-mero
Seguidor (Follower) Nodo pasivo cuya responsabilidad es responder a laspeticiones del nodo liacuteder
Candidato (Candidate) Maacutequina que no ha encontrado liacuteder y solicita sueleccioacuten
Supongamos que tenemos cinco equipos que acaban de arrancar el protocoloEn la figura 11 se observan los nodos y sus respectivos registros a la derecha
Figura 11 Equipos sin consenso ejecutando el protocolo RAFTFuente httpsgithubcomongardieraftscope
Al comenzar todos los nodos son seguidores esperando recibir comunicacioacutende un nodo que actuacutee como liacuteder Cada nodo tiene un tiempo de espera aleatoriodespueacutes del cual si no es informado por un liacuteder pasa a estado candidato y pideel ldquovotordquo al resto de los participantes El algoritmo divide el tiempo en plazos uncandidato pasa a liacuteder si recibe la mayoriacutea de los votos en un plazo determinadoSe define mayoriacutea o cuoacuterum (quorum) comolceil
N2rceil
+ 1 (1)
donde N representa el nuacutemero de nodos
Para el ejemplo propuesto de 5 equipos se requieren de 3 votos Soacutelo losnodos que se encuentren en estado seguidor pueden votar una uacutenica vez a laprimera solicitud que reciba dentro de un plazo
Supoacutengase que el nodo denotado con S1 ha cumplido su tiempo de espera yrealiza la peticioacuten de voto (figura 12) A partir de este momento se pueden dartres casos
La maacutequina gana la eleccioacuten y pasa a ser liacuteder informando al resto
Otro servidor se establece como liacuteder en el mismo momento
Varios nodos pasan a ser candidatos por lo que ninguno consigue los votos
21
Figura 12 Un equipo pasa a estado candidato (RAFT)
Si un candidato recibe un aviso de un liacuteder en el mismo plazo el primeropasa a ser seguidor y se acaba la eleccioacuten de liacuteder
Por otro lado si un equipo candidato no recibe los votos en el plazo y agotasu tiempo de espera avanza al siguiente plazo y repite el proceso de votacioacutenLa tercera posibilidad puede conllevar a un estado indefinido ya que varioscandidatos pueden agotar su tiempo de espera al mismo tiempo y repartir losvotos Para solventarlo el algoritmo establece tiempos de espera aleatorios paralos candidatos
Siguiendo con el ejemplo propuesto el servidor S1 pasa a ser el liacuteder Cadacierto tiempo eacuteste debe realizar avisos a los nodos seguidores para no agotar sutiempo de espera
En este momento el cluster de servidores estaacute en ldquoconsensordquo y la informacioacutenen todos los nodos estaacute actualizada Un cambio en la informacioacuten inicia unproceso de replicacioacuten el liacuteder registra el cambio lo pasa al resto de nodos yuna vez eacutestos responden el cambio se hace efectivo
Supoacutengase que se realiza un cambio en los datos en la figura 13 en la partederecha se observa el cambio en el registro del servidor S1 que informa a losnodos seguidores En consecuencia los nodos registran el cambio y responden aS1
Figura 13 Cambio en un registro (RAFT)
Una vez el cuoacuterum (en el ejemplo tres equipos) informa al liacuteder de que
22
ha registrado el cambio el liacuteder lo hace efectivo en su sistema y notifica a losnodos que hacen lo mismo En la figura 14 el enviacuteo todaviacutea no ha llegado ala maacutequina S3 y se observa que no ha hecho efectivo el cambio (en el registroaparece punteado)
Figura 14 Aprobacioacuten del resto de equipos (RAFT)
Este protocolo funcionaraacute correctamente mientras exista un nuacutemero de nodosen funcionamiento igual o superior al cuoacuterum en el ejemplo propuesto elcuoacuterum es tres por lo que el sistema puede tolerar la caiacuteda de dos de los equipos
522 Protocolo gossip SWIM
Nomad permite la gestioacuten simultaacutenea de varios centros de datos reparti-dos en regiones geograacuteficamente separadas requiriendo de un protocolo ligeroque mantenga a los miembros actualizados sobre los participantes del conjun-to Para ello usa una ligera variante del protocolo SWIM[3] (Scalable Weakly-consistent Infection-style Process Group Membership Protocol) desarrollada porHashiCorp Estaacute clasificado como un protocolo de tipo gossip que debe su nom-bre a la semejanza con coacutemo se distribuye un rumor en una red social
SWIM se sustenta en dos caracteriacutesticas fundamentales la deteccioacuten de fallosy la distribucioacuten de la informacioacuten relativa a los miembros A continuacioacuten sedetalla el funcionamiento de ambos componentes
Deteccioacuten de fallos
Este componente tiene dos paraacutemetros el periodo de protocolo T y el nuacutemerode subgrupos de deteccioacuten de fallos k en los que se dividen los nodos Paracomprobar la comunicacioacuten entre dos maacutequinas usa la utilidad ping basadaen el protocolo ICMP La deteccioacuten de caiacuteda de un servidor sigue el siguientealgoritmo
Durante el periodo T cada miembro Mi de un subgrupo elige otro al azar Mjdel mismo subgrupo y le enviacutea un mensaje ping para comprobar su estado Enel caso de que se cumpla un tiempo de espera determinado por una estimacioacuten
23
del tiempo de ida y vuelta (RTT por sus siglas en ingleacutes) de la red y no hayarespuesta Mi le vuelve a enviar un mensaje ping indirectamente a traveacutes deun nuacutemero k de miembros escogidos aleatoriamente De no recibir ninguna res-puesta Mi establece que Mj ha sufrido un fallo y lo etiqueta como ldquosospechosordquoinformando al componente de distribucioacuten
Figura 15 Diagrama de tiempo del protocolo SWIMFuente httpswwwcscornelledu
Componente de distribucioacuten
Se encarga de informar de cualquier cambio en los miembros a todo el con-junto Los eventos de nodo caiacutedo y la unioacuten o disociacioacuten de un miembro setransmiten a todos los servidores para que actualicen sus lista Para distribuirla informacioacuten a todos los nodos se podriacutea usar el meacutetodo de multicast perosuele estar deshabilitado Por ello se utiliza una teacutecnica de transmisioacuten denomi-nada Piggybacking mediante la cual se adjunta a los propios mensajes PINGy ACK del algoritmo la informacioacuten a distribuir reduciendo asiacute la congestioacutenen la red
523 Planificacioacuten
Proceso encargado de distribuir las tareas entre los nodos clientes de acuerdoa su estado
El planificador de Nomad estaacute basado en las publicaciones de Google sobresus herramientas de gestioacuten de clusters Borg y Omega14 y entiende los trabajosdescritos por el usuario como un estado deseado es decir su despliegue en unamaacutequina cliente de forma correcta y los clientes como el estado actual esto eslo que se encuentra en ejecucioacuten El registro actualizacioacuten o cancelacioacuten de un
14httpresearchgooglecompubspub43438html
24
trabajo asiacute como el fallo de un nodo cliente implican un cambio de estado atramitar por el sistema lo que se define como evaluacioacuten (evaluation) Esto uacutelti-mo supone comparar el estado actual (clientes) con el estado deseado (conjuntode trabajos registrados) y enviarlos a los planificadores correspondientes que seencargaraacuten de asignar las tareas a los nodos clientes
Figura 16 Procedimiento de asignacioacuten en NomadFuente httpswwwnomadprojectio
En la figura 16 se observa el flujo de trabajo en el que las distintas evalua-ciones se encolan en el evaluation broker que se ejecuta en el servidor liacuteder ygestiona las evaluaciones pendientes asignaacutendoles prioridades
A continuacioacuten los nodos servidores ejecutan los scheduling workers queprocesan las evaluaciones llamando a los distintos planificadores que generanun plan de asignacioacuten esto es un conjunto de relaciones entre las tareas y losnodos clientes donde se ejecutaraacuten Este proceso se divide en dos fases primerose descartan aquellos clientes que no cumplan los requisitos y posteriormentese asigna una calificacioacuten al resto Se selecciona el nodo con mayor puntuacioacuteny se encola el plan en el gestor que se ejecuta en el servidor liacuteder Existen tresplanificadores de acuerdo al tipo de trabajo
Service Incluye aquellos trabajos que estaacuten destinados a ejecutarse en un pe-riacuteodo largo de tiempo Para realizar las asignaciones el planificador evaluacuteala mayor parte de los nodos y usa una versioacuten del algoritmo Best fit in-fluenciada por el trabajo de Google en su herramienta Borg Se trata deun algoritmo de planificacioacuten que sacrifica tiempo a cambio de maximizarel rendimiento de los clientes asignando la tarea a la maacutequina que tengala mayor carga de trabajo con el objetivo de reducir equipos en funciona-
25
miento
Batch Tareas que incluyen listas de comandos en general de menor duracioacuteny que no requieren interaccioacuten con el usuario Se vale del algoritmo deSparrow desarrollado por la universidad de Berkeley15 para limitar losnodos clientes a evaluar
System Trabajos destinados a ejecutarse en todos los nodos incluso los que seunen al cluster posteriormente
Core Mantenimiento interno de Nomad
Una vez se ha realizado el proceso de planificacioacuten el nodo liacuteder lo registra enla cola de planes (plan queue) que se encarga de asignarles prioridad y manejarcondiciones de carrera es decir que no accedan a los recursos de los clientes sincontrol y evitar que eacutestos superen su capacidad
La maacutequina liacuteder del conjunto puede de este modo aceptar una asignacioacuteny ser ejecutada por los clientes o por el contrario rechazaacutersela al planificadorlo que implicariacutea realizar un plan parcial o totalmente nuevo
Finalmente el estado de las evaluaciones se actualizan y los clientes soninformados de las asignaciones ejecutaacutendose las tareas
15httppeopleeecsberkeleyedu~keopublicationssosp13-final17pdf
26
6 Casos de uso y despliegue
Con el objetivo de mostrar las posibles utilidades que este tipo de sistemaspueden tener en las infraestructuras TI actuales se han desplegado las dos he-rramientas en la nube Microsoft Azure usando su servicio cloud de instancias demaacutequinas virtuales Linux para simular un conjunto de ordenadores conectadosentre siacute por una red LAN Sobre ellas se ha implementado dos casos de usouna aplicacioacuten web con una arquitectura con cierta orientacioacuten a microserviciosy un sistema de integracioacuten continua
El coacutedigo y todos los ficheros de configuracioacuten se pueden encontrar en elrepositorio del proyecto en GitHub16
61 Aplicacioacuten Web
Se busca simular el proceso de adaptacioacuten de una solucioacuten web para su des-pliegue en un sistema distribuido con las herramientas anteriormente descritascon el objetivo de aumentar tanto su escalabilidad como disponibilidad medianteredundancia
Se ha partido de una aplicacioacuten ya existente17 un servicio de almacenamien-to y reproduccioacuten de canciones A grandes rasgos este servicio permite crearusuarios subir canciones con sus respectivas portadas tener playlists propias yescuchar las canciones a traveacutes de un navegador web
La solucioacuten estaacute dividida en 4 partes (figura 17)
Una vista web con la loacutegica
Un almacenamiento conectado en red (NAS por sus siglas en ingleacutes)
Una API REST para gestionar las peticiones al almacenamiento
Base de datos NoSQL basada en MongoDB
La nueva tendencia de los proyectos web es su implementacioacuten en contene-dores Docker ya que facilitan su portabilidad y ofrecen un procedimiento dedespliegue raacutepido sobre todo a la hora de desarrollar y realizar pruebas en en-tornos de produccioacuten simulados Por ello en este caso se va a hacer uso de los
16httpsgithubcomAntonioAlfrzCloud-Orchestrators17httpsgithubcomsonsoleslpCDPSfy
27
motores de orquestacioacuten de contenedores de ambas herramientas Marathon enDCOS y el controlador Docker en el caso de Nomad
Figura 17 Arquitectura aplicacioacuten web
A continuacioacuten vamos detallar el despliegue en ambas herramientas de es-ta solucioacuten y observar tanto queacute dificultades se encuentran como que ventajasofrecen El objetivo final es adaptar el proyecto modificaacutendolo lo menos posiblecon objeto de analizar la capacidad de estas herramientas para desplegar cual-quier aplicacioacuten sin que eso conlleve la modificacioacuten de la arquitectura de eacutestaes decir que no sea dependiente del entorno
611 DCOS
Se ha descrito DCOS como una herramienta que se despliega sobre un con-junto de ordenadores y que permite instalar gestionar el despliegue de sistemasdistribuidos
Microsoft Azure cuenta con una plantilla para desplegar en su servicio cloudun cluster de maacutequinas virtuales con DCOS ya instalado que cuenta con
Maacutequinas maestras (1 3 o 5 a seleccionar por el usuario) configuradascomo un conjunto de disponibilidad esto eso Azure da ciertas garantiacuteasde que al menos una maacutequina estaraacute en funcionamiento
Maacutequinas agentes Por motivos de seguridad se distinguen dos roles
bull Nodos privados solo accesibles desde la red interna y configuradoscomo un conjunto de escala un recurso de Azure para gestionar ydesplegar maacutequinas con configuraciones ideacutenticas para permitir unraacutepido escalado
bull Un equipo conectado accesible desde Internet a travntildees de un balan-ceador de carga puacuteblico y situado en una subred externa
28
Dos balanceadores de carga
bull La interfaz puacuteblica del cluster que se conecta con el cliente puacuteblicobull Acceso a los equipos maestros para el administrador que soacutelo permiteconexioacuten mediante SSH y credenciales
Almacenamiento para todas las maacutequinas
Configuraciones necesarias de red y seguridad
En la figura 18 se observa un diagrama de la infraestructura
Figura 18 Infraestructura en Azure
El primer obstaacuteculo es la persistencia de estado de la aplicacioacuten que seconsigue gracias a una base de datos no relacional basada en MongoDB asiacutecomo el almacenamiento de las canciones Para implementarla tenemos variasposibilidades
Montar un sistema externo de almacenamiento conectado en red en todoslos agentes donde se ejecuten las tareas de esta manera si una tarea pasade un nodo a otro por cualquier motivo puede tener acceso a los mismosficheros (opcioacuten del caso de uso original)
Implementar un sistema de ficheros distribuidos en los agentes
Usar los servicios de almacenamiento de las nubes puacuteblicas
Aprovechar el sistema de voluacutemenes persistentes de Apache Mesos Eacutestepermite reservar recursos de un agente de forma que al arrancar una tarease crea un volumen independiente del ciclo de vida de eacutesta con ello esosrecursos donde se ha almacenado la informacioacuten pueden volver a ofrecerseal mismo entorno de tal manera que otra tarea pueda acceder a ella
DCOS aprovecha este sistema de voluacutemenes persistentes y permite instalarbases de datos distribuidas como ArangoDB o Apache Cassandra sin embargoesto implicariacutea modificar todo el coacutedigo referente al modelo de la base de datos
29
Por motivos de eficiencia y latencia asiacute como de una mayor gobernabilidadde los datos la mejor opcioacuten es usar el recurso de voluacutemenes persistentes queofrece Apache Mesos ya que de esta manera se gestionariacutea la aplicacioacuten completamediante una uacutenica herramienta Sin embargo esto implica que la informacioacutense encuentra exclusivamente en el agente donde se haya ejecutado la tarea y porlo tanto se sigue requiriendo de software externo para distribuir la informacioacutenpara que se accesible para todos los agentes A la hora de realizar este proyectose encontraba en desarrollo Flocker una solucioacuten desarrollada por ClusterHQque permite compartir los voluacutemenes de Docker a traveacutes de un cluster quesi bien es compatible con el planificador de Mesos el proyecto se encontrabatodaviacutea en fases tempranas de desarrollo y los sistemas de almacenamiento quesoporta quedaban fuera del aacutembito de este trabajo
Por todo ello dado que las maacutequinas se han desplegado en la nube puacuteblicade Azure se decidioacute usar su servicio de almacenamiento de objetos para lascanciones y otra maacutequina para desplegar MongoDB y asiacute mantener el modelode datos original de la aplicacioacuten La diferencia del almacenamiento de obje-tos con respecto a nivel de fichero es que el primero no tiene jerarquiacutea paraorganizar los archivos eacutestos se guardan como objetos (con sus metadatos) enun mismo espacio soacutelo diferenciaacutendose por un identificador uacutenico esto implicaentre otras cosas que se puede acceder a un fichero dado uacutenicamente su IDindependientemente de la localizacioacuten fiacutesica de eacuteste facilitando pues la gestioacuteny el desarrollo
El coacutedigo del proyecto se ha modificado en los siguientes apartados
Las direcciones de la base de datos y los balanceadores de carga asiacute comosus puertos estaban originalmente fijos Se han configurado como variablesde entorno para facilitar el descubrimiento del servicio y hacer transpa-rente la aplicacioacuten al entorno de despliegue
La API REST se ha adaptado al almacenamiento en Azure en vez de enlocal
Estas modificaciones no suponen un cambio sustancial pero permiten separala persistencia de las tareas ejecutadas por DCOS lo que facilita en granmedida su ejecucioacuten al ser totalmente sin estado y ademaacutes implican tenerlos datos bajo un mayor control
Para la orquestacioacuten de contenedores se va a usar el entorno Marathondesarrollado tambieacuten por Mesosphere Eacuteste se puede usar a traveacutes de una interfazgraacutefica la interfaz de liacutenea de comandos (en lo que sigue CLI por sus siglas eningleacutes) de DCOS o con su API HTTP
Primero se han publicado la imaacutegenes de los contenedores que encapsulanla interfaz web y la api de la aplicacioacuten en el repositorio puacuteblico DockerHub
Los despliegues en este entorno se describen mediante ficheros JSON en losque se detalla entre otras opciones la imagen del contenedor los puertos a usar
30
los recursos que debe ocupar en un nodo o las instrucciones de monitorizacioacuten
Para el servicio de descubrimiento DCOS ofrece la posibilidad de asignardirecciones IP virtuales (VIP por sus siglas en ingleacutes) a tareas que se compartenen todos los nodos DCOS lleva integrado un balanceador de carga a nivel TCP(el componente denominado Minuteman) que balancea entre las direccionesvirtuales de las tareas y todas las instancias de eacutestas a lo largo del cluster Estoes necesario por dos motivos equilibrar la carga de los equipos con el fin deevitar un punto de uacutenico fallo mediante redundancia y evitar la contienda dedirecciones al ejecutar las tareas en puertos aleatorios
Este balanceador de carga estaacute basado en el trabajo de Michael Mitzenma-cher The Power of Two Choices in Randomized Load Balancing18 A grandesrasgos el algoritmo mantiene una media moacutevil exponencial de latencias paracada destino (backend) ademaacutes de las caiacutedas consecutivas Si un destino noresponde a una negociacioacuten en tres pasos (three way handshake) de forma con-secutiva en un periodo inferior a 5 ms se considera caiacutedo El algoritmo iterasobre los destinos disponibles en base a su histoacuterico de fallos y escoge dos deforma aleatoria de los cuales coge el de mejor meacutetrica
Las direcciones virtuales soacutelo se pueden resolver dentro del cluster porello para implementar la interfaz puacuteblica de la aplicacioacuten esto es el balancea-dor de carga de la interfaz web usaremos un paquete de DCOS denominadomarathon-lb un balanceador basado en HAProxy y adaptado por MesosphereEn este caso equilibra la carga de todas instancias de las tareas ejecutadas porel entorno Marathon por sus etiquetas y permite ademaacutes definir como puntode entrada muacuteltiples hosts virtuales definidos por sus nombres completos dedominio (FQDN por sus siglas en ingleacutes) en nuestro caso la interfaz puacuteblicadel balanceador de Azure para los agentes
Por motivos de seguridad todas las tareas se ejecutan en los agentes privadoses decir los que son exclusivamente accesibles desde la red interna Por su partemarathon-lb se ejecuta en el agente puacuteblico que cuenta con IP puacuteblica y lospuertos 80 (HTTP) y 8080 abiertos de forma que la aplicacioacuten sea accesibledesde Internet Esto es posible debido a que Apache Mesos permite reservarrecursos mediante roles asignados a nodos para un uso especiacutefico De esta formala arquitectura vista desde la aplicacioacuten quedariacutea como en la figura 19
18httpswwweecsharvardedu~michaelmpostscriptstpds2001pdf
31
Figura 19 Arquitectura de la aplicacioacuten web en DCOS
Ejecucioacuten
A la hora de desplegar la aplicacioacuten DCOS puede gestionarse medianteuna interfaz graacutefica o una interfaz de liacutenea de comandos La primera se accedea traveacutes de un navegador web en el puerto 80 (HTTP) y permite instalar losentornos disponibles observar el estado de los nodos y las tareas que se estaacutenejecutando y los ficheros de registros que eacutestas generan
La CLI permite el control desde un nodo o una maacutequina remota (suponiendoque los maestros tienen IP puacuteblica y el puerto 80 abierto) ya que DCOS tieneun sistema de autorizacioacuten que permite tener una interfaz puacuteblica con ciertasgarantiacuteas de seguridad
Por su parte cada entorno de trabajo puede ser controlado por la CLI peroademaacutes cuenta con sus propias interfaces Marathon expone una API HTTPen el puerto 8080 de la direccioacuten puacuteblica de los maestros del cluster asiacute comootra interfaz graacutefica Para desplegar un contenedor se podriacutea usar la CLI
$ dcos marathon app add lt f i l e j songt
O la API HTTP
$ cu r l minusX POST http lt ip_maestro gt8080v2apps minusd ltf i l e jsongt minusH Contentminustype app l i c a t i o n j son
32
612 Nomad
La arquitectura de Nomad es maacutes sencilla ya que solo requiere de un ficheroejecutable en todos los nodos para funcionar Si DCOS es la base de instala-cioacuten de entornos de terceros Nomad integra todas las funcionalidades baacutesicasesto es gestor de recursos planificador y ejecutor en los nodos cliente Estaherramienta cuenta con un menor tiempo de desarrollo y en el momento deescribir este documento cuenta exclusivamente con los siguientes controladoresen comparacioacuten con los entornos de DCOS
Motor Docker es decir funcioacuten de orquestacioacuten de contenedores
Ejecucioacuten de archivos binarios como comandos de Shell
Ejecucioacuten de aplicaciones Java
Virtualizacioacuten de maacutequinas mediante tecnologiacutea QEMU
Todos ellos necesitan que la tecnologiacutea subyacente esteacute instalada en las maacute-quinas clientes (Docker Java QEMU) Actualmente no permite el registro decontroladores por parte de terceros aunque estaacute planificado en un futuro ofreceruna interfaz para su desarrollo
Nomad no cuenta con el servicio de descubrimiento sin embargo puede inte-grarse con la herramienta Consul desarrollada por la misma empresa Por otrolado para el balanceo de carga usaremos un contenedor Docker con HAProxyuna herramienta de coacutedigo abierto que ofrece tanto servicios de proxy como debalanceador y cuyos ficheros de configuracioacuten completaremos con el proyectoConsul Template19
Consul
Consul sigue la misma arquitectura que Nomad es decir un nodo servidorque orquesta un conjunto de maacutequinas clientes y permite a los procesos que seejecutan en los equipos definirlos como servicios ofreciendo diversas caracteriacutes-ticas entorno a estos de los cuales vamos a usar dos
Descubrimiento de servicio Las maacutequinas clientes publican en el cataacutelogode servicios las tareas en ejecucioacuten y Consul les asigna nombres de dominioaccesibles por todos los miembros del cluster a traveacutes de la interfaz DNSincluida en esta herramientaConsul se integra con Nomad de forma que todas las tareas que se ejecu-ten en la segunda son automaacuteticamente publicados como servicios de laprimera de esta manera no hace falta conocer la direccioacuten de la maacutequinacliente donde se esteacute ejecutando el proceso ya que se puede acceder a eacutela traveacutes de su nombre de dominio de forma transparente Por ejemplo si
19[httpsgithubcomhashicorpconsul-template]
33
ejecutamos una tarea con ID web en el puerto 8080 se puede acceder aella en la direccioacuten webserviceconsul8080Para que las direcciones propias de Consul las resuelva su propio DNS y noel que esteacute asignado por defecto en la maacutequina usaremos la herramientadnsmasq20 que permite especificar la direccioacuten de un servidor DNS paraconsultas de direcciones especiacuteficas
Monitorizacioacuten Permite realizar comprobaciones del servicio y seguir su esta-do Aprovecharemos esta funcionalidad tanto para definir el propio procesode Nomad como servicio de Consul como las tareas desplegadas
HAProxy + Consul Template
HAProxy es una solucioacuten versaacutetil de coacutedigo abierto que ofrece solucionesde balanceo de carga y proxy Existen otras herramientas en el mercado comoNGINX o ldirectord sin embargo HAProxy suponiacutea una solucioacuten sencilla deconfigurar para mostrar el caso de uso
El uso de estas herramientas se debe a dos motivos para que no existacontienda con respecto a los puertos de los clientes usados por las tareas eacutestos sevan a asignar de forma dinaacutemica lo que en principio implicariacutea que la aplicacioacutendeberiacutea realizar consultas DNS de tipo SRV (que incluye puertos) a la interfazde Consul y balancear la carga entre tareas por redundancia y capacidad
Como la direccioacuten IP y puerto son variables cada vez que las tareas seactualicen o se reasignen es necesario volver a configurar HAProxy de formamanual Por ello HashiCorp ha desarrollado un programa denominado Con-sul Template que realiza peticiones sucesivas a la interfaz HTTP de Consul delas direcciones fiacutesicas de un servicio y reinicia automaacuteticamente el proceso deHAProxy Asiacute definiendo estas tareas como servicios Consul podremos tantomonitorizarlas como escalar las tareas dinaacutemicamente sin necesidad de cambiarel balanceador A partir del contenedor Docker oficial de HAProxy se ha desa-rrollado otro con la configuracioacuten baacutesica y con Consul Template para desplegarlocomo una tarea en Nomad
Despliegue
Se ha usado el mismo coacutedigo que en el apartado anterior con la persistenciaen el servicio de almacenamiento de Azure Desde la perspectiva del hardwarese implementaraacute la misma infraestructura que en el caso de DCOS (figura 18)estos es definiremos dos tipos de maacutequinas clientes un agente que se conectaraacutecon el balanceador de carga con nombre de dominio puacuteblico y donde se desple-garaacute el balanceador de carga de la vista web y agentes privados no accesiblesdesde fuera del cluster y donde se ejecutaraacuten el resto de tareas en la red inter-na La principal diferencia radica en las tareas que ejecutan HAproxy y ConsulTemplate que sustituye a las direcciones IP virtuales que ofrece DCOS
20httpwwwthekelleysorgukdnsmasqdochtml
34
Figura 20 Despliegue en Azure de Nomad+Consul
Cabe matizar que los balanceadores basados en HAProxy se implementanpor necesidad de la aplicacioacuten para el descubrimiento del servicio a diferenciade los de Azure que se implementan por motivos de seguridad y escalabilidaddel cluster en siacute
Configuracioacuten Nomad
Los ficheros de configuracioacuten de las maacutequinas maacutester y cliente son similaresy comparten la mayoriacutea de las opciones como por ejemplo el nombre del nodoo la interfaz de red donde escucha Nomad las peticiones Sus opciones son engeneral auto-explicativas sin embargo existen dos detalles que matizar
El proceso de Nomad escucha las peticiones tanto de los protocolos deconsenso como del usuario a traveacutes de una interfaz de red que se debeindicar en el fichero de configuracioacuten
En el caso de los clientes se deben indicar las direcciones de los servidoresdel cluster sin embargo se trata de un sistema dinaacutemico en el que losnodos pueden sufrir errores y cambiar de direccioacuten Por ello se ha definidoNomad como un servicio de Consul y asiacute poder definir la direccioacuten de losservidores como un nombre de dominio no por su direccioacuten fiacutesica que elservidor DNS de Consul se encargaraacute de resolver
Por defecto Nomad usa los siguientes puertos
API HTTP 4646 Peticiones HTTP y recepcioacuten de oacuterdenes mediante laliacutenea de comandos
RPC 4647 Protocolo de consenso entre los nodos del cluster
Serf 4648 Protocolo de gossip entre los servidores de los centros de datosgobernados por Nomad
35
Los dos uacuteltimos deben ser interfaces alcanzables por otros nodos sin embargo laAPI HTTP por motivos de seguridad deberiacutea ser local ya que en caso contrariocualquier persona con acceso a ella tiene el control sobre la herramienta Eacutestasolo deberiacutea estar accesible en un servidor o gestionarlo mediante una terminalSSH por ejemplo En este trabajo al ser una prueba de concepto se ha abiertoen todos los nodos
Trabajos de Nomad
Las tareas se detallan en ficheros con formato HashiCorp Configuration Lan-guage un derivado del formato JSON creado por la empresa que le da nombrecompatible con eacuteste y que permite comentarios
En estos ficheros se puede definir
La regioacuten y el centro de datos donde se ejecutaraacute (Nomad permite lagestioacuten de centros de datos geograacuteficamente distribuidos en regiones)
La poliacutetica de actualizacioacuten de la tarea
Grupo de tareas esto es que se ejecutaraacuten en el mismo nodo
El nuacutemero de grupos a ejecutarescalar asiacute como los liacutemite que debencumplir los nodos asignados
La poliacutetica de reinicio ante fallo o error
Tareas El controlador su configuracioacuten los paraacutemetros del servicio aso-ciado a registrar en Consul asiacute como los recursos que consume (puertosmemoria)
En nuestro caso usamos sobre todo el controlador Docker esto eso orques-tacioacuten de contenedores en los nodos clientes y tres de sus opciones
Imagen del contenedor Se han subido todas las imaacutegenes del proyecto a Doc-ker Hub donde por defecto se busca la imagen
Puertos Los puertos a usar por el contenedor que pueden ser estaacuteticos asigna-dos por el usuario o dinaacutemicos siendo Nomad el que se encarga de mapearun puerto libre del nodo cliente al expuesto por el contenedor
Servidores DNS Como usamos la interfaz DNS de Consul como descubri-miento de servicio se debe configurar el contenedor para que use cualquiernodo del cluster como servidor DNS
Configuracioacuten Consul
Al ser desarrolladas por la misma empresa los ficheros de configuracioacuten deConsul y Nomad comparten muchas opciones Consul tambieacuten acepta peticionesa traveacutes de una interfaz de red siendo los puertos usados por defecto
36
RPC 8300 8400 Maneja la peticiones del resto de nodos y usuarios
Serf 8301 8302 Protocolo gossip
HTTP API 8500
HTTPS API Desactivada por defecto
Interfaz DNS 8600
Se debe asignar a los protocolos internos del cluster esto es RPC y Serf unainterfaz alcanzable por los nodos y por el contrarioasignar a los dos uacuteltimos ala interfaz de loopback por motivos de seguridad
Cabe destacar que Consul tambieacuten cuenta con una interfaz graacutefica que per-mite ver el estado de los equipos y los servicios registrados y que se encuentra enel mismo puerto que la API HTTP en la direccioacuten httpIP_EQUIPO8500ui
Ejecucioacuten
Tanto Nomad como Consul requieren de la ejecucioacuten de un fichero en todoslos nodos integrantes del cluster Como prueba de concepto se ha decidido usardos servidores para ambos aunque cabe matizar que es un nuacutemero ineficienteya que la caiacuteda de uno de ellos supondriacutea la peacuterdida del cuoacuterum y por tantodel consenso del cluster
En primer lugar se arrancan los servidores que son los encargados de ejecu-tar el protocolo de consenso y gestionar el cluster y a continuacioacuten los clientesque no tienen praacutecticamente estado y dependen de los servidores
En el caso de Consul se debe indicar el directorio donde se guardan losficheros que describen los servicios asiacute como el archivo que especifica el resto delas opciones
1 Se inicia el primer servidor en uno de los equipos
$ consu l agent minuscon f i gminusd i r e t c consu l d s e r v i c e s minuscon f i gminus f i l e consu l_server j son
2 Los siguientes equipos deben unirse al anterior por lo que antildeadimos elargumento join con la direccioacuten del primer servidor Para el caso de otrosservidores
$ consu l agent minuscon f i gminusd i r e t c consu l d s e r v i c e s minuscon f i gminus f i l e consu l_server j son minus j o i n ltIP_servidor1gt
37
Una vez los servidores han alcanzado el consenso y elegido un liacuteder en losclientes
$ consu l agent minuscon f i gminusd i r e t c consu l d s e r v i c e s minuscon f i gminus f i l e c on su l_c l i en t j son minus j o i n ltIP_cualquierServ idorgt
El proceso para iniciar Nomad es igual y los comandos similares sin embargoya no es necesario indicar una direccioacuten IP fija en los equipos sino el nombre dedominio del servicio de Nomad registrado por Consul En el primer servidor
$ nomad agent minusc on f i g nomad_server j son
Y el resto de equipos (con su fichero de configuracioacuten correspondiente)$ nomad agent minusc on f i g nomad_server j son minus j o i n nomad s e r v i c e consu l
Por uacuteltimo para desplegar la aplicacioacuten web se han escrito tres ficherosque detallan las tareas de la interfaz web API y los balanceadores de cargaMediante la CLI
$ nomad run minusaddress=http lt ip_c lus te r gt4646 lt f i l e hclgt
O mediante la API HTTP de Nomad$ cu r l minusX POST minusd ltf i l e hclgthttp lt ip_c lus te r gt4646 jobltjob_namegt
Ansible
Como se puede comprobar con el aumento del nuacutemero de equipos pasa aser inviable manejar todos los nodos a traveacutes de terminal Ademaacutes como seha comentado con anterioridad Nomad requiere que en los nodos clientes es-teacuten instalados las herramientas que soporten las tareas por ejemplo el motorde Docker Por ello para facilitar tanto el arranque como la instalacioacuten de lasdependencias vamos a usar Ansible una herramienta de coacutedigo abierto desarro-llada en Python que permite gestionar configuraciones aprovisionar recursosdespliegue de aplicaciones de forma automaacutetica
A grandes rasgos esta herramienta funciona mediante ficheros en formatoYAML denominados play-books que describen un conjunto de pasos a ejecutaren una lista de equipos remotos Estos pasos son ejecutados por moacutedulos inde-pendientes a traveacutes de SSH es decir en cualquier ordenador con conexioacuten a los
38
hosts dado su contrasentildea o clave puacuteblica puede arrancar el script y realizariacutealos pasos de forma remota gestionando el cluster desde un solo equipo
Se han desarrollado guiones para lo siguiente
Descarga de los binarios de Nomad y Consul en todos los nodos copiade los ficheros de configuracioacuten baacutesicos y modificarlos de acuerdo a cadanodo (nombre del equipo direccioacuten IP)
Instalacioacuten de las dependencias
Arranque de Nomad y Consul
Ansible extiende su funcionalidad a traveacutes de moacutedulos independientes que per-miten por ejemplo instalar paquetes mediante herramientas de gestioacuten de pa-quetes (APT yum) aprovisionar automaacuteticamente maacutequinas virtuales de Ama-zon EC2
Algunas opciones de los ficheros de configuracioacuten de Nomad y Consul sondependientes del nodo particular por ejemplo la interfaz de red Para estetrabajo se ha realizado un moacutedulo para modificar los ficheros de configuracioacutende forma automaacutetica En el repositorio del proyecto se encuentra una carpetadonde se encuentran todos los ficheros necesarios para desplegar un clustertotalmente funcional solo requiere de una liacutenea de terminal con Ansible
$ ans ib l eminusplaybook minus i hos t s minusk ltssh_passgt minusu ltnode_usergt s i t e yml
39
62 Servicio de integracioacuten continua
Se ha implementado un sistema de integracioacuten continua que permite ejecu-tar tareas de compilacioacuten y pruebas de forma distribuida aumentando asiacute elrendimiento de los equipos En primer lugar se detallaraacute los motivos por los quepuede resultar beneficioso para las empresas una implementacioacuten de este tipo alo que seguiraacute los detalles del despliegue
621 DevOps
Metodologiacutea que defiende la comunicacioacuten y colaboracioacuten entre desarrolla-dores de software y los profesionales de operaciones a lo largo de todo el ciclo devida de una aplicacioacuten Estaacute muy relacionado con el desarrollo aacutegil de softwareesto es un enfoque para los proyectos que defiende el desarrollo iterativo e in-cremental donde los requisitos y soluciones evolucionan con el tiempo seguacuten lanecesidad del proyecto DevOps extiende esta filosofiacutea a todas los componentesde un servicio incluyendo sistemas y operaciones
Se trata de un concepto que cada organizacioacuten o empresa adapta a suspropias necesidades y procesos de negocio en este proyecto nos vamos a centraren la integracioacuten continua una praacutectica fundamental tanto del desarrollo aacutegilcomo de esta filosofiacutea
622 Integracioacuten Continua
Se define como una praacutectica de desarrollo software donde los miembros delequipo ponen en comuacuten su trabajo frecuentemente al menos una vez al diacutea21Cada integracioacuten se verifica con una compilacioacuten automaacutetica que incluye laejecucioacuten de pruebas para detectar errores de integracioacuten tan pronto como seaposible
Desde el punto de vista operativo esto supone automatizar la configuracioacutende equipos o el despliegue de maacutequinas virtuales donde compilar el proyecto yejecutar las pruebas y posteriormente eliminarlas Este flujo de trabajo se vebeneficiado en entornos distribuidos ya que el objetivo del desarrollador es com-probar el resultado de las pruebas raacutepidamente sin preocuparse del despliegueo los propios equipos
Para esta prueba de concepto vamos a usar Jenkins un servidor de integra-cioacuten continua escrito en Java que nos permite definir trabajos que contendraacutenla descripcioacuten tanto del entorno como su ejecucioacuten
Este sigue una estructura maestro-esclavo muy similar al de los gestores declusters usados en este proyecto el maestro contiene toda la loacutegica del servicio
21httpmartinfowlercomarticlescontinuousIntegrationhtml
40
trabajos autenticacioacuten y los esclavos son los encargados de la ejecucioacuten ensiacute Jenkins tiene varias viacuteas para aprovisionar los uacuteltimos
Mediante SSH
Interfaz graacutefica
Desarrollar un script propio
Ejecucioacuten de un fichero java
La ventaja de usar planificadores es que el despliegue de esclavos es dinaacutemicoes decir no tener una maacutequina especiacuteficamente configurada para ello DCOS yNomad se encargaraacuten de configurar estos despliegues en sus maacutequinas y poste-riormente eliminarlos Para ello se ha usado la uacuteltima opcioacuten definiendo tareasque descarguen el fichero java Con todo ello se consigue un entorno de inte-gracioacuten continua eficiente que ademaacutes permite la ejecucioacuten de otros servicios deforma independiente
Jenkins permite la creacioacuten de plugins que extienden sus funcionalidadesTanto Nomad22 como Apache Mesos cuentan con uno que permite su integra-cioacuten
Para esta prueba se va a usar el mismo proyecto que para el caso de usode orquestacioacuten de contenedores la aplicacioacuten web al que se le ha antildeadido untest para comprobar que se conecta correctamente a la base de datos medianteMocha un framework de Nodejs Por otro lado se antildeade el plugin de git ya queel coacutedigo se obtiene de GitHub el repositorio remoto de control de versiones delproyecto
El proceso general de ejecucioacuten seriacutea como sigue
1 Se ejecuta el maestro de Jenkins como tarea Docker partiendo de la imagenoficial
2 Al arrancar un trabajo se manda una tarea a los planificadores que laasignaraacuten a un nodo cliente Esta tarea consiste en la descarga del ficherode configuracioacuten Java y arrancarlo configurando el equipo como un clientede Jenkins temporalmente
3 Jenkins ejecuta el trabajo en el nuevo cliente en este caso iniciar la apli-cacioacuten web iniciar las pruebas y generar un informe
4 Se elimina el cliente
A continuacioacuten se detallan los matices de cada herramienta a la hora de imple-mentar este servicio
22Desarrollado por Ivo Verberk httpwwwivoverberknl
41
623 Jenkins con Nomad
El plugin permite la ejecucioacuten del fichero Java mediante dos controladorescontenedores Docker y Java En este proyecto nos hemos decantado por el pri-mero ya que nos ahorra instalar la maacutequina virtual de java en todos los nodoscliente Por ello se ha construido un contenedor base con Java para la ejecucioacutendel fichero de configuracioacuten y Nodejs para lanzar la aplicacioacuten web
El plugin se configura con la direccioacuten IP del cluster y el contenedor queejecuta el esclavo Jenkins Por su parte el trabajo en Jenkins se define conel repositorio en GitHub donde se aloja el coacutedigo del proyecto a probar y loscomandos a ejecutar en este caso npm update y npm test
624 Jenkins con DCOS
En el caso de DCOS su sistema de paquetes incluye Jenkins por lo queal instalarlo ya se tiene la configuracioacuten de Mesos totalmente funcional Sinembargo para ejecutar la aplicacioacuten en particular y las pruebas se requiere deNodejs en los equipos esclavos por ello debemos antildeadir un plugin de Jenkinsque permite instalar este entorno antes de ejecutar el trabajo Una vez hechoesto soacutelo queda definir la tarea igual que en el caso anterior
Cabe destacar que Mesosphere tambieacuten ha desarrollado un plugin que per-mite hacer despliegues en Marathon de tal manera que permitiriacutea con cadacommit del coacutedigo compilar la imagen del contenedor Docker y desplegarlaautomaacuteticamente aunque en este proyecto no se ha hecho pruebas de esta fun-cionalidad
42
7 Escalando la infraestructura
Uno de los factores clave que se busca a la hora de implementar sistemasdistribuidos es el poder escalar la infraestructura de forma maacutes sencilla estoes detectar que las maacutequinas estaacuten alcanzando el liacutemite de su capacidad yaumentar eacutesta ya sea mejorando sus caracteriacutesticas teacutecnicas o antildeadiendo maacutesnodos al cluster
El coacutedigo y todos los ficheros de configuracioacuten de esta seccioacuten tambieacuten sepueden encontrar en el repositorio del proyecto en GitHub23
71 Disentildeo
Microsoft Azure permite organizar los servicios cloud de forma loacutegica a traveacutesde grupos de recursos y asiacute poder crear o eliminar eacutestos en conjunto parauna aplicacioacuten determinada (por ejemplo una aplicacioacuten web suele requerir demaacutequinas virtuales bases de datos almacenamiento) Ademaacutes dispone dela opcioacuten de crear plantillas en formato JSON que permite al desarrolladordefinir los recursos y su interrelacioacuten para desplegar de forma automaacutetica unainfraestructura TI en la nube
Azure tambieacuten ofrece la posibilidad de monitorizar el estado de las maacutequinasvirtuales a traveacutes de extensiones lo que permite configurar el escalado automaacute-tico al alcanzar cierto liacutemite definido por el operador Eacutesta es a priori la formaen que deberiacutea implementarse hablando en teacuterminos de eficiencia sin embargoesta aproximacioacuten es totalmente dependiente de la plataforma es decir no sepuede extrapolar a otro proveedor o sobre recursos propios sin realizar un nue-vo disentildeo En este proyecto las tareas que son ejecutadas por estos equipos notienen estado ya que todo lo relativo a la persistencia lo hemos asignado fueradel cluster esto permite escalar la plataforma a traveacutes de otra aproximaciones
Las plantillas aceptan una serie de variables a indicar por el usuario entreotras los conjuntos de escala para definir los nodos aceptan una variable quedefine el nuacutemero de maacutequinas que los componen Por otro lado Azure ofreceuna API REST y kits de desarrollo software (SDK por sus siglas en ingleacutes) quepermiten su despliegue de forma programaacutetica Aprovechando estas facilidadesen este proyecto se va a aproximar la escalabilidad con el sucesivo desplieguede la infraestructura de forma automaacutetica se monitorizan los equipos y si sedetecta una maacutequina excesivamente cargada se aumenta el nuacutemero de equiposen la plantilla y se vuelve a desplegar
23httpsgithubcomAntonioAlfrzCloud-Orchestrators
43
En este proyecto se han disentildeado las plantillas para desplegar la arquitec-tura necesaria tanto de Nomad como de DCOS En el caso de la primera eldespliegue es maacutes descriptivo ya que incluye maacutequinas virtuales grupos de se-guridad redes En el caso de DCOS Azure cuenta con un servicio especiacuteficopara clusters gobernados por DCOS denominado Azure Container Service queincluye los componentes necesarios y la instalacioacuten ya realizada
72 Implementacioacuten
En primer lugar para monitorizar el estado de los equipos se va a usar laherramienta Nagios un sistema que permite controlar el estado del hardwarey los servicios de un equipo Se trata de una herramienta muy completa de laque se va a usar su capacidad para ejecutar comandos (plugins) en los nodospara detectar picos de carga generar alertas y ejecutar programas para estoseventos
Se ha desplegado una maacutequina virtual con esta herramienta en ambos siste-mas y se ha instalado una extensioacuten de Nagios (Nagios Remote Plugin Executor)en todos los nodos que permite ejecutar comprobaciones remotamente en con-creto para esta prueba de concepto medir el nivel de saturacioacuten de la unidadcentral de procesamiento (CPU por sus siglas del ingleacutes) Cuando sucede uncambio de estado de una maacutequina esto es cuando este paraacutemetro supera el liacutemi-te definido por el operador Nagios permite actuar en consecuencia ejecutandoprogramas por ello se ha desarrollado un script que ejecuta lo siguiente
Un programa desarrollado en Python con el SDK de Azure que modificalas plantillas y despliega los recursos
Un guioacuten de Ansible para instalar todos los componentes necesarios en lasnuevas maacutequinas y arrancar de nuevo el cluster y las aplicaciones
44
8 Resultados y conclusiones
En este uacuteltimo apartado se da una visioacuten global del proyecto asiacute como a lasconclusiones maacutes importantes a las que se ha llegado y posibles temas futurosde desarrollo
81 Comparacioacuten
Ambas herramientas ofrecen las funcionalidades para gestionar los recursoseficientemente ofreciendo a los desarrolladores una plataforma donde desplegarsus aplicaciones de forma distribuida independientemente de los equipos fiacutesicosy el hardware que las soporten
DCOS es una herramienta que en un comienzo fue privativa pero cuyos res-ponsables la empresa Mesosphere decidieron publicar una versioacuten de coacutedigoEacutesta nos permite gestionar un cluster de una forma sencilla y usable ademaacutes decomplementarlo con otras herramientas como el balanceador de carga integradoo la autenticacioacuten de usuarios ademaacutes estaacute basada en Apache Mesos un pro-yecto de relativa madurez y con el soporte de la Apache Software FoundationDe forma resumida DCOS ofrece muchas posibilidades y servicios a cambiode una arquitectura e instalacioacuten maacutes compleja
Por su parte HashiCorp con menor tiempo de desarrollo ha conseguidouna herramienta muy sencilla de desplegar que ademaacutes cumple con todas lasfuncionalidades baacutesicas ejecutando un simple binario en cada nodo se puededesplegar un gestor de clusters totalmente funcional Sin embargo no cuentacon todas las posibilidades de Mesos (Nomad cuenta con menos controladoresque entornos posibles de Mesos) ni con los antildeadidos de DCOS lo que implicael uso de otras herramientas para complementar el servicio (Consul HAProxy)
De entre las dificultades encontradas al usar estas herramientas y desplegaraplicaciones sobre ellas se puede destacar la depuracioacuten en ocasiones se desco-noce si un error viene de la propia herramienta de la aplicacioacuten desplegada o delequipo fiacutesico si no se cuenta con un sistema de procesamiento de registro unose puede encontrar con muacuteltiples terminales abiertas inspeccionando numerososficheros de registro buscando posibles errores Ademaacutes no dejan de ser solucio-nes que para usar eficientemente se debe conocer parte de su funcionamientoy sintaxis a la hora de describir la tareas lo que supone un esfuerzo antildeadido yaque cada una tiene sus particularidades y liacutemites
45
82 Conclusiones
En una sociedad cada vez maacutes digital las empresas deben adaptarse a unmercado cuya demanda de contenido no deja de crecer Las nuevas arquitecturascomo microservicios asiacute como la gran cantidad de datos generada implica queuna mejor gestioacuten de los recursos y la rapidez para desplegar o escalar solucionesdando valor al cliente lo maacutes raacutepido posible es uno de los objetivos de todas lasempresas de base tecnoloacutegica
Las ventajas que ofrecen los planificadores con aplicaciones distribuidas sonnumerosas sin ir maacutes lejos empresas tan punteras como Google llevan maacutesde 10 antildeos orquestando contenedores24 Por un lado permiten aumentar elrendimiento de los equipos propios y por otro implementar un servicio comoplataforma para despliegues distribuidos sobre cualquier conjunto hardware deesta forma se provee un servicio similar al de la nube puacuteblica pero con laprincipal diferencia de que se elimina la independencia con el proveedor (vendorlock-in) esto es las aplicaciones no tienen limitaciones impuestas por eacuteste talescomo lenguaje de programacioacuten o herramientas y permite despliegues hiacutebridosentre recursos propios y la nube
83 Objetivos conseguidos
Implementacioacuten de los planificadores propuestos en la nube Se ha en-tendido y detallado el funcionamiento de estas herramientas y se hanimplementado en el servicio de infraestructura de Microsoft Azure
Despliegue de aplicaciones y servicios distribuidos Servicios que se usanactualmente en la industria del desarrollo software asiacute como una aplica-cioacuten web con una arquitectura moderna han sido desplegados de formadistribuida en los equipos cumpliendo con la funcionalidad esperada ade-maacutes de consiguiendo una alta disponibilidad
Aproximacioacuten de arquitectura escalable Se ha hecho una aproximacioacutende infraestructura escalable de forma que sea parcialmente extrapolable aotros proveedores
24httpwwwnextplatformcom20160322decade-container-control-google
46
84 Liacuteneas de investigacioacuten
Siguiendo con la materia de este proyecto se presentan posibles liacuteneas deinvestigacioacuten
Analizar el despliegue con estas herramientas de aplicaciones de Big Datay comparar la eficiencia con respecto a soluciones especializadas
Analizar el rendimiento de los algoritmos de planificacioacuten antes pruebasde estreacutes y situaciones de alta contienda
Comparar el uso de estas herramientas con las praacutecticas actuales de laindustria o implementacioacuten en un sistema de produccioacuten real
47
Referencias
[1] LA Barroso y U Houmllzle laquoThe Datacenter as a Computer An Introduc-tion to the Design of Warehouse-Scale Machinesraquo En Morgan amp ClaypoolPublishers ()
[2] Systems Research Group ndash NetOS (University of Cambridge) The evolu-tion of cluster scheduler architectures 2016 url httpswwwclcamacukresearchsrgnetoscamsasblog2016-03-09-scheduler-architectureshtml
[3] A Das I Gupta y A Motivala SWIM Scalable Weakly-consistent Infection-style Process Group Membership Protocol Inf teacutec Dept of ComputerScience Cornell University url https www cs cornell edu ~asdasresearchdsn02-swimpdf
[4] D Dubhashi y A Das Mastering Mesos PACKT Publishing mayo de2016
[5] The Apache Software Foundation Apache Mesos documentation urlhttpsmesosapacheorg
[6] David Greenberg Building Applications on Mesos OrsquoReilly Media 2016[7] Armand Grillet Comparison of Container Schedulers Inf teacutec Technische
Universitaumlt Berlin[8] HashiCorp Consul documentation url httpswwwconsulio[9] HashiCorp Nomad documentation url httpsdcosio[10] Dan C Marinescu Cloud computing theory and practice Morgan Kauf-
mann 2013[11] Mesosphere DCOS documentation url httpswwwnomadproject
io[12] Microsoft Azure documentation url httpsazuremicrosoftcom
es-esdocumentation[13] D Ongaro y J Ousterhout In Search of an Understandable Consensus
Algorithm Inf teacutec Stanford University url httpsraftgithubioraftpdf
[14] Fei Teng laquoRessource allocation and schelduling models for cloud compu-tingraquo Tesis de mtriacutea Ecole Centrale Paris 2011
[15] A Williams y col Automation and Orchestration with Docker and Contai-ners A Comprehensive Overview of the Docker and Container Ecosystem3 The New Stack 2016
48
- Resumen
- Summary
- Iacutendice de figuras
- Introduccioacuten y objetivos
-
- Contexto
- Objetivos
- Estructura del documento
-
- Cloud Computing
- Nuevas cargas de trabajo
- Gestioacuten de recursos Planificadores
-
- Sistemas distribuidos
-
- Clasificacioacuten
-
- Herramientas
-
- DCOS
-
- Apache Mesos
- Ejemplos de uso
-
- Nomad
-
- Protocolo de consenso Raft
- Protocolo gossip SWIM
- Planificacioacuten
-
- Casos de uso y despliegue
-
- Aplicacioacuten Web
-
- DCOS
- Nomad
-
- Servicio de integracioacuten continua
-
- DevOps
- Integracioacuten Continua
- Jenkins con Nomad
- Jenkins con DCOS
-
- Escalando la infraestructura
-
- Disentildeo
- Implementacioacuten
-
- Resultados y conclusiones
-
- Comparacioacuten
- Conclusiones
- Objetivos conseguidos
- Liacuteneas de investigacioacuten
-
Iacutendice de figuras
1 Comparacioacuten Centro de datos - Computacioacuten en la nube 4
2 Arquitectura Docker 6
3 Planificador monoliacutetico 11
4 Planificador de dos niveles 11
5 Planificador de estado compartido 12
6 Planificador distribuido 12
7 Arquitectura DCOS 14
8 Servicios DCOS 15
9 Arquitectura de Apache Mesos 17
10 Arquitectura multi-regioacuten en Nomad 20
11 Equipos sin consenso ejecutando el protocolo RAFT 21
12 Un equipo pasa a estado candidato (RAFT) 22
13 Cambio en un registro (RAFT) 22
14 Aprobacioacuten del resto de equipos (RAFT) 23
15 Diagrama de tiempo del protocolo SWIM 24
16 Procedimiento de asignacioacuten en Nomad 25
17 Arquitectura aplicacioacuten web 28
18 Infraestructura en Azure 29
19 Arquitectura de la aplicacioacuten web en DCOS 32
20 Despliegue en Azure de Nomad+Consul 35
ix
1 Introduccioacuten y objetivos
11 Contexto
Las tecnologiacuteas de la informacioacuten y la comunicacioacuten estaacuten suponiendo uncambio draacutestico en la sociedad en 2007 comenzaron a aparecer los teleacutefonosinteligentes tal y como los conocemos y nueves antildeos despueacutes se empieza a con-cebir la idea de dar conectividad a todo dispositivo electroacutenico movimiento queha tomado el nombre de Internet de las cosas Para hacerse una idea de la rapi-dez y magnitud de esta evolucioacuten la consultora Excelacom1 ha estimado que enun minuto se realizan 24 millones de buacutesquedas en Google o se ven 278 millonesde viacutedeos en Youtube En una eacutepoca en la que los recursos tecnoloacutegicos crecenexponencialmente y los usuarios demandan mayor contenido y movilidad nocabe duda que las empresas deben adaptarse lo maacutes raacutepidamente posible a esteproceso de digitalizacioacuten movidas por las nuevas necesidades de las personas
Dado el gran volumen de informacioacuten a lo largo de estos antildeos la compu-tacioacuten y el almacenamiento estaacuten pasando de clientes locales a concentrarse engrandes centros de datos una tendencia que Google ha denominado ldquoWarehouse-scale computingrdquo en 2009[1] Este movimiento hacia la computacioacuten desde ser-vidor no solo viene de la necesidad de mejorar la experiencia de los usuariossino tambieacuten de facilitar la gestioacuten y configuracioacuten de los recursos asiacute como laubicuidad de acceso que permite
En 2006 Amazon lanza Amazon Web Services siendo uno de los pionerosen el mercado de los recursos virtuales ofreciendo capacidad de computacioacutencon un coste proporcional exclusivamente a los recursos utilizados Todo ellocambioacute la perspectiva de los modelos tradicionales de TI a la conocida comocomputacioacuten en la nube recursos informaacuteticos que antes suponiacutean barrerasde entrada en ciertos mercados han pasado a ser condicioacuten necesaria para laconstante evolucioacuten de la tecnologiacutea y la sociedad De hecho Cisco estima quepara el antildeo 2019 maacutes del 86 de las cargas de trabajo seraacuten procesadas porcentros de datos en la nube2
1httpwwwexcelacomcomresourcesblog2016-update-what-happens-in-one-internet-minute2httpwwwciscocomcenussolutionscollateralservice-provider
global-cloud-index-gciCloud_Index_White_Paperpdf
1
12 Objetivos
El propoacutesito de este proyecto es estudiar la viabilidad del uso de planifica-dores de recursos para aumentar la eficiencia de eacutestos y facilitar al desarrolladorel despliegue de aplicaciones de forma distribuida y asiacute ofrecer un servicio ca-racterizado por una alta disponibilidad y escalabilidad
A lo largo de este trabajo se han usado algunas de las herramientas quese estaacuten comenzando a desarrollar para hacer frente a este nuevo enfoque degestioacuten de infraestructuras de las tecnologiacuteas de la informacioacuten (en adelanteinfraestructuras TI) realizando pruebas de concepto sobre cada una de ellas
13 Estructura del documento
A continuacioacuten se detalla las secciones que componen este trabajo La es-tructura queda como sigue
Cloud computing Se entra en detalle en este nuevo modelo de negocio queha originado nuevos enfoques y disentildeos de las infraestructuras TI dentrode las organizaciones
Nuevas cargas de trabajo Se explican algunas tecnologiacuteas representativasque estaacuten suponiendo un desafiacuteo para los profesionales de TI a la horade planificar los recursos y que se ven beneficiadas por entornos de tipocloud
Gestioacuten de recursos Planificadores Estado del arte de las tecnologiacuteas degestioacuten de clusters y planificacioacuten de recursos
Herramientas Descripcioacuten detallada del funcionamiento y arquitectura de lasherramientas usadas a lo largo del proyecto
Casos de uso y despliegue Se describe el proceso de implementacioacuten de unaaplicacioacuten web y un servicio de integracioacuten continua con el software pro-puesto
Escalando la infraestructura Se propone un procedimiento con cierta inde-pendencia del proveedor cloud
Resultados y conclusiones Resume las ideas y hechos a los que se ha llegadoademaacutes de introducir liacuteneas de investigacioacuten futuras
2
2 Cloud Computing
El NIST (National Insitute of Standards and Technology) define este con-cepto como un modelo que permite un acceso ubicuo y bajo demanda de formaremota a un conjunto compartido de recursos de computacioacuten que pueden seraprovisionados y liberados con unos miacutenimos esfuerzos de gestioacuten por parte delproveedor del servicio3
Clasificacioacuten
La computacioacuten en la nube abarca una amplia variedad de servicios y enfo-ques por lo que en primer lugar se va a dar una clasificacioacuten para posterior-mente entrar maacutes en detalle Existen distintos modelos de nube atendiendo a lagobernabilidad de la infraestructura seguacuten el NIST
Nubes puacuteblicas Los servicios y recursos son ofertados de forma puacuteblica yson provistos por una organizacioacuten que los comercializa bajo demanda
Nube privada Los recursos son gestionados por una uacutenica organizacioacutenpara su propio uso
Nube comunitaria En este caso la infraestructura es administrada por unconjunto de organizaciones con objetivos comunes
Nube hiacutebrida Una combinacioacuten de las anteriores
A su vez los distintos servicios que ofrece se pueden clasificar atendiendo algrado de control del usuario
Servicios de software (Software as a Service SaaS) El proveedor se encargade toda la gestioacuten de la infraestructura y oferta aplicaciones a las cuales elcliente puede acceder de forma ubicua a traveacutes de diversos clientes comoun navegador web Por ejemplo Office 365 o Google docs
Servicios de plataforma (Platform as a Service PaaS) Modelo de distribu-cioacuten que ofrece la capacidad de desplegar aplicaciones desarrolladas por elcliente usando las herramientas y lenguajes de programacioacuten soportadaspor el proveedor pero sin la posibilidad de gestionar los recursos consu-midos En este caso el cliente solo tiene control sobre la propia aplicacioacuteny algunas configuraciones del entorno Es el caso de Heroku o Google AppEngine
3httpnvlpubsnistgovnistpubsLegacySPnistspecialpublication800-145pdf
3
Servicios de infraestructura (Infrastructure as a Service IaaS) Se ofertanrecursos de computacioacuten puros como procesamiento o almacenamientomediante una plataforma de virtualizacioacuten El cliente puede controlar elsistema operativo componentes de red y aplicaciones
Figura 1 Comparacioacuten Centro de datos - Computacioacuten en la nubeFuente httpsad-hocnet
De entre las numerosas ventajas que ofrece la computacioacuten en la nube se puededestacar su flexibilidad ya que permite aprovisionar recursos y adaptarlos deacuerdo a la demanda reduce el capital inmovilizado y su amortizacioacuten laubicuidad que permite su consumo desde cualquier parte con conexioacuten a la redy la seguridad y fiabilidad que ofrece el proveedor que normalmente cuenta conrecursos geograacuteficamente distribuidos frente a la gestioacuten y mantenimiento derecursos propios
4
3 Nuevas cargas de trabajo
Las organizaciones que cuentan con sus propios infraestructuras TI han co-menzado a adoptar un enfoque de nube privada para gestionar las tareas ofunciones informaacuteticas sobre las que se sustentan el negocio ya que una es-tructura virtualizada puede ofrecer ventajas con respecto a las adaptaciones decentros de datos tradicionales en los aacutembitos de rendimiento escalabilidad eincluso seguridad4
A su vez se han desarrollado nuevas tecnologiacuteas que suponen cargas detrabajo dinaacutemicas y con gran intensidad de consumo de datos para las empresasque se ven beneficiadas al desplegarlas en recursos virtualizados
Big data
Con la creciente aceptacioacuten de las tecnologiacuteas TIC por parte de la sociedadla cantidad de datos generados en la red es ingente Las profesionales de TI tienecomo objetivo extraer valor de eacutestos para por ejemplo prever las tendencias delmercado Sin embargo este incremento exponencial hace que su procesamientoy almacenamiento requiera de un sistema con gran escalabilidad dado el hechode que una sola maacutequina no puede proveer de la capacidad necesaria
Integracioacuten continua
Modelo informaacutetico que consiste en hacer integraciones automaacuteticas de unproyecto con cualquier cambio en el coacutedigo con el objetivo de detectar fallosde forma temprana Esto implica la compilacioacuten del coacutedigo y su ejecucioacuten enun entorno de pruebas automaacuteticamente un proceso que mediante tecnologiacuteasde virtualizacioacuten permiten simular entornos con eficiencia y rapidez Su imple-mentacioacuten en sistemas distribuidos permite tanto una mejor planificacioacuten comoun mejor rendimiento de los recursos
Arquitectura de microservicios
Enfoque para desarrollar aplicaciones software como un conjunto de serviciosautoacutenomos que se comunican entre siacute a diferencia de aproximaciones monoliacuteti-cas donde la loacutegica del servicio estaacute desarrollada como una unidad Un sistemadistribuido permite el despliegue de los componentes en distintas maacutequinas loque mejora tanto su escalabilidad como la tolerancia a fallos
4httpswwwakamaicomesesresourcespublic-private-cloudjsp
5
Docker
Proyecto de coacutedigo abierto que facilita y automatiza el despliegue de aplica-ciones al encapsular el entorno de trabajo en contenedores Linux una tecnologiacuteaque permite a un sistema fiacutesico ejecutar muacuteltiples instancias de sistemas opera-tivos aislados mediante entornos virtuales con sus propios espacios de procesosy redes pero compartiendo el nuacutecleo (kernel) con el equipo anfitrioacuten
En la figura 2 se compara la pila de una virtualizacioacuten tradicional con res-pecto a los contenedores no se simula el sistema operativo por lo que el procesoes mucho maacutes ligero
Docker se caracteriza por
Autosuficiencia Los contenedores cuentan con las libreriacuteas y configuracio-nes necesarias para ejecutarse de manera autoacutenoma al compartir el nuacutecleo
Portabilidad El hecho de que sean autosuficientes implica que es inde-pendiente del host es decir se puede desplegar en cualquier equipo quesoporte esta tecnologiacutea
Tamantildeo El peso de un contenedor es sustancialmente inferior a otrastecnologiacuteas de virtualizacioacuten
Figura 2 Arquitectura DockerFuente httpsdockercom
6
Los componentes fundamentales de esta herramienta son
Imaacutegenes Describen el entorno de base sobre el que ejecutar el contene-dor por ejemplo la imagen del sistema operativo Ubuntu Sobre eacutesta seconstruyen las aplicaciones particulares del usuario dando lugar a otraimagen
Contenedores Se crean a partir de las imaacutegenes y comprenden todo aquellonecesario para arrancar la aplicacioacuten decir su entorno de ejecucioacuten
bull Voluacutemenes Encargados de gestionar la persistencia de datos e inde-pendientes del ciclo de vida del contenedor
Registros Pueden ser puacuteblicos o privados y almacenan las imaacutegenes elregistro puacuteblico oficial de Docker es Docker Hub
Dadas estas caracteriacutesticas los profesionales TI estaacuten comenzando a adoptarDocker ya que facilita tanto los despliegues como el trabajo compartido en dis-tintos entornos Sin embargo esto requiere de un software que permita desplegarlos distintos contenedores de forma que puedan trabajar en conjunto procesoque se ha denominado orquestacioacuten de contenedores
7
4 Gestioacuten de recursos Planificadores
Para sacar el maacuteximo provecho a las tecnologiacuteas anteriormente descritaslo ideal es desplegarlas en sistemas distribuidos sin embargo esto aumenta lacomplejidad del propio despliegue asiacute como la necesidad de software especiali-zado para ello Se necesitan algoritmos de planificacioacuten que permitan obtener elmaacuteximo rendimiento de los recursos por un lado y dar ciertas garantiacuteas de quetodas las tareas y procesos se van a ejecuta por otro
41 Sistemas distribuidos
En primer lugar se definen los sistemas distribuidos o clusters como unconjunto de ordenadores conectados entre siacute cuyo objetivo es trabajar como unauacutenica instancia de gran capacidad5
Su clasificacioacuten variacutea de acuerdo a cada autor pero en general se puedendividir seguacuten su objetivo en alto rendimiento aquellos cuyo objetivos es proveerde gran capacidad de coacutemputo gracias al conjunto de los nodos y alta disponi-bilidad con los cuales se busca la fiabilidad del sistema mediante redundanciayo balanceo de carga
El intereacutes de este proyecto recae en los uacuteltimos ya que el objetivo es porun lado ofrecer al desarrollador un entorno donde desplegar sus aplicaciones deforma distribuida y por otro maximizar el rendimiento de los recursos
De forma general las caracteriacutesticas que se buscan son las siguientes
Elasticidad Adaptacioacuten a cargas dinaacutemicas de trabajo aumentando (o dis-minuyendo) recursos de manera automaacutetica de tal forma que la utilizacioacutensea lo maacutes cercana a la demanda
Disponibilidad Capacidad de un sistema para mantener el servicio fun-cional
Tolerancia a fallos Recuperacioacuten del servicio ante el fallo de un compo-nente
Balanceo de carga Compartir las tareas entre las diferentes maacutequinasredundadas evitando asiacute puntos de uacutenico fallo
5httpsenwikipediaorgwikiComputer_cluster
8
Los programas que se implementan en entornos distribuidos se caracterizanpor ejecutarse de forma concurrente en equipos independientes estar conectadospor una red que introduce fallos aleatorios y no compartir memoria ni reloj Estoimplica entre otras cosas que
Los nodos soacutelo tienen un acceso raacutepido a su memoria local por lo quecualquier informacioacuten relativa al estado global puede ser potencialmenteerroacutenea
Las maacutequinas pueden sufrir caiacutedas de forma aleatoria
El intercambio de informacioacuten puede fallar ya sea por error en transmisioacuteno por caiacuteda de los nodos
Estas dificultades se ponen de manifiesto en el teorema de CAP en cienciasde la computacioacuten el teorema de CAP que lanzado inicialmente como conjetu-ra en el antildeo 2000 por Eric Brewer (motivo por el cual al teorema se le conoceformalmente como teorema de Brewer) y posteriormente demostrado en el antildeo20026 establece que es imposible para un sistema de coacutemputo distribuido ga-rantizar simultaacuteneamente dos de las tres propiedades siguientes
Consistencia (Consistency) es decir que todos los nodos vean la mismainformacioacuten al mismo tiempo Se busca que un cambio en el sistema soacutelose ejecute satisfactoriamente si y soacutelo si se efectuacutea a todos las maacutequinasde tal forma que los datos entre ellos nunca difieren y la respuesta a unapeticioacuten sea la misma independientemente del nodo que la atienda
Disponibilidad (Availability) esto es la garantiacutea de que toda peticioacuten debeobtener una respuesta (servicio funcional) aunque exista inconsistenciaentre nodos
Tolerancia al particionado (Partition Tolerance) es decir que el sistemasiga funcionado a pesar de un fallo en la comunicacioacuten entre los equipos
Por todo lo expresado anteriormente conseguir un sistema distribuido capazde ofrecer procesamiento de forma transparente implica una arquitectura TIcompleja Se requieren de subsistemas y herramientas que permitan la cohesioacutenentre todos los nodos
Gestor de los recursos de las diferentes maacutequinas
Monitorizacioacuten tanto de los servicios activos como de la funcionalidad delsistema ademaacutes de poliacuteticas para recuperacioacuten de fallo
Protocolos de consenso que permitan a los nodos ser consistentes con elestado global del cluster
6urlhttpsgroupscsailmitedutdspapersGilbertBrewer2pdf
9
Herramientas de descubrimiento de servicios que permita la comunicacioacutenentre tareas distribuidas
Planificadores Encargados de distribuir las tareas y procesos en las dife-rentes maacutequinas asignaacutendole parte de su capacidad
Los planificadores del ingleacutes cluster schedulers son un componente funda-mental por lo que vamos a entrar un poco maacutes en detalle en ellos
Planificadores (Cluster Schedulers)
Es el software encargado de monitorizar los recursos usados por cada maacute-quina perteneciente a un cluster y distribuir la carga de trabajo entre ellas deacuerdo a un poliacutetica o reglas
Este tipo de herramientas comparten cierta terminologiacutea que es relevantedefinir
Tarea Unidad de trabajo computacional comprendida por una secuenciade instrucciones datos de entrada y recursos asociados Por ejemplo laejecucioacuten de un comando o el arranque de una base de datos
Nodo Cualquier maacutequina integrante de un cluster En una arquitecturamaestro-esclavo se definen dos roles
bull Cliente Agente Esclavo Aquellos ordenadores que se encargan deejecutar las tareas
bull Maestro Servidor Su objetivo es mantener el estado del cluster ygestionar sus recursos
411 Clasificacioacuten
A lo largo de los uacuteltimos antildeos se han desarrollado diferentes tipos de plani-ficadores[2]
Monoliacutetico
Un solo planificador que se encarga de distribuir todas las tareas entran-tes La mayoriacutea de los planificadores en computacioacuten de alto rendimiento asiacutecomo Borg desarrollado por Google son de este tipo En la figura 3 se pue-de observar de forma graacutefica el procedimiento siendo las cajas grises maacutequinaspertenecientes al cluster y los ciacuterculos las tareas a asignar
10
Figura 3 Planificador monoliacuteticoFuente httpswwwclcamacuk
Planificacioacuten de dos niveles
La mayoriacutea de los clusters ejecutan aplicaciones con distintas necesidadesdesde procesos casi instantaacuteneos hasta servicios persistenteslo que implica dis-tintas necesidades de recursos
Por ello la planificacioacuten a dos niveles distingue dos funciones la gestioacutende recursos (gestor) y la disposicioacuten de las tareas (planificador) Cada serviciotiene su propio planificador de tal manera que el gestor les ldquoofertardquo recursosde acuerdo a una poliacutetica y los planificadores se encargan de escoger la maacutesadecuada Esto permite que el proceso de distribucioacuten sea maacutes acorde con lasnecesidades de los diferentes servicios Apache Mesos que detallaremos maacutesadelante sigue este esquema
Como desventaja cabriacutea sentildealar que esta programacioacuten implica que los pla-nificadores pierden la vista general de la infraestructura y las tareas soacutelo puedenejecutarse con los recursos que les son ofrecidos lo que dificulta la implementa-cioacuten de prioridades de ejecucioacuten de tareas entre otras
Figura 4 Planificador de dos niveles
11
Planificacioacuten de estado compartido
Muacuteltiples reacuteplicas del estado del cluster se actualizan independientementepara cada planificador como se observa en la figura 5 cuando sucede un cambiode forma local el planificador se encarga de informar al resto
Ejemplo de este tipo son Omega la evolucioacuten de Borg por parte de GoogleMicrosoft Apollo y Nomad que usaremos para los casos de uso
De entre las desventajas se puede destacar el hecho de que en general losnodos trabajan con informacioacuten desactualizada lo que conlleva una degradacioacutendel rendimiento en situaciones de alta contienda
Figura 5 Planificador de estado compartido
Planificacioacuten distribuida
En este caso no existe coordinacioacuten entre los distintos planificadores Cadauno de ellos funciona con su propia vista del cluster Las tareas pueden serorganizadas por cualquiera de ellos y desplegadas en cualquier parte del clusteren base a la aleatoriedad y multiplexacioacuten estadiacutestica de los flujos de trabajosin ninguacuten control central
Figura 6 Planificador distribuido
12
5 Herramientas
En la industria comienzan a aparecer soluciones software de coacutedigo abiertoque aglutinan los servicios necesarios para gestionar la infraestructura TI de ma-nera maacutes eficaz El objetivo es doble se busca facilitar la gestioacuten de los recursosde computacioacuten para organizaciones con instalaciones propias mediante su usocon un enfoque cloud esto es desplegar aplicaciones a traveacutes de un conjuntode ordenadores de forma transparente y sin tener en cuenta la infraestructurasubyacente o aprovechar el maacuteximo rendimiento de la infraestructura de losproveedores cloud puacuteblicos de forma que se tiene el maacuteximo control sobre eacutestapero no se depende de las soluciones propietarias permitiendo asiacute despliegueshiacutebridos
Entre estas herramientas se pueden destacar
OpenStack Proyecto desarrollado por la fundacioacuten del mismo nombre paraproporcionar servicios de infraestructuras (IaaS) basado en componentesque se comunican a traveacutes de APIs El componente Magnum incluye mo-tores de orquestacioacuten de contenedores
Kubernetes Sistema de orquestacioacuten de contenedores Docker creado por Goo-gle
CoreOs Sistema operativo basado en Linux disentildeado para despliegues distri-buidos sobre contenedores incluyendo mecanismos de descubrimiento deservicio y comparticioacuten de configuracioacuten
Docker Swarm Herramienta nativa de orquestacioacuten de contenedores Docker
YARN Entorno de gestioacuten de recursos y aplicaciones distribuidas de Hadoopuna libreriacutea software de procesamiento de grandes conjuntos de datos
Como podemos observar existe un gran rango de opciones para gestionar lainfraestructura desde un bajo nivel como puede ser OpenStack hasta Kuberne-tes o Docker Swarm que ofrecen exclusivamente orquestacioacuten de contenedores
En este trabajo se ha optado por Mesosphere DCOS y HashiCorp Nomadque se encuentran en el teacutermino medio su objetivo es proporcionar serviciosde plataforma que permitan la coexistencia dediferentes cargas de trabajo en elcluster
13
51 DCOS
DCOS es un proyecto de coacutedigo abierto7 creado y desarrollado por la empre-sa Mesosphere Se describe como un sistema operativo distribuido que abstraelos recursos de un cluster (capacidad de procesamiento memoria) permite lagestioacuten de muacuteltiples ordenadores de forma transparente y simplifica la instala-cioacuten de aplicaciones distribuidas
Su arquitectura se puede comparar a la de Linux en teacuterminos de nuacutecleo(kernel) y espacio de usuario El primero consta de recursos protegidos a losque no puede acceder el usuario e involucra operaciones de bajo nivel comoasignacioacuten de recursos o aislamiento de procesos En el espacio de usuario seejecutan las aplicaciones y servicios de maacutes alto nivel
Siguiendo con este siacutemil el nuacutecleo de DCOS estaacute basado en Apache Mesosque se explicaraacute en un apartado posterior y el espacio de usuario que estaacute com-prendido por los componentes del sistema esto es las diferentes herramientasque en conjunto conforman DCOS y los servicios encargados de planificar yejecutar las aplicaciones y tareas del usuario
Figura 7 Arquitectura DCOSFuente httpsdcosio
De entre los componentes que conforman DCOS destacan
Admin Router Balanceador de carga central basado en NGINX que dis-pone un proxy entre todos los servicios en el puerto 80 permitiendo sugestioacuten mediante la interfaz graacutefica Ademaacutes se encarga de la autenticacioacutenpara acceder al panel de administracioacuten
Cosmos Gestor de paquetes de las aplicaciones
Diagnostics Se ejecuta en todos los nodos y se encarga de monitorizar elestado de los daemons que sustentan DCOS
7Desde abril de 2016 httpsmesospherecomblog20160419open-source-dcos
14
Exhibitor Gestiona y automatiza el despliegue de ZooKeper la herra-mienta que provee de configuracioacuten centralizada y registro de nombres
Marathon Equivale al proceso init de los sistemas tipo Unix esto es elprimer proceso en ejecucioacuten tras la carga del kernel y que genera los demaacutesprocesos Se encarga de arrancar y monitorizar las aplicaciones y servicios
Mesos-DNS Servicio de DNS interno que define el dominio mesos pa-ra nodos y tareas en el cluster es decir permite resolver nombres conindependencia de la direccioacuten fiacutesica
Minuteman Balanceador de carga integrado a nivel TCPUDP disponiblepara las propias aplicaciones
Por otra parte se definen como servicios a las diferentes aplicaciones dis-tribuidas que DCOS permite instalar en el cluster y que pueden haber sidodesarrollados por la misma empresa Mesosphere o por terceros por ejemploApache Spark Jenkins o Apache Hadoop En la figura 8 se muestra un diagramade los servicios disponibles incluyendo algunos de las aplicaciones distribuidasque soporta DCOS
Figura 8 Servicios DCOSFuente httpsdcosio
511 Apache Mesos
El nuacutecleo de DCOS estaacute basado en Apache Mesos un proyecto de coacutedigoabierto creado por la Universidad de California Berkeley y desarrollado actual-mente por la fundacioacuten Apache Se trata de un administrador de clusters queabstrae los recursos y los dispone para diferentes aplicaciones y entornos de tra-bajo distribuidos (frameworks) mediante una interfaz comuacuten En el momento deredaccioacuten de este proyecto Apache Mesos soportaba una variedad de entornosque abarcaba desde Big Data (Apache Spark Hadoop) hasta bases de datos(Cassandra Hypertable)
15
Arquitectura
Mesos se basa en la asignacioacuten de dos roles diferentes a los nodos
Maestros (Masters) Se encargan de la gestioacuten y reparticioacuten de los recursospara los diferentes entornos de trabajo mediante ldquoofertas de recursosrdquo deacuerdo a los disponibles y a la poliacutetica de asignacioacuten (planificacioacuten en dosniveles)
Esclavos (Slaves) Ordenadores donde se ejecutaraacuten las aplicaciones y cu-yos recursos son ofertados por los maestros
En el caso de fallo del maestro las tareas pueden seguir ejecutaacutendose perono se podraacute asignar nuevos recursos ni tareas por ello pueden existir varios enel cluster para configuraciones de alta disponibilidad pero soacutelo uno orquesta alos esclavos
Para la eleccioacuten del master liacuteder Mesos usa Apache ZooKeeper un proyectode software desarrollado por la misma fundacioacuten cuyo objetivo es proveer deun servicio de configuracioacuten centralizado y registro de nombres8
Por otra parte los entornos de trabajo son los programas que deciden final-mente queacute recursos se van a usar y se encargan de que los esclavos ejecuten lastareas Eacutestos se ejecutan sobre Mesos y constan de dos componentes
Planificador (Scheduler) Optimiza y decide los recursos a utilizar de losofertados informando a los Masters
Procesador (Executor) Ejecuta las aplicaciones o servicios en los esclavos
El objetivo final es conseguir una interfaz liviana tolerante a fallos paracualquier tipo de entorno de trabajo de tal manera que en los esclavos del clusterpuedan ejecutarse simultaacuteneamente tareas con necesidades y duracioacuten diferentesPara ello se basa en dos conceptos asignacioacuten y aislamiento de recursos
Asignacioacuten de recursos
En el cluster pueden coexistir entornos de trabajo con tareas de larga dura-cioacuten y con gran consumo de recursos con tareas cortas que los ocupan y liberancon rapidez El maestro integra un moacutedulo de asignacioacuten de recursos (allocationmodule) que se encarga del algoritmo de distribucioacuten
En el momento de escribir este proyecto estaban desarrollados dos moacutedulosuno mediante el cual el usuario puede asignar prioridades y otro que implementa
8httpszookeeperapacheorg
16
el algoritmo Dominant Resource Fairness9 a grandes rasgos se determina entodos los esclavos la tarea en ejecucioacuten que necesita maacutes recursos y se calcula laproporcioacuten del recurso de mayor peso con respecto al total por ejemplo si unatarea ocupa 2 GB de memoria con respecto a 10 GB totales que tiene el clusterse le asigna un dominant share del 20 la tarea se asignaraacute al nodo con menordominant share
Aislamiento de recursos
Para conseguir que tareas de diferentes entornos de trabajo y con distin-ta naturaleza se ejecuten simultaacuteneamente en un mismo nodo Mesos usa loscontenedores Linux (descritos en la seccioacuten 3)
Funcionamiento
La figura 9 muestra el esquema de la arquitectura de Apache Mesos conalta disponibilidad (tres maestros) y con dos entornos de trabajo ejecutaacutendo-se Hadoop que permite el almacenamiento y procesamiento de gran cantidadde datos para proyectos de big data y un sistema que implementa la interfazsistema de paso de mensajes MPI
Como se puede observar el sistema ZooKeeper elige a un solo maestro comoliacuteder y eacuteste orquesta el cluster comunicando los esclavos con los planificadoresde los diferentes entornos de trabajo Tambieacuten se puede observar como las tareasde los distintos entornos estaacuten distribuidas entre los tres esclavos disponibles
Figura 9 Arquitectura de Apache MesosFuente httpsmesosapacheorg
El proceso de asignacioacuten se realiza como sigue en primer lugar un usuariosolicita la ejecucioacuten de una tarea mediante la interfaz de cada entorno de traba-jo (interfaz graacutefica API HTTP ) De forma paralela un esclavo informa almaestro de los recursos que tiene libres En consecuencia eacuteste se lo notifica almoacutedulo de asignacioacuten que en funcioacuten de su configuracioacuten decide cuaacutento ofertar
9httpspeopleeecsberkeleyedu~aligpapersdrfpdf
17
y a queacute entorno de trabajo y enviacutea la oferta a los planificadores Eacutestos respondenal maestro con queacute recursos ha decidido usar para cada tarea Finalmente lastareas son enviadas al esclavo seleccionado el cual asigna los recursos indicadosal procesador (executor) quien finalmente las ejecuta
Cabriacutea pensar que esta metodologiacutea puede conducir a situaciones en lasque un entorno podriacutea quedarse con tareas sin ejecutarse a la espera de unaoferta satisfactoria para ello Mesos implementa un sistema de filtros medianteel cual los entornos especifican los requisitos miacutenimos que debe cumplir unaoferta por ejemplo se puede especificar en queacute nodos debe desplegarse la tareaEste sistema estaacute disentildeado asiacute con el objetivo de mantener lo maacutes transparenteposible esta herramientas de forma que acepte entornos de trabajo de distintasnaturalezas
512 Ejemplos de uso
Grandes empresas estaacuten usando Apache Mesos con eficacia de acuerdo a susnecesidades e infraestructuras Caben destacar
Ebay En el modelo de implementacioacuten continua en esta empresa10 cadadesarrollador cuenta con su propia instancia que se ejecuta en una maacutequinavirtual dedicada lo que ha conllevado un uso de los recursos poco eficiente Enuna prueba de concepto consiguieron realizar una herramienta de integracioacutencontinua distribuida basada en un cluster con Apache mesos y con el entornoMarathon y Jenkins
Apple Anuncioacute que el motor de su famosa herramienta de asistencia per-sonal para iPhones Siri estaacute desplegada sobre Apache Mesos11 Para ello handesarrollado su propio entorno para facilitar a los ingenieros a desplegar los ser-vicios que la herramienta necesita para resolver las peticiones de los usuarios
Twitter Desarrolloacute su propio entorno denominado Aurora y actualmentegestionan sus recursos y miden el coste de las tareas que los empleados usancon el objetivo de que sean conscientes del gasto que puede suponer un usoinadecuado de la infraestructura12
10httpwwwebaytechblogcom20140404delivering-ebays-ci-solution-with-apache-mesos-part-i11httpwwwbusinessinsidercomapple-siri-uses-apache-mesos-2015-812httpswwwlinuxcomNEWS4-UNIQUE-WAYS-UBER-TWITTER-PAYPAL-AND-HUBSPOT-USE-APACHE-MESOS
18
52 Nomad
Herramienta de coacutedigo abierto de gestioacuten de clusters creada y desarrolladapor Hashicorp13 que permite el despliegue de aplicaciones y procesos de formadistribuida
Las principales diferencias con Apache Mesos a grandes rasgos son
Arquitectura maacutes ligera Nomad soacutelo requiere de un fichero para funcionarejecutaacutendolo con las correspondientes configuraciones en todos los nodosrealiza las funciones de gestioacuten del cluster eleccioacuten de liacuteder planificacioacutende recursos y ejecucioacuten de las tareas
Centro de datos y regiones muacuteltiples Su arquitectura estaacute orientada afacilitar la gestioacuten de diferentes centros de datos geograacuteficamente distri-buidos
Entorno de ejecucioacuten Las tareas se definen y son interpretadas mediantecontroladores integrados en Nomad que se valen de los recursos y herra-mientas de los nodos clientes para ejecutarlas Esta integracioacuten dificultael desarrollo de controladores por parte de terceros a diferencia de Mesosque delega dicha responsabilidad en los entornos de trabajo externos alproyecto
Usa un planificador de estado compartido con respecto a la planificacioacutenen dos niveles de Mesos
Antes de entrar en maacutes detalle en la arquitectura es importante definir lossiguientes teacuterminos
Controlador (Driver) Software que se encarga de interpretar las definicionesde las tareas y ejecutarlas semejante a los procesadores de los entornosde trabajo de Mesos A la hora de redactar este proyecto Nomad contabacon controladores para contenedores Docker virtualizacioacuten de maacutequinasmediante el emulador QEMU aplicaciones java y archivos binarios
Grupo de trabajo (Task Group) Conjunto de tareas que se ejecutan en elmismo nodo cliente
Trabajo (Job) Conjunto loacutegico de tareas y grupos de trabajo que se despliegana la vez
Asignacioacuten (Allocation) Relacioacuten entre un grupo de trabajo y el cliente don-de se ejecuta
Evaluacioacuten (Evaluation) Proceso mediante el cual Nomad planifica y ges-tiona el registro o actualizaciones de los trabajos
13httpswwwhashicorpcom
19
Nomad sigue una arquitectura maestro-esclavo similar a la de Apache Mesosmuacuteltiples servidores acuerdan entre siacute un liacuteder que gestiona la planificacioacuten detareas en los clientes que soacutelo conocen sus asignaciones y las ejecutan
Todos los servidores participan paralelamente en tareas de planificacioacuten derecursos y asignacioacuten de tareas y ademaacutes entre ellos eligen un liacuteder que seencarga de la coordinacioacuten de la suscripcioacuten de los clientes al cluster y de lagestioacuten de las peticiones
Los clientes estaacuten configurados para comunicarse con el servidor usando lla-madas a procedimiento remoto (RPC por sus siglas en ingleacutes) que permite unordenador ejecutar coacutedigo en otra maacutequina Mediante esta tecnologiacutea los nodosclientes avisan de su estado e informa de sus asignaciones recursos y controla-dores disponibles
Existe la posibilidad de gestionar varios centros de datos agrupados en regio-nes eacutestas son independientes pero permite definir tareas o comprobar el estadode todas ellas desde cualquier punto A continuacioacuten se muestra una figura dela arquitectura a alto nivel de esta configuracioacuten
Figura 10 Arquitectura multi-regioacuten en NomadFuente httpswwwnomadprojectio
La herramienta se sustenta sobre tres protocolos fundamentales un protocolode consenso entre los servidores para compartir informacioacuten sobre su estado yel liacuteder un protocolo Gossip para la gestioacuten entre regiones y el planificador detareas
521 Protocolo de consenso Raft
El objetivo es obtener consistencia en un conjunto de nodos que comparteninformacioacuten es decir si un cliente realiza un cambio que todos los nodos veanla misma informacioacuten a la vez y ademaacutes sea tolerante a fallos Para ello se basaen el algoritmo Raft[13] que se detalla brevemente a continuacioacuten
20
Los nodos participantes en el algoritmo pueden estar en tres estados
Liacuteder (Leader) Todos los cambios que realicen en el cluster pasan por eacutel pri-mero
Seguidor (Follower) Nodo pasivo cuya responsabilidad es responder a laspeticiones del nodo liacuteder
Candidato (Candidate) Maacutequina que no ha encontrado liacuteder y solicita sueleccioacuten
Supongamos que tenemos cinco equipos que acaban de arrancar el protocoloEn la figura 11 se observan los nodos y sus respectivos registros a la derecha
Figura 11 Equipos sin consenso ejecutando el protocolo RAFTFuente httpsgithubcomongardieraftscope
Al comenzar todos los nodos son seguidores esperando recibir comunicacioacutende un nodo que actuacutee como liacuteder Cada nodo tiene un tiempo de espera aleatoriodespueacutes del cual si no es informado por un liacuteder pasa a estado candidato y pideel ldquovotordquo al resto de los participantes El algoritmo divide el tiempo en plazos uncandidato pasa a liacuteder si recibe la mayoriacutea de los votos en un plazo determinadoSe define mayoriacutea o cuoacuterum (quorum) comolceil
N2rceil
+ 1 (1)
donde N representa el nuacutemero de nodos
Para el ejemplo propuesto de 5 equipos se requieren de 3 votos Soacutelo losnodos que se encuentren en estado seguidor pueden votar una uacutenica vez a laprimera solicitud que reciba dentro de un plazo
Supoacutengase que el nodo denotado con S1 ha cumplido su tiempo de espera yrealiza la peticioacuten de voto (figura 12) A partir de este momento se pueden dartres casos
La maacutequina gana la eleccioacuten y pasa a ser liacuteder informando al resto
Otro servidor se establece como liacuteder en el mismo momento
Varios nodos pasan a ser candidatos por lo que ninguno consigue los votos
21
Figura 12 Un equipo pasa a estado candidato (RAFT)
Si un candidato recibe un aviso de un liacuteder en el mismo plazo el primeropasa a ser seguidor y se acaba la eleccioacuten de liacuteder
Por otro lado si un equipo candidato no recibe los votos en el plazo y agotasu tiempo de espera avanza al siguiente plazo y repite el proceso de votacioacutenLa tercera posibilidad puede conllevar a un estado indefinido ya que varioscandidatos pueden agotar su tiempo de espera al mismo tiempo y repartir losvotos Para solventarlo el algoritmo establece tiempos de espera aleatorios paralos candidatos
Siguiendo con el ejemplo propuesto el servidor S1 pasa a ser el liacuteder Cadacierto tiempo eacuteste debe realizar avisos a los nodos seguidores para no agotar sutiempo de espera
En este momento el cluster de servidores estaacute en ldquoconsensordquo y la informacioacutenen todos los nodos estaacute actualizada Un cambio en la informacioacuten inicia unproceso de replicacioacuten el liacuteder registra el cambio lo pasa al resto de nodos yuna vez eacutestos responden el cambio se hace efectivo
Supoacutengase que se realiza un cambio en los datos en la figura 13 en la partederecha se observa el cambio en el registro del servidor S1 que informa a losnodos seguidores En consecuencia los nodos registran el cambio y responden aS1
Figura 13 Cambio en un registro (RAFT)
Una vez el cuoacuterum (en el ejemplo tres equipos) informa al liacuteder de que
22
ha registrado el cambio el liacuteder lo hace efectivo en su sistema y notifica a losnodos que hacen lo mismo En la figura 14 el enviacuteo todaviacutea no ha llegado ala maacutequina S3 y se observa que no ha hecho efectivo el cambio (en el registroaparece punteado)
Figura 14 Aprobacioacuten del resto de equipos (RAFT)
Este protocolo funcionaraacute correctamente mientras exista un nuacutemero de nodosen funcionamiento igual o superior al cuoacuterum en el ejemplo propuesto elcuoacuterum es tres por lo que el sistema puede tolerar la caiacuteda de dos de los equipos
522 Protocolo gossip SWIM
Nomad permite la gestioacuten simultaacutenea de varios centros de datos reparti-dos en regiones geograacuteficamente separadas requiriendo de un protocolo ligeroque mantenga a los miembros actualizados sobre los participantes del conjun-to Para ello usa una ligera variante del protocolo SWIM[3] (Scalable Weakly-consistent Infection-style Process Group Membership Protocol) desarrollada porHashiCorp Estaacute clasificado como un protocolo de tipo gossip que debe su nom-bre a la semejanza con coacutemo se distribuye un rumor en una red social
SWIM se sustenta en dos caracteriacutesticas fundamentales la deteccioacuten de fallosy la distribucioacuten de la informacioacuten relativa a los miembros A continuacioacuten sedetalla el funcionamiento de ambos componentes
Deteccioacuten de fallos
Este componente tiene dos paraacutemetros el periodo de protocolo T y el nuacutemerode subgrupos de deteccioacuten de fallos k en los que se dividen los nodos Paracomprobar la comunicacioacuten entre dos maacutequinas usa la utilidad ping basadaen el protocolo ICMP La deteccioacuten de caiacuteda de un servidor sigue el siguientealgoritmo
Durante el periodo T cada miembro Mi de un subgrupo elige otro al azar Mjdel mismo subgrupo y le enviacutea un mensaje ping para comprobar su estado Enel caso de que se cumpla un tiempo de espera determinado por una estimacioacuten
23
del tiempo de ida y vuelta (RTT por sus siglas en ingleacutes) de la red y no hayarespuesta Mi le vuelve a enviar un mensaje ping indirectamente a traveacutes deun nuacutemero k de miembros escogidos aleatoriamente De no recibir ninguna res-puesta Mi establece que Mj ha sufrido un fallo y lo etiqueta como ldquosospechosordquoinformando al componente de distribucioacuten
Figura 15 Diagrama de tiempo del protocolo SWIMFuente httpswwwcscornelledu
Componente de distribucioacuten
Se encarga de informar de cualquier cambio en los miembros a todo el con-junto Los eventos de nodo caiacutedo y la unioacuten o disociacioacuten de un miembro setransmiten a todos los servidores para que actualicen sus lista Para distribuirla informacioacuten a todos los nodos se podriacutea usar el meacutetodo de multicast perosuele estar deshabilitado Por ello se utiliza una teacutecnica de transmisioacuten denomi-nada Piggybacking mediante la cual se adjunta a los propios mensajes PINGy ACK del algoritmo la informacioacuten a distribuir reduciendo asiacute la congestioacutenen la red
523 Planificacioacuten
Proceso encargado de distribuir las tareas entre los nodos clientes de acuerdoa su estado
El planificador de Nomad estaacute basado en las publicaciones de Google sobresus herramientas de gestioacuten de clusters Borg y Omega14 y entiende los trabajosdescritos por el usuario como un estado deseado es decir su despliegue en unamaacutequina cliente de forma correcta y los clientes como el estado actual esto eslo que se encuentra en ejecucioacuten El registro actualizacioacuten o cancelacioacuten de un
14httpresearchgooglecompubspub43438html
24
trabajo asiacute como el fallo de un nodo cliente implican un cambio de estado atramitar por el sistema lo que se define como evaluacioacuten (evaluation) Esto uacutelti-mo supone comparar el estado actual (clientes) con el estado deseado (conjuntode trabajos registrados) y enviarlos a los planificadores correspondientes que seencargaraacuten de asignar las tareas a los nodos clientes
Figura 16 Procedimiento de asignacioacuten en NomadFuente httpswwwnomadprojectio
En la figura 16 se observa el flujo de trabajo en el que las distintas evalua-ciones se encolan en el evaluation broker que se ejecuta en el servidor liacuteder ygestiona las evaluaciones pendientes asignaacutendoles prioridades
A continuacioacuten los nodos servidores ejecutan los scheduling workers queprocesan las evaluaciones llamando a los distintos planificadores que generanun plan de asignacioacuten esto es un conjunto de relaciones entre las tareas y losnodos clientes donde se ejecutaraacuten Este proceso se divide en dos fases primerose descartan aquellos clientes que no cumplan los requisitos y posteriormentese asigna una calificacioacuten al resto Se selecciona el nodo con mayor puntuacioacuteny se encola el plan en el gestor que se ejecuta en el servidor liacuteder Existen tresplanificadores de acuerdo al tipo de trabajo
Service Incluye aquellos trabajos que estaacuten destinados a ejecutarse en un pe-riacuteodo largo de tiempo Para realizar las asignaciones el planificador evaluacuteala mayor parte de los nodos y usa una versioacuten del algoritmo Best fit in-fluenciada por el trabajo de Google en su herramienta Borg Se trata deun algoritmo de planificacioacuten que sacrifica tiempo a cambio de maximizarel rendimiento de los clientes asignando la tarea a la maacutequina que tengala mayor carga de trabajo con el objetivo de reducir equipos en funciona-
25
miento
Batch Tareas que incluyen listas de comandos en general de menor duracioacuteny que no requieren interaccioacuten con el usuario Se vale del algoritmo deSparrow desarrollado por la universidad de Berkeley15 para limitar losnodos clientes a evaluar
System Trabajos destinados a ejecutarse en todos los nodos incluso los que seunen al cluster posteriormente
Core Mantenimiento interno de Nomad
Una vez se ha realizado el proceso de planificacioacuten el nodo liacuteder lo registra enla cola de planes (plan queue) que se encarga de asignarles prioridad y manejarcondiciones de carrera es decir que no accedan a los recursos de los clientes sincontrol y evitar que eacutestos superen su capacidad
La maacutequina liacuteder del conjunto puede de este modo aceptar una asignacioacuteny ser ejecutada por los clientes o por el contrario rechazaacutersela al planificadorlo que implicariacutea realizar un plan parcial o totalmente nuevo
Finalmente el estado de las evaluaciones se actualizan y los clientes soninformados de las asignaciones ejecutaacutendose las tareas
15httppeopleeecsberkeleyedu~keopublicationssosp13-final17pdf
26
6 Casos de uso y despliegue
Con el objetivo de mostrar las posibles utilidades que este tipo de sistemaspueden tener en las infraestructuras TI actuales se han desplegado las dos he-rramientas en la nube Microsoft Azure usando su servicio cloud de instancias demaacutequinas virtuales Linux para simular un conjunto de ordenadores conectadosentre siacute por una red LAN Sobre ellas se ha implementado dos casos de usouna aplicacioacuten web con una arquitectura con cierta orientacioacuten a microserviciosy un sistema de integracioacuten continua
El coacutedigo y todos los ficheros de configuracioacuten se pueden encontrar en elrepositorio del proyecto en GitHub16
61 Aplicacioacuten Web
Se busca simular el proceso de adaptacioacuten de una solucioacuten web para su des-pliegue en un sistema distribuido con las herramientas anteriormente descritascon el objetivo de aumentar tanto su escalabilidad como disponibilidad medianteredundancia
Se ha partido de una aplicacioacuten ya existente17 un servicio de almacenamien-to y reproduccioacuten de canciones A grandes rasgos este servicio permite crearusuarios subir canciones con sus respectivas portadas tener playlists propias yescuchar las canciones a traveacutes de un navegador web
La solucioacuten estaacute dividida en 4 partes (figura 17)
Una vista web con la loacutegica
Un almacenamiento conectado en red (NAS por sus siglas en ingleacutes)
Una API REST para gestionar las peticiones al almacenamiento
Base de datos NoSQL basada en MongoDB
La nueva tendencia de los proyectos web es su implementacioacuten en contene-dores Docker ya que facilitan su portabilidad y ofrecen un procedimiento dedespliegue raacutepido sobre todo a la hora de desarrollar y realizar pruebas en en-tornos de produccioacuten simulados Por ello en este caso se va a hacer uso de los
16httpsgithubcomAntonioAlfrzCloud-Orchestrators17httpsgithubcomsonsoleslpCDPSfy
27
motores de orquestacioacuten de contenedores de ambas herramientas Marathon enDCOS y el controlador Docker en el caso de Nomad
Figura 17 Arquitectura aplicacioacuten web
A continuacioacuten vamos detallar el despliegue en ambas herramientas de es-ta solucioacuten y observar tanto queacute dificultades se encuentran como que ventajasofrecen El objetivo final es adaptar el proyecto modificaacutendolo lo menos posiblecon objeto de analizar la capacidad de estas herramientas para desplegar cual-quier aplicacioacuten sin que eso conlleve la modificacioacuten de la arquitectura de eacutestaes decir que no sea dependiente del entorno
611 DCOS
Se ha descrito DCOS como una herramienta que se despliega sobre un con-junto de ordenadores y que permite instalar gestionar el despliegue de sistemasdistribuidos
Microsoft Azure cuenta con una plantilla para desplegar en su servicio cloudun cluster de maacutequinas virtuales con DCOS ya instalado que cuenta con
Maacutequinas maestras (1 3 o 5 a seleccionar por el usuario) configuradascomo un conjunto de disponibilidad esto eso Azure da ciertas garantiacuteasde que al menos una maacutequina estaraacute en funcionamiento
Maacutequinas agentes Por motivos de seguridad se distinguen dos roles
bull Nodos privados solo accesibles desde la red interna y configuradoscomo un conjunto de escala un recurso de Azure para gestionar ydesplegar maacutequinas con configuraciones ideacutenticas para permitir unraacutepido escalado
bull Un equipo conectado accesible desde Internet a travntildees de un balan-ceador de carga puacuteblico y situado en una subred externa
28
Dos balanceadores de carga
bull La interfaz puacuteblica del cluster que se conecta con el cliente puacuteblicobull Acceso a los equipos maestros para el administrador que soacutelo permiteconexioacuten mediante SSH y credenciales
Almacenamiento para todas las maacutequinas
Configuraciones necesarias de red y seguridad
En la figura 18 se observa un diagrama de la infraestructura
Figura 18 Infraestructura en Azure
El primer obstaacuteculo es la persistencia de estado de la aplicacioacuten que seconsigue gracias a una base de datos no relacional basada en MongoDB asiacutecomo el almacenamiento de las canciones Para implementarla tenemos variasposibilidades
Montar un sistema externo de almacenamiento conectado en red en todoslos agentes donde se ejecuten las tareas de esta manera si una tarea pasade un nodo a otro por cualquier motivo puede tener acceso a los mismosficheros (opcioacuten del caso de uso original)
Implementar un sistema de ficheros distribuidos en los agentes
Usar los servicios de almacenamiento de las nubes puacuteblicas
Aprovechar el sistema de voluacutemenes persistentes de Apache Mesos Eacutestepermite reservar recursos de un agente de forma que al arrancar una tarease crea un volumen independiente del ciclo de vida de eacutesta con ello esosrecursos donde se ha almacenado la informacioacuten pueden volver a ofrecerseal mismo entorno de tal manera que otra tarea pueda acceder a ella
DCOS aprovecha este sistema de voluacutemenes persistentes y permite instalarbases de datos distribuidas como ArangoDB o Apache Cassandra sin embargoesto implicariacutea modificar todo el coacutedigo referente al modelo de la base de datos
29
Por motivos de eficiencia y latencia asiacute como de una mayor gobernabilidadde los datos la mejor opcioacuten es usar el recurso de voluacutemenes persistentes queofrece Apache Mesos ya que de esta manera se gestionariacutea la aplicacioacuten completamediante una uacutenica herramienta Sin embargo esto implica que la informacioacutense encuentra exclusivamente en el agente donde se haya ejecutado la tarea y porlo tanto se sigue requiriendo de software externo para distribuir la informacioacutenpara que se accesible para todos los agentes A la hora de realizar este proyectose encontraba en desarrollo Flocker una solucioacuten desarrollada por ClusterHQque permite compartir los voluacutemenes de Docker a traveacutes de un cluster quesi bien es compatible con el planificador de Mesos el proyecto se encontrabatodaviacutea en fases tempranas de desarrollo y los sistemas de almacenamiento quesoporta quedaban fuera del aacutembito de este trabajo
Por todo ello dado que las maacutequinas se han desplegado en la nube puacuteblicade Azure se decidioacute usar su servicio de almacenamiento de objetos para lascanciones y otra maacutequina para desplegar MongoDB y asiacute mantener el modelode datos original de la aplicacioacuten La diferencia del almacenamiento de obje-tos con respecto a nivel de fichero es que el primero no tiene jerarquiacutea paraorganizar los archivos eacutestos se guardan como objetos (con sus metadatos) enun mismo espacio soacutelo diferenciaacutendose por un identificador uacutenico esto implicaentre otras cosas que se puede acceder a un fichero dado uacutenicamente su IDindependientemente de la localizacioacuten fiacutesica de eacuteste facilitando pues la gestioacuteny el desarrollo
El coacutedigo del proyecto se ha modificado en los siguientes apartados
Las direcciones de la base de datos y los balanceadores de carga asiacute comosus puertos estaban originalmente fijos Se han configurado como variablesde entorno para facilitar el descubrimiento del servicio y hacer transpa-rente la aplicacioacuten al entorno de despliegue
La API REST se ha adaptado al almacenamiento en Azure en vez de enlocal
Estas modificaciones no suponen un cambio sustancial pero permiten separala persistencia de las tareas ejecutadas por DCOS lo que facilita en granmedida su ejecucioacuten al ser totalmente sin estado y ademaacutes implican tenerlos datos bajo un mayor control
Para la orquestacioacuten de contenedores se va a usar el entorno Marathondesarrollado tambieacuten por Mesosphere Eacuteste se puede usar a traveacutes de una interfazgraacutefica la interfaz de liacutenea de comandos (en lo que sigue CLI por sus siglas eningleacutes) de DCOS o con su API HTTP
Primero se han publicado la imaacutegenes de los contenedores que encapsulanla interfaz web y la api de la aplicacioacuten en el repositorio puacuteblico DockerHub
Los despliegues en este entorno se describen mediante ficheros JSON en losque se detalla entre otras opciones la imagen del contenedor los puertos a usar
30
los recursos que debe ocupar en un nodo o las instrucciones de monitorizacioacuten
Para el servicio de descubrimiento DCOS ofrece la posibilidad de asignardirecciones IP virtuales (VIP por sus siglas en ingleacutes) a tareas que se compartenen todos los nodos DCOS lleva integrado un balanceador de carga a nivel TCP(el componente denominado Minuteman) que balancea entre las direccionesvirtuales de las tareas y todas las instancias de eacutestas a lo largo del cluster Estoes necesario por dos motivos equilibrar la carga de los equipos con el fin deevitar un punto de uacutenico fallo mediante redundancia y evitar la contienda dedirecciones al ejecutar las tareas en puertos aleatorios
Este balanceador de carga estaacute basado en el trabajo de Michael Mitzenma-cher The Power of Two Choices in Randomized Load Balancing18 A grandesrasgos el algoritmo mantiene una media moacutevil exponencial de latencias paracada destino (backend) ademaacutes de las caiacutedas consecutivas Si un destino noresponde a una negociacioacuten en tres pasos (three way handshake) de forma con-secutiva en un periodo inferior a 5 ms se considera caiacutedo El algoritmo iterasobre los destinos disponibles en base a su histoacuterico de fallos y escoge dos deforma aleatoria de los cuales coge el de mejor meacutetrica
Las direcciones virtuales soacutelo se pueden resolver dentro del cluster porello para implementar la interfaz puacuteblica de la aplicacioacuten esto es el balancea-dor de carga de la interfaz web usaremos un paquete de DCOS denominadomarathon-lb un balanceador basado en HAProxy y adaptado por MesosphereEn este caso equilibra la carga de todas instancias de las tareas ejecutadas porel entorno Marathon por sus etiquetas y permite ademaacutes definir como puntode entrada muacuteltiples hosts virtuales definidos por sus nombres completos dedominio (FQDN por sus siglas en ingleacutes) en nuestro caso la interfaz puacuteblicadel balanceador de Azure para los agentes
Por motivos de seguridad todas las tareas se ejecutan en los agentes privadoses decir los que son exclusivamente accesibles desde la red interna Por su partemarathon-lb se ejecuta en el agente puacuteblico que cuenta con IP puacuteblica y lospuertos 80 (HTTP) y 8080 abiertos de forma que la aplicacioacuten sea accesibledesde Internet Esto es posible debido a que Apache Mesos permite reservarrecursos mediante roles asignados a nodos para un uso especiacutefico De esta formala arquitectura vista desde la aplicacioacuten quedariacutea como en la figura 19
18httpswwweecsharvardedu~michaelmpostscriptstpds2001pdf
31
Figura 19 Arquitectura de la aplicacioacuten web en DCOS
Ejecucioacuten
A la hora de desplegar la aplicacioacuten DCOS puede gestionarse medianteuna interfaz graacutefica o una interfaz de liacutenea de comandos La primera se accedea traveacutes de un navegador web en el puerto 80 (HTTP) y permite instalar losentornos disponibles observar el estado de los nodos y las tareas que se estaacutenejecutando y los ficheros de registros que eacutestas generan
La CLI permite el control desde un nodo o una maacutequina remota (suponiendoque los maestros tienen IP puacuteblica y el puerto 80 abierto) ya que DCOS tieneun sistema de autorizacioacuten que permite tener una interfaz puacuteblica con ciertasgarantiacuteas de seguridad
Por su parte cada entorno de trabajo puede ser controlado por la CLI peroademaacutes cuenta con sus propias interfaces Marathon expone una API HTTPen el puerto 8080 de la direccioacuten puacuteblica de los maestros del cluster asiacute comootra interfaz graacutefica Para desplegar un contenedor se podriacutea usar la CLI
$ dcos marathon app add lt f i l e j songt
O la API HTTP
$ cu r l minusX POST http lt ip_maestro gt8080v2apps minusd ltf i l e jsongt minusH Contentminustype app l i c a t i o n j son
32
612 Nomad
La arquitectura de Nomad es maacutes sencilla ya que solo requiere de un ficheroejecutable en todos los nodos para funcionar Si DCOS es la base de instala-cioacuten de entornos de terceros Nomad integra todas las funcionalidades baacutesicasesto es gestor de recursos planificador y ejecutor en los nodos cliente Estaherramienta cuenta con un menor tiempo de desarrollo y en el momento deescribir este documento cuenta exclusivamente con los siguientes controladoresen comparacioacuten con los entornos de DCOS
Motor Docker es decir funcioacuten de orquestacioacuten de contenedores
Ejecucioacuten de archivos binarios como comandos de Shell
Ejecucioacuten de aplicaciones Java
Virtualizacioacuten de maacutequinas mediante tecnologiacutea QEMU
Todos ellos necesitan que la tecnologiacutea subyacente esteacute instalada en las maacute-quinas clientes (Docker Java QEMU) Actualmente no permite el registro decontroladores por parte de terceros aunque estaacute planificado en un futuro ofreceruna interfaz para su desarrollo
Nomad no cuenta con el servicio de descubrimiento sin embargo puede inte-grarse con la herramienta Consul desarrollada por la misma empresa Por otrolado para el balanceo de carga usaremos un contenedor Docker con HAProxyuna herramienta de coacutedigo abierto que ofrece tanto servicios de proxy como debalanceador y cuyos ficheros de configuracioacuten completaremos con el proyectoConsul Template19
Consul
Consul sigue la misma arquitectura que Nomad es decir un nodo servidorque orquesta un conjunto de maacutequinas clientes y permite a los procesos que seejecutan en los equipos definirlos como servicios ofreciendo diversas caracteriacutes-ticas entorno a estos de los cuales vamos a usar dos
Descubrimiento de servicio Las maacutequinas clientes publican en el cataacutelogode servicios las tareas en ejecucioacuten y Consul les asigna nombres de dominioaccesibles por todos los miembros del cluster a traveacutes de la interfaz DNSincluida en esta herramientaConsul se integra con Nomad de forma que todas las tareas que se ejecu-ten en la segunda son automaacuteticamente publicados como servicios de laprimera de esta manera no hace falta conocer la direccioacuten de la maacutequinacliente donde se esteacute ejecutando el proceso ya que se puede acceder a eacutela traveacutes de su nombre de dominio de forma transparente Por ejemplo si
19[httpsgithubcomhashicorpconsul-template]
33
ejecutamos una tarea con ID web en el puerto 8080 se puede acceder aella en la direccioacuten webserviceconsul8080Para que las direcciones propias de Consul las resuelva su propio DNS y noel que esteacute asignado por defecto en la maacutequina usaremos la herramientadnsmasq20 que permite especificar la direccioacuten de un servidor DNS paraconsultas de direcciones especiacuteficas
Monitorizacioacuten Permite realizar comprobaciones del servicio y seguir su esta-do Aprovecharemos esta funcionalidad tanto para definir el propio procesode Nomad como servicio de Consul como las tareas desplegadas
HAProxy + Consul Template
HAProxy es una solucioacuten versaacutetil de coacutedigo abierto que ofrece solucionesde balanceo de carga y proxy Existen otras herramientas en el mercado comoNGINX o ldirectord sin embargo HAProxy suponiacutea una solucioacuten sencilla deconfigurar para mostrar el caso de uso
El uso de estas herramientas se debe a dos motivos para que no existacontienda con respecto a los puertos de los clientes usados por las tareas eacutestos sevan a asignar de forma dinaacutemica lo que en principio implicariacutea que la aplicacioacutendeberiacutea realizar consultas DNS de tipo SRV (que incluye puertos) a la interfazde Consul y balancear la carga entre tareas por redundancia y capacidad
Como la direccioacuten IP y puerto son variables cada vez que las tareas seactualicen o se reasignen es necesario volver a configurar HAProxy de formamanual Por ello HashiCorp ha desarrollado un programa denominado Con-sul Template que realiza peticiones sucesivas a la interfaz HTTP de Consul delas direcciones fiacutesicas de un servicio y reinicia automaacuteticamente el proceso deHAProxy Asiacute definiendo estas tareas como servicios Consul podremos tantomonitorizarlas como escalar las tareas dinaacutemicamente sin necesidad de cambiarel balanceador A partir del contenedor Docker oficial de HAProxy se ha desa-rrollado otro con la configuracioacuten baacutesica y con Consul Template para desplegarlocomo una tarea en Nomad
Despliegue
Se ha usado el mismo coacutedigo que en el apartado anterior con la persistenciaen el servicio de almacenamiento de Azure Desde la perspectiva del hardwarese implementaraacute la misma infraestructura que en el caso de DCOS (figura 18)estos es definiremos dos tipos de maacutequinas clientes un agente que se conectaraacutecon el balanceador de carga con nombre de dominio puacuteblico y donde se desple-garaacute el balanceador de carga de la vista web y agentes privados no accesiblesdesde fuera del cluster y donde se ejecutaraacuten el resto de tareas en la red inter-na La principal diferencia radica en las tareas que ejecutan HAproxy y ConsulTemplate que sustituye a las direcciones IP virtuales que ofrece DCOS
20httpwwwthekelleysorgukdnsmasqdochtml
34
Figura 20 Despliegue en Azure de Nomad+Consul
Cabe matizar que los balanceadores basados en HAProxy se implementanpor necesidad de la aplicacioacuten para el descubrimiento del servicio a diferenciade los de Azure que se implementan por motivos de seguridad y escalabilidaddel cluster en siacute
Configuracioacuten Nomad
Los ficheros de configuracioacuten de las maacutequinas maacutester y cliente son similaresy comparten la mayoriacutea de las opciones como por ejemplo el nombre del nodoo la interfaz de red donde escucha Nomad las peticiones Sus opciones son engeneral auto-explicativas sin embargo existen dos detalles que matizar
El proceso de Nomad escucha las peticiones tanto de los protocolos deconsenso como del usuario a traveacutes de una interfaz de red que se debeindicar en el fichero de configuracioacuten
En el caso de los clientes se deben indicar las direcciones de los servidoresdel cluster sin embargo se trata de un sistema dinaacutemico en el que losnodos pueden sufrir errores y cambiar de direccioacuten Por ello se ha definidoNomad como un servicio de Consul y asiacute poder definir la direccioacuten de losservidores como un nombre de dominio no por su direccioacuten fiacutesica que elservidor DNS de Consul se encargaraacute de resolver
Por defecto Nomad usa los siguientes puertos
API HTTP 4646 Peticiones HTTP y recepcioacuten de oacuterdenes mediante laliacutenea de comandos
RPC 4647 Protocolo de consenso entre los nodos del cluster
Serf 4648 Protocolo de gossip entre los servidores de los centros de datosgobernados por Nomad
35
Los dos uacuteltimos deben ser interfaces alcanzables por otros nodos sin embargo laAPI HTTP por motivos de seguridad deberiacutea ser local ya que en caso contrariocualquier persona con acceso a ella tiene el control sobre la herramienta Eacutestasolo deberiacutea estar accesible en un servidor o gestionarlo mediante una terminalSSH por ejemplo En este trabajo al ser una prueba de concepto se ha abiertoen todos los nodos
Trabajos de Nomad
Las tareas se detallan en ficheros con formato HashiCorp Configuration Lan-guage un derivado del formato JSON creado por la empresa que le da nombrecompatible con eacuteste y que permite comentarios
En estos ficheros se puede definir
La regioacuten y el centro de datos donde se ejecutaraacute (Nomad permite lagestioacuten de centros de datos geograacuteficamente distribuidos en regiones)
La poliacutetica de actualizacioacuten de la tarea
Grupo de tareas esto es que se ejecutaraacuten en el mismo nodo
El nuacutemero de grupos a ejecutarescalar asiacute como los liacutemite que debencumplir los nodos asignados
La poliacutetica de reinicio ante fallo o error
Tareas El controlador su configuracioacuten los paraacutemetros del servicio aso-ciado a registrar en Consul asiacute como los recursos que consume (puertosmemoria)
En nuestro caso usamos sobre todo el controlador Docker esto eso orques-tacioacuten de contenedores en los nodos clientes y tres de sus opciones
Imagen del contenedor Se han subido todas las imaacutegenes del proyecto a Doc-ker Hub donde por defecto se busca la imagen
Puertos Los puertos a usar por el contenedor que pueden ser estaacuteticos asigna-dos por el usuario o dinaacutemicos siendo Nomad el que se encarga de mapearun puerto libre del nodo cliente al expuesto por el contenedor
Servidores DNS Como usamos la interfaz DNS de Consul como descubri-miento de servicio se debe configurar el contenedor para que use cualquiernodo del cluster como servidor DNS
Configuracioacuten Consul
Al ser desarrolladas por la misma empresa los ficheros de configuracioacuten deConsul y Nomad comparten muchas opciones Consul tambieacuten acepta peticionesa traveacutes de una interfaz de red siendo los puertos usados por defecto
36
RPC 8300 8400 Maneja la peticiones del resto de nodos y usuarios
Serf 8301 8302 Protocolo gossip
HTTP API 8500
HTTPS API Desactivada por defecto
Interfaz DNS 8600
Se debe asignar a los protocolos internos del cluster esto es RPC y Serf unainterfaz alcanzable por los nodos y por el contrarioasignar a los dos uacuteltimos ala interfaz de loopback por motivos de seguridad
Cabe destacar que Consul tambieacuten cuenta con una interfaz graacutefica que per-mite ver el estado de los equipos y los servicios registrados y que se encuentra enel mismo puerto que la API HTTP en la direccioacuten httpIP_EQUIPO8500ui
Ejecucioacuten
Tanto Nomad como Consul requieren de la ejecucioacuten de un fichero en todoslos nodos integrantes del cluster Como prueba de concepto se ha decidido usardos servidores para ambos aunque cabe matizar que es un nuacutemero ineficienteya que la caiacuteda de uno de ellos supondriacutea la peacuterdida del cuoacuterum y por tantodel consenso del cluster
En primer lugar se arrancan los servidores que son los encargados de ejecu-tar el protocolo de consenso y gestionar el cluster y a continuacioacuten los clientesque no tienen praacutecticamente estado y dependen de los servidores
En el caso de Consul se debe indicar el directorio donde se guardan losficheros que describen los servicios asiacute como el archivo que especifica el resto delas opciones
1 Se inicia el primer servidor en uno de los equipos
$ consu l agent minuscon f i gminusd i r e t c consu l d s e r v i c e s minuscon f i gminus f i l e consu l_server j son
2 Los siguientes equipos deben unirse al anterior por lo que antildeadimos elargumento join con la direccioacuten del primer servidor Para el caso de otrosservidores
$ consu l agent minuscon f i gminusd i r e t c consu l d s e r v i c e s minuscon f i gminus f i l e consu l_server j son minus j o i n ltIP_servidor1gt
37
Una vez los servidores han alcanzado el consenso y elegido un liacuteder en losclientes
$ consu l agent minuscon f i gminusd i r e t c consu l d s e r v i c e s minuscon f i gminus f i l e c on su l_c l i en t j son minus j o i n ltIP_cualquierServ idorgt
El proceso para iniciar Nomad es igual y los comandos similares sin embargoya no es necesario indicar una direccioacuten IP fija en los equipos sino el nombre dedominio del servicio de Nomad registrado por Consul En el primer servidor
$ nomad agent minusc on f i g nomad_server j son
Y el resto de equipos (con su fichero de configuracioacuten correspondiente)$ nomad agent minusc on f i g nomad_server j son minus j o i n nomad s e r v i c e consu l
Por uacuteltimo para desplegar la aplicacioacuten web se han escrito tres ficherosque detallan las tareas de la interfaz web API y los balanceadores de cargaMediante la CLI
$ nomad run minusaddress=http lt ip_c lus te r gt4646 lt f i l e hclgt
O mediante la API HTTP de Nomad$ cu r l minusX POST minusd ltf i l e hclgthttp lt ip_c lus te r gt4646 jobltjob_namegt
Ansible
Como se puede comprobar con el aumento del nuacutemero de equipos pasa aser inviable manejar todos los nodos a traveacutes de terminal Ademaacutes como seha comentado con anterioridad Nomad requiere que en los nodos clientes es-teacuten instalados las herramientas que soporten las tareas por ejemplo el motorde Docker Por ello para facilitar tanto el arranque como la instalacioacuten de lasdependencias vamos a usar Ansible una herramienta de coacutedigo abierto desarro-llada en Python que permite gestionar configuraciones aprovisionar recursosdespliegue de aplicaciones de forma automaacutetica
A grandes rasgos esta herramienta funciona mediante ficheros en formatoYAML denominados play-books que describen un conjunto de pasos a ejecutaren una lista de equipos remotos Estos pasos son ejecutados por moacutedulos inde-pendientes a traveacutes de SSH es decir en cualquier ordenador con conexioacuten a los
38
hosts dado su contrasentildea o clave puacuteblica puede arrancar el script y realizariacutealos pasos de forma remota gestionando el cluster desde un solo equipo
Se han desarrollado guiones para lo siguiente
Descarga de los binarios de Nomad y Consul en todos los nodos copiade los ficheros de configuracioacuten baacutesicos y modificarlos de acuerdo a cadanodo (nombre del equipo direccioacuten IP)
Instalacioacuten de las dependencias
Arranque de Nomad y Consul
Ansible extiende su funcionalidad a traveacutes de moacutedulos independientes que per-miten por ejemplo instalar paquetes mediante herramientas de gestioacuten de pa-quetes (APT yum) aprovisionar automaacuteticamente maacutequinas virtuales de Ama-zon EC2
Algunas opciones de los ficheros de configuracioacuten de Nomad y Consul sondependientes del nodo particular por ejemplo la interfaz de red Para estetrabajo se ha realizado un moacutedulo para modificar los ficheros de configuracioacutende forma automaacutetica En el repositorio del proyecto se encuentra una carpetadonde se encuentran todos los ficheros necesarios para desplegar un clustertotalmente funcional solo requiere de una liacutenea de terminal con Ansible
$ ans ib l eminusplaybook minus i hos t s minusk ltssh_passgt minusu ltnode_usergt s i t e yml
39
62 Servicio de integracioacuten continua
Se ha implementado un sistema de integracioacuten continua que permite ejecu-tar tareas de compilacioacuten y pruebas de forma distribuida aumentando asiacute elrendimiento de los equipos En primer lugar se detallaraacute los motivos por los quepuede resultar beneficioso para las empresas una implementacioacuten de este tipo alo que seguiraacute los detalles del despliegue
621 DevOps
Metodologiacutea que defiende la comunicacioacuten y colaboracioacuten entre desarrolla-dores de software y los profesionales de operaciones a lo largo de todo el ciclo devida de una aplicacioacuten Estaacute muy relacionado con el desarrollo aacutegil de softwareesto es un enfoque para los proyectos que defiende el desarrollo iterativo e in-cremental donde los requisitos y soluciones evolucionan con el tiempo seguacuten lanecesidad del proyecto DevOps extiende esta filosofiacutea a todas los componentesde un servicio incluyendo sistemas y operaciones
Se trata de un concepto que cada organizacioacuten o empresa adapta a suspropias necesidades y procesos de negocio en este proyecto nos vamos a centraren la integracioacuten continua una praacutectica fundamental tanto del desarrollo aacutegilcomo de esta filosofiacutea
622 Integracioacuten Continua
Se define como una praacutectica de desarrollo software donde los miembros delequipo ponen en comuacuten su trabajo frecuentemente al menos una vez al diacutea21Cada integracioacuten se verifica con una compilacioacuten automaacutetica que incluye laejecucioacuten de pruebas para detectar errores de integracioacuten tan pronto como seaposible
Desde el punto de vista operativo esto supone automatizar la configuracioacutende equipos o el despliegue de maacutequinas virtuales donde compilar el proyecto yejecutar las pruebas y posteriormente eliminarlas Este flujo de trabajo se vebeneficiado en entornos distribuidos ya que el objetivo del desarrollador es com-probar el resultado de las pruebas raacutepidamente sin preocuparse del despliegueo los propios equipos
Para esta prueba de concepto vamos a usar Jenkins un servidor de integra-cioacuten continua escrito en Java que nos permite definir trabajos que contendraacutenla descripcioacuten tanto del entorno como su ejecucioacuten
Este sigue una estructura maestro-esclavo muy similar al de los gestores declusters usados en este proyecto el maestro contiene toda la loacutegica del servicio
21httpmartinfowlercomarticlescontinuousIntegrationhtml
40
trabajos autenticacioacuten y los esclavos son los encargados de la ejecucioacuten ensiacute Jenkins tiene varias viacuteas para aprovisionar los uacuteltimos
Mediante SSH
Interfaz graacutefica
Desarrollar un script propio
Ejecucioacuten de un fichero java
La ventaja de usar planificadores es que el despliegue de esclavos es dinaacutemicoes decir no tener una maacutequina especiacuteficamente configurada para ello DCOS yNomad se encargaraacuten de configurar estos despliegues en sus maacutequinas y poste-riormente eliminarlos Para ello se ha usado la uacuteltima opcioacuten definiendo tareasque descarguen el fichero java Con todo ello se consigue un entorno de inte-gracioacuten continua eficiente que ademaacutes permite la ejecucioacuten de otros servicios deforma independiente
Jenkins permite la creacioacuten de plugins que extienden sus funcionalidadesTanto Nomad22 como Apache Mesos cuentan con uno que permite su integra-cioacuten
Para esta prueba se va a usar el mismo proyecto que para el caso de usode orquestacioacuten de contenedores la aplicacioacuten web al que se le ha antildeadido untest para comprobar que se conecta correctamente a la base de datos medianteMocha un framework de Nodejs Por otro lado se antildeade el plugin de git ya queel coacutedigo se obtiene de GitHub el repositorio remoto de control de versiones delproyecto
El proceso general de ejecucioacuten seriacutea como sigue
1 Se ejecuta el maestro de Jenkins como tarea Docker partiendo de la imagenoficial
2 Al arrancar un trabajo se manda una tarea a los planificadores que laasignaraacuten a un nodo cliente Esta tarea consiste en la descarga del ficherode configuracioacuten Java y arrancarlo configurando el equipo como un clientede Jenkins temporalmente
3 Jenkins ejecuta el trabajo en el nuevo cliente en este caso iniciar la apli-cacioacuten web iniciar las pruebas y generar un informe
4 Se elimina el cliente
A continuacioacuten se detallan los matices de cada herramienta a la hora de imple-mentar este servicio
22Desarrollado por Ivo Verberk httpwwwivoverberknl
41
623 Jenkins con Nomad
El plugin permite la ejecucioacuten del fichero Java mediante dos controladorescontenedores Docker y Java En este proyecto nos hemos decantado por el pri-mero ya que nos ahorra instalar la maacutequina virtual de java en todos los nodoscliente Por ello se ha construido un contenedor base con Java para la ejecucioacutendel fichero de configuracioacuten y Nodejs para lanzar la aplicacioacuten web
El plugin se configura con la direccioacuten IP del cluster y el contenedor queejecuta el esclavo Jenkins Por su parte el trabajo en Jenkins se define conel repositorio en GitHub donde se aloja el coacutedigo del proyecto a probar y loscomandos a ejecutar en este caso npm update y npm test
624 Jenkins con DCOS
En el caso de DCOS su sistema de paquetes incluye Jenkins por lo queal instalarlo ya se tiene la configuracioacuten de Mesos totalmente funcional Sinembargo para ejecutar la aplicacioacuten en particular y las pruebas se requiere deNodejs en los equipos esclavos por ello debemos antildeadir un plugin de Jenkinsque permite instalar este entorno antes de ejecutar el trabajo Una vez hechoesto soacutelo queda definir la tarea igual que en el caso anterior
Cabe destacar que Mesosphere tambieacuten ha desarrollado un plugin que per-mite hacer despliegues en Marathon de tal manera que permitiriacutea con cadacommit del coacutedigo compilar la imagen del contenedor Docker y desplegarlaautomaacuteticamente aunque en este proyecto no se ha hecho pruebas de esta fun-cionalidad
42
7 Escalando la infraestructura
Uno de los factores clave que se busca a la hora de implementar sistemasdistribuidos es el poder escalar la infraestructura de forma maacutes sencilla estoes detectar que las maacutequinas estaacuten alcanzando el liacutemite de su capacidad yaumentar eacutesta ya sea mejorando sus caracteriacutesticas teacutecnicas o antildeadiendo maacutesnodos al cluster
El coacutedigo y todos los ficheros de configuracioacuten de esta seccioacuten tambieacuten sepueden encontrar en el repositorio del proyecto en GitHub23
71 Disentildeo
Microsoft Azure permite organizar los servicios cloud de forma loacutegica a traveacutesde grupos de recursos y asiacute poder crear o eliminar eacutestos en conjunto parauna aplicacioacuten determinada (por ejemplo una aplicacioacuten web suele requerir demaacutequinas virtuales bases de datos almacenamiento) Ademaacutes dispone dela opcioacuten de crear plantillas en formato JSON que permite al desarrolladordefinir los recursos y su interrelacioacuten para desplegar de forma automaacutetica unainfraestructura TI en la nube
Azure tambieacuten ofrece la posibilidad de monitorizar el estado de las maacutequinasvirtuales a traveacutes de extensiones lo que permite configurar el escalado automaacute-tico al alcanzar cierto liacutemite definido por el operador Eacutesta es a priori la formaen que deberiacutea implementarse hablando en teacuterminos de eficiencia sin embargoesta aproximacioacuten es totalmente dependiente de la plataforma es decir no sepuede extrapolar a otro proveedor o sobre recursos propios sin realizar un nue-vo disentildeo En este proyecto las tareas que son ejecutadas por estos equipos notienen estado ya que todo lo relativo a la persistencia lo hemos asignado fueradel cluster esto permite escalar la plataforma a traveacutes de otra aproximaciones
Las plantillas aceptan una serie de variables a indicar por el usuario entreotras los conjuntos de escala para definir los nodos aceptan una variable quedefine el nuacutemero de maacutequinas que los componen Por otro lado Azure ofreceuna API REST y kits de desarrollo software (SDK por sus siglas en ingleacutes) quepermiten su despliegue de forma programaacutetica Aprovechando estas facilidadesen este proyecto se va a aproximar la escalabilidad con el sucesivo desplieguede la infraestructura de forma automaacutetica se monitorizan los equipos y si sedetecta una maacutequina excesivamente cargada se aumenta el nuacutemero de equiposen la plantilla y se vuelve a desplegar
23httpsgithubcomAntonioAlfrzCloud-Orchestrators
43
En este proyecto se han disentildeado las plantillas para desplegar la arquitec-tura necesaria tanto de Nomad como de DCOS En el caso de la primera eldespliegue es maacutes descriptivo ya que incluye maacutequinas virtuales grupos de se-guridad redes En el caso de DCOS Azure cuenta con un servicio especiacuteficopara clusters gobernados por DCOS denominado Azure Container Service queincluye los componentes necesarios y la instalacioacuten ya realizada
72 Implementacioacuten
En primer lugar para monitorizar el estado de los equipos se va a usar laherramienta Nagios un sistema que permite controlar el estado del hardwarey los servicios de un equipo Se trata de una herramienta muy completa de laque se va a usar su capacidad para ejecutar comandos (plugins) en los nodospara detectar picos de carga generar alertas y ejecutar programas para estoseventos
Se ha desplegado una maacutequina virtual con esta herramienta en ambos siste-mas y se ha instalado una extensioacuten de Nagios (Nagios Remote Plugin Executor)en todos los nodos que permite ejecutar comprobaciones remotamente en con-creto para esta prueba de concepto medir el nivel de saturacioacuten de la unidadcentral de procesamiento (CPU por sus siglas del ingleacutes) Cuando sucede uncambio de estado de una maacutequina esto es cuando este paraacutemetro supera el liacutemi-te definido por el operador Nagios permite actuar en consecuencia ejecutandoprogramas por ello se ha desarrollado un script que ejecuta lo siguiente
Un programa desarrollado en Python con el SDK de Azure que modificalas plantillas y despliega los recursos
Un guioacuten de Ansible para instalar todos los componentes necesarios en lasnuevas maacutequinas y arrancar de nuevo el cluster y las aplicaciones
44
8 Resultados y conclusiones
En este uacuteltimo apartado se da una visioacuten global del proyecto asiacute como a lasconclusiones maacutes importantes a las que se ha llegado y posibles temas futurosde desarrollo
81 Comparacioacuten
Ambas herramientas ofrecen las funcionalidades para gestionar los recursoseficientemente ofreciendo a los desarrolladores una plataforma donde desplegarsus aplicaciones de forma distribuida independientemente de los equipos fiacutesicosy el hardware que las soporten
DCOS es una herramienta que en un comienzo fue privativa pero cuyos res-ponsables la empresa Mesosphere decidieron publicar una versioacuten de coacutedigoEacutesta nos permite gestionar un cluster de una forma sencilla y usable ademaacutes decomplementarlo con otras herramientas como el balanceador de carga integradoo la autenticacioacuten de usuarios ademaacutes estaacute basada en Apache Mesos un pro-yecto de relativa madurez y con el soporte de la Apache Software FoundationDe forma resumida DCOS ofrece muchas posibilidades y servicios a cambiode una arquitectura e instalacioacuten maacutes compleja
Por su parte HashiCorp con menor tiempo de desarrollo ha conseguidouna herramienta muy sencilla de desplegar que ademaacutes cumple con todas lasfuncionalidades baacutesicas ejecutando un simple binario en cada nodo se puededesplegar un gestor de clusters totalmente funcional Sin embargo no cuentacon todas las posibilidades de Mesos (Nomad cuenta con menos controladoresque entornos posibles de Mesos) ni con los antildeadidos de DCOS lo que implicael uso de otras herramientas para complementar el servicio (Consul HAProxy)
De entre las dificultades encontradas al usar estas herramientas y desplegaraplicaciones sobre ellas se puede destacar la depuracioacuten en ocasiones se desco-noce si un error viene de la propia herramienta de la aplicacioacuten desplegada o delequipo fiacutesico si no se cuenta con un sistema de procesamiento de registro unose puede encontrar con muacuteltiples terminales abiertas inspeccionando numerososficheros de registro buscando posibles errores Ademaacutes no dejan de ser solucio-nes que para usar eficientemente se debe conocer parte de su funcionamientoy sintaxis a la hora de describir la tareas lo que supone un esfuerzo antildeadido yaque cada una tiene sus particularidades y liacutemites
45
82 Conclusiones
En una sociedad cada vez maacutes digital las empresas deben adaptarse a unmercado cuya demanda de contenido no deja de crecer Las nuevas arquitecturascomo microservicios asiacute como la gran cantidad de datos generada implica queuna mejor gestioacuten de los recursos y la rapidez para desplegar o escalar solucionesdando valor al cliente lo maacutes raacutepido posible es uno de los objetivos de todas lasempresas de base tecnoloacutegica
Las ventajas que ofrecen los planificadores con aplicaciones distribuidas sonnumerosas sin ir maacutes lejos empresas tan punteras como Google llevan maacutesde 10 antildeos orquestando contenedores24 Por un lado permiten aumentar elrendimiento de los equipos propios y por otro implementar un servicio comoplataforma para despliegues distribuidos sobre cualquier conjunto hardware deesta forma se provee un servicio similar al de la nube puacuteblica pero con laprincipal diferencia de que se elimina la independencia con el proveedor (vendorlock-in) esto es las aplicaciones no tienen limitaciones impuestas por eacuteste talescomo lenguaje de programacioacuten o herramientas y permite despliegues hiacutebridosentre recursos propios y la nube
83 Objetivos conseguidos
Implementacioacuten de los planificadores propuestos en la nube Se ha en-tendido y detallado el funcionamiento de estas herramientas y se hanimplementado en el servicio de infraestructura de Microsoft Azure
Despliegue de aplicaciones y servicios distribuidos Servicios que se usanactualmente en la industria del desarrollo software asiacute como una aplica-cioacuten web con una arquitectura moderna han sido desplegados de formadistribuida en los equipos cumpliendo con la funcionalidad esperada ade-maacutes de consiguiendo una alta disponibilidad
Aproximacioacuten de arquitectura escalable Se ha hecho una aproximacioacutende infraestructura escalable de forma que sea parcialmente extrapolable aotros proveedores
24httpwwwnextplatformcom20160322decade-container-control-google
46
84 Liacuteneas de investigacioacuten
Siguiendo con la materia de este proyecto se presentan posibles liacuteneas deinvestigacioacuten
Analizar el despliegue con estas herramientas de aplicaciones de Big Datay comparar la eficiencia con respecto a soluciones especializadas
Analizar el rendimiento de los algoritmos de planificacioacuten antes pruebasde estreacutes y situaciones de alta contienda
Comparar el uso de estas herramientas con las praacutecticas actuales de laindustria o implementacioacuten en un sistema de produccioacuten real
47
Referencias
[1] LA Barroso y U Houmllzle laquoThe Datacenter as a Computer An Introduc-tion to the Design of Warehouse-Scale Machinesraquo En Morgan amp ClaypoolPublishers ()
[2] Systems Research Group ndash NetOS (University of Cambridge) The evolu-tion of cluster scheduler architectures 2016 url httpswwwclcamacukresearchsrgnetoscamsasblog2016-03-09-scheduler-architectureshtml
[3] A Das I Gupta y A Motivala SWIM Scalable Weakly-consistent Infection-style Process Group Membership Protocol Inf teacutec Dept of ComputerScience Cornell University url https www cs cornell edu ~asdasresearchdsn02-swimpdf
[4] D Dubhashi y A Das Mastering Mesos PACKT Publishing mayo de2016
[5] The Apache Software Foundation Apache Mesos documentation urlhttpsmesosapacheorg
[6] David Greenberg Building Applications on Mesos OrsquoReilly Media 2016[7] Armand Grillet Comparison of Container Schedulers Inf teacutec Technische
Universitaumlt Berlin[8] HashiCorp Consul documentation url httpswwwconsulio[9] HashiCorp Nomad documentation url httpsdcosio[10] Dan C Marinescu Cloud computing theory and practice Morgan Kauf-
mann 2013[11] Mesosphere DCOS documentation url httpswwwnomadproject
io[12] Microsoft Azure documentation url httpsazuremicrosoftcom
es-esdocumentation[13] D Ongaro y J Ousterhout In Search of an Understandable Consensus
Algorithm Inf teacutec Stanford University url httpsraftgithubioraftpdf
[14] Fei Teng laquoRessource allocation and schelduling models for cloud compu-tingraquo Tesis de mtriacutea Ecole Centrale Paris 2011
[15] A Williams y col Automation and Orchestration with Docker and Contai-ners A Comprehensive Overview of the Docker and Container Ecosystem3 The New Stack 2016
48
- Resumen
- Summary
- Iacutendice de figuras
- Introduccioacuten y objetivos
-
- Contexto
- Objetivos
- Estructura del documento
-
- Cloud Computing
- Nuevas cargas de trabajo
- Gestioacuten de recursos Planificadores
-
- Sistemas distribuidos
-
- Clasificacioacuten
-
- Herramientas
-
- DCOS
-
- Apache Mesos
- Ejemplos de uso
-
- Nomad
-
- Protocolo de consenso Raft
- Protocolo gossip SWIM
- Planificacioacuten
-
- Casos de uso y despliegue
-
- Aplicacioacuten Web
-
- DCOS
- Nomad
-
- Servicio de integracioacuten continua
-
- DevOps
- Integracioacuten Continua
- Jenkins con Nomad
- Jenkins con DCOS
-
- Escalando la infraestructura
-
- Disentildeo
- Implementacioacuten
-
- Resultados y conclusiones
-
- Comparacioacuten
- Conclusiones
- Objetivos conseguidos
- Liacuteneas de investigacioacuten
-
1 Introduccioacuten y objetivos
11 Contexto
Las tecnologiacuteas de la informacioacuten y la comunicacioacuten estaacuten suponiendo uncambio draacutestico en la sociedad en 2007 comenzaron a aparecer los teleacutefonosinteligentes tal y como los conocemos y nueves antildeos despueacutes se empieza a con-cebir la idea de dar conectividad a todo dispositivo electroacutenico movimiento queha tomado el nombre de Internet de las cosas Para hacerse una idea de la rapi-dez y magnitud de esta evolucioacuten la consultora Excelacom1 ha estimado que enun minuto se realizan 24 millones de buacutesquedas en Google o se ven 278 millonesde viacutedeos en Youtube En una eacutepoca en la que los recursos tecnoloacutegicos crecenexponencialmente y los usuarios demandan mayor contenido y movilidad nocabe duda que las empresas deben adaptarse lo maacutes raacutepidamente posible a esteproceso de digitalizacioacuten movidas por las nuevas necesidades de las personas
Dado el gran volumen de informacioacuten a lo largo de estos antildeos la compu-tacioacuten y el almacenamiento estaacuten pasando de clientes locales a concentrarse engrandes centros de datos una tendencia que Google ha denominado ldquoWarehouse-scale computingrdquo en 2009[1] Este movimiento hacia la computacioacuten desde ser-vidor no solo viene de la necesidad de mejorar la experiencia de los usuariossino tambieacuten de facilitar la gestioacuten y configuracioacuten de los recursos asiacute como laubicuidad de acceso que permite
En 2006 Amazon lanza Amazon Web Services siendo uno de los pionerosen el mercado de los recursos virtuales ofreciendo capacidad de computacioacutencon un coste proporcional exclusivamente a los recursos utilizados Todo ellocambioacute la perspectiva de los modelos tradicionales de TI a la conocida comocomputacioacuten en la nube recursos informaacuteticos que antes suponiacutean barrerasde entrada en ciertos mercados han pasado a ser condicioacuten necesaria para laconstante evolucioacuten de la tecnologiacutea y la sociedad De hecho Cisco estima quepara el antildeo 2019 maacutes del 86 de las cargas de trabajo seraacuten procesadas porcentros de datos en la nube2
1httpwwwexcelacomcomresourcesblog2016-update-what-happens-in-one-internet-minute2httpwwwciscocomcenussolutionscollateralservice-provider
global-cloud-index-gciCloud_Index_White_Paperpdf
1
12 Objetivos
El propoacutesito de este proyecto es estudiar la viabilidad del uso de planifica-dores de recursos para aumentar la eficiencia de eacutestos y facilitar al desarrolladorel despliegue de aplicaciones de forma distribuida y asiacute ofrecer un servicio ca-racterizado por una alta disponibilidad y escalabilidad
A lo largo de este trabajo se han usado algunas de las herramientas quese estaacuten comenzando a desarrollar para hacer frente a este nuevo enfoque degestioacuten de infraestructuras de las tecnologiacuteas de la informacioacuten (en adelanteinfraestructuras TI) realizando pruebas de concepto sobre cada una de ellas
13 Estructura del documento
A continuacioacuten se detalla las secciones que componen este trabajo La es-tructura queda como sigue
Cloud computing Se entra en detalle en este nuevo modelo de negocio queha originado nuevos enfoques y disentildeos de las infraestructuras TI dentrode las organizaciones
Nuevas cargas de trabajo Se explican algunas tecnologiacuteas representativasque estaacuten suponiendo un desafiacuteo para los profesionales de TI a la horade planificar los recursos y que se ven beneficiadas por entornos de tipocloud
Gestioacuten de recursos Planificadores Estado del arte de las tecnologiacuteas degestioacuten de clusters y planificacioacuten de recursos
Herramientas Descripcioacuten detallada del funcionamiento y arquitectura de lasherramientas usadas a lo largo del proyecto
Casos de uso y despliegue Se describe el proceso de implementacioacuten de unaaplicacioacuten web y un servicio de integracioacuten continua con el software pro-puesto
Escalando la infraestructura Se propone un procedimiento con cierta inde-pendencia del proveedor cloud
Resultados y conclusiones Resume las ideas y hechos a los que se ha llegadoademaacutes de introducir liacuteneas de investigacioacuten futuras
2
2 Cloud Computing
El NIST (National Insitute of Standards and Technology) define este con-cepto como un modelo que permite un acceso ubicuo y bajo demanda de formaremota a un conjunto compartido de recursos de computacioacuten que pueden seraprovisionados y liberados con unos miacutenimos esfuerzos de gestioacuten por parte delproveedor del servicio3
Clasificacioacuten
La computacioacuten en la nube abarca una amplia variedad de servicios y enfo-ques por lo que en primer lugar se va a dar una clasificacioacuten para posterior-mente entrar maacutes en detalle Existen distintos modelos de nube atendiendo a lagobernabilidad de la infraestructura seguacuten el NIST
Nubes puacuteblicas Los servicios y recursos son ofertados de forma puacuteblica yson provistos por una organizacioacuten que los comercializa bajo demanda
Nube privada Los recursos son gestionados por una uacutenica organizacioacutenpara su propio uso
Nube comunitaria En este caso la infraestructura es administrada por unconjunto de organizaciones con objetivos comunes
Nube hiacutebrida Una combinacioacuten de las anteriores
A su vez los distintos servicios que ofrece se pueden clasificar atendiendo algrado de control del usuario
Servicios de software (Software as a Service SaaS) El proveedor se encargade toda la gestioacuten de la infraestructura y oferta aplicaciones a las cuales elcliente puede acceder de forma ubicua a traveacutes de diversos clientes comoun navegador web Por ejemplo Office 365 o Google docs
Servicios de plataforma (Platform as a Service PaaS) Modelo de distribu-cioacuten que ofrece la capacidad de desplegar aplicaciones desarrolladas por elcliente usando las herramientas y lenguajes de programacioacuten soportadaspor el proveedor pero sin la posibilidad de gestionar los recursos consu-midos En este caso el cliente solo tiene control sobre la propia aplicacioacuteny algunas configuraciones del entorno Es el caso de Heroku o Google AppEngine
3httpnvlpubsnistgovnistpubsLegacySPnistspecialpublication800-145pdf
3
Servicios de infraestructura (Infrastructure as a Service IaaS) Se ofertanrecursos de computacioacuten puros como procesamiento o almacenamientomediante una plataforma de virtualizacioacuten El cliente puede controlar elsistema operativo componentes de red y aplicaciones
Figura 1 Comparacioacuten Centro de datos - Computacioacuten en la nubeFuente httpsad-hocnet
De entre las numerosas ventajas que ofrece la computacioacuten en la nube se puededestacar su flexibilidad ya que permite aprovisionar recursos y adaptarlos deacuerdo a la demanda reduce el capital inmovilizado y su amortizacioacuten laubicuidad que permite su consumo desde cualquier parte con conexioacuten a la redy la seguridad y fiabilidad que ofrece el proveedor que normalmente cuenta conrecursos geograacuteficamente distribuidos frente a la gestioacuten y mantenimiento derecursos propios
4
3 Nuevas cargas de trabajo
Las organizaciones que cuentan con sus propios infraestructuras TI han co-menzado a adoptar un enfoque de nube privada para gestionar las tareas ofunciones informaacuteticas sobre las que se sustentan el negocio ya que una es-tructura virtualizada puede ofrecer ventajas con respecto a las adaptaciones decentros de datos tradicionales en los aacutembitos de rendimiento escalabilidad eincluso seguridad4
A su vez se han desarrollado nuevas tecnologiacuteas que suponen cargas detrabajo dinaacutemicas y con gran intensidad de consumo de datos para las empresasque se ven beneficiadas al desplegarlas en recursos virtualizados
Big data
Con la creciente aceptacioacuten de las tecnologiacuteas TIC por parte de la sociedadla cantidad de datos generados en la red es ingente Las profesionales de TI tienecomo objetivo extraer valor de eacutestos para por ejemplo prever las tendencias delmercado Sin embargo este incremento exponencial hace que su procesamientoy almacenamiento requiera de un sistema con gran escalabilidad dado el hechode que una sola maacutequina no puede proveer de la capacidad necesaria
Integracioacuten continua
Modelo informaacutetico que consiste en hacer integraciones automaacuteticas de unproyecto con cualquier cambio en el coacutedigo con el objetivo de detectar fallosde forma temprana Esto implica la compilacioacuten del coacutedigo y su ejecucioacuten enun entorno de pruebas automaacuteticamente un proceso que mediante tecnologiacuteasde virtualizacioacuten permiten simular entornos con eficiencia y rapidez Su imple-mentacioacuten en sistemas distribuidos permite tanto una mejor planificacioacuten comoun mejor rendimiento de los recursos
Arquitectura de microservicios
Enfoque para desarrollar aplicaciones software como un conjunto de serviciosautoacutenomos que se comunican entre siacute a diferencia de aproximaciones monoliacuteti-cas donde la loacutegica del servicio estaacute desarrollada como una unidad Un sistemadistribuido permite el despliegue de los componentes en distintas maacutequinas loque mejora tanto su escalabilidad como la tolerancia a fallos
4httpswwwakamaicomesesresourcespublic-private-cloudjsp
5
Docker
Proyecto de coacutedigo abierto que facilita y automatiza el despliegue de aplica-ciones al encapsular el entorno de trabajo en contenedores Linux una tecnologiacuteaque permite a un sistema fiacutesico ejecutar muacuteltiples instancias de sistemas opera-tivos aislados mediante entornos virtuales con sus propios espacios de procesosy redes pero compartiendo el nuacutecleo (kernel) con el equipo anfitrioacuten
En la figura 2 se compara la pila de una virtualizacioacuten tradicional con res-pecto a los contenedores no se simula el sistema operativo por lo que el procesoes mucho maacutes ligero
Docker se caracteriza por
Autosuficiencia Los contenedores cuentan con las libreriacuteas y configuracio-nes necesarias para ejecutarse de manera autoacutenoma al compartir el nuacutecleo
Portabilidad El hecho de que sean autosuficientes implica que es inde-pendiente del host es decir se puede desplegar en cualquier equipo quesoporte esta tecnologiacutea
Tamantildeo El peso de un contenedor es sustancialmente inferior a otrastecnologiacuteas de virtualizacioacuten
Figura 2 Arquitectura DockerFuente httpsdockercom
6
Los componentes fundamentales de esta herramienta son
Imaacutegenes Describen el entorno de base sobre el que ejecutar el contene-dor por ejemplo la imagen del sistema operativo Ubuntu Sobre eacutesta seconstruyen las aplicaciones particulares del usuario dando lugar a otraimagen
Contenedores Se crean a partir de las imaacutegenes y comprenden todo aquellonecesario para arrancar la aplicacioacuten decir su entorno de ejecucioacuten
bull Voluacutemenes Encargados de gestionar la persistencia de datos e inde-pendientes del ciclo de vida del contenedor
Registros Pueden ser puacuteblicos o privados y almacenan las imaacutegenes elregistro puacuteblico oficial de Docker es Docker Hub
Dadas estas caracteriacutesticas los profesionales TI estaacuten comenzando a adoptarDocker ya que facilita tanto los despliegues como el trabajo compartido en dis-tintos entornos Sin embargo esto requiere de un software que permita desplegarlos distintos contenedores de forma que puedan trabajar en conjunto procesoque se ha denominado orquestacioacuten de contenedores
7
4 Gestioacuten de recursos Planificadores
Para sacar el maacuteximo provecho a las tecnologiacuteas anteriormente descritaslo ideal es desplegarlas en sistemas distribuidos sin embargo esto aumenta lacomplejidad del propio despliegue asiacute como la necesidad de software especiali-zado para ello Se necesitan algoritmos de planificacioacuten que permitan obtener elmaacuteximo rendimiento de los recursos por un lado y dar ciertas garantiacuteas de quetodas las tareas y procesos se van a ejecuta por otro
41 Sistemas distribuidos
En primer lugar se definen los sistemas distribuidos o clusters como unconjunto de ordenadores conectados entre siacute cuyo objetivo es trabajar como unauacutenica instancia de gran capacidad5
Su clasificacioacuten variacutea de acuerdo a cada autor pero en general se puedendividir seguacuten su objetivo en alto rendimiento aquellos cuyo objetivos es proveerde gran capacidad de coacutemputo gracias al conjunto de los nodos y alta disponi-bilidad con los cuales se busca la fiabilidad del sistema mediante redundanciayo balanceo de carga
El intereacutes de este proyecto recae en los uacuteltimos ya que el objetivo es porun lado ofrecer al desarrollador un entorno donde desplegar sus aplicaciones deforma distribuida y por otro maximizar el rendimiento de los recursos
De forma general las caracteriacutesticas que se buscan son las siguientes
Elasticidad Adaptacioacuten a cargas dinaacutemicas de trabajo aumentando (o dis-minuyendo) recursos de manera automaacutetica de tal forma que la utilizacioacutensea lo maacutes cercana a la demanda
Disponibilidad Capacidad de un sistema para mantener el servicio fun-cional
Tolerancia a fallos Recuperacioacuten del servicio ante el fallo de un compo-nente
Balanceo de carga Compartir las tareas entre las diferentes maacutequinasredundadas evitando asiacute puntos de uacutenico fallo
5httpsenwikipediaorgwikiComputer_cluster
8
Los programas que se implementan en entornos distribuidos se caracterizanpor ejecutarse de forma concurrente en equipos independientes estar conectadospor una red que introduce fallos aleatorios y no compartir memoria ni reloj Estoimplica entre otras cosas que
Los nodos soacutelo tienen un acceso raacutepido a su memoria local por lo quecualquier informacioacuten relativa al estado global puede ser potencialmenteerroacutenea
Las maacutequinas pueden sufrir caiacutedas de forma aleatoria
El intercambio de informacioacuten puede fallar ya sea por error en transmisioacuteno por caiacuteda de los nodos
Estas dificultades se ponen de manifiesto en el teorema de CAP en cienciasde la computacioacuten el teorema de CAP que lanzado inicialmente como conjetu-ra en el antildeo 2000 por Eric Brewer (motivo por el cual al teorema se le conoceformalmente como teorema de Brewer) y posteriormente demostrado en el antildeo20026 establece que es imposible para un sistema de coacutemputo distribuido ga-rantizar simultaacuteneamente dos de las tres propiedades siguientes
Consistencia (Consistency) es decir que todos los nodos vean la mismainformacioacuten al mismo tiempo Se busca que un cambio en el sistema soacutelose ejecute satisfactoriamente si y soacutelo si se efectuacutea a todos las maacutequinasde tal forma que los datos entre ellos nunca difieren y la respuesta a unapeticioacuten sea la misma independientemente del nodo que la atienda
Disponibilidad (Availability) esto es la garantiacutea de que toda peticioacuten debeobtener una respuesta (servicio funcional) aunque exista inconsistenciaentre nodos
Tolerancia al particionado (Partition Tolerance) es decir que el sistemasiga funcionado a pesar de un fallo en la comunicacioacuten entre los equipos
Por todo lo expresado anteriormente conseguir un sistema distribuido capazde ofrecer procesamiento de forma transparente implica una arquitectura TIcompleja Se requieren de subsistemas y herramientas que permitan la cohesioacutenentre todos los nodos
Gestor de los recursos de las diferentes maacutequinas
Monitorizacioacuten tanto de los servicios activos como de la funcionalidad delsistema ademaacutes de poliacuteticas para recuperacioacuten de fallo
Protocolos de consenso que permitan a los nodos ser consistentes con elestado global del cluster
6urlhttpsgroupscsailmitedutdspapersGilbertBrewer2pdf
9
Herramientas de descubrimiento de servicios que permita la comunicacioacutenentre tareas distribuidas
Planificadores Encargados de distribuir las tareas y procesos en las dife-rentes maacutequinas asignaacutendole parte de su capacidad
Los planificadores del ingleacutes cluster schedulers son un componente funda-mental por lo que vamos a entrar un poco maacutes en detalle en ellos
Planificadores (Cluster Schedulers)
Es el software encargado de monitorizar los recursos usados por cada maacute-quina perteneciente a un cluster y distribuir la carga de trabajo entre ellas deacuerdo a un poliacutetica o reglas
Este tipo de herramientas comparten cierta terminologiacutea que es relevantedefinir
Tarea Unidad de trabajo computacional comprendida por una secuenciade instrucciones datos de entrada y recursos asociados Por ejemplo laejecucioacuten de un comando o el arranque de una base de datos
Nodo Cualquier maacutequina integrante de un cluster En una arquitecturamaestro-esclavo se definen dos roles
bull Cliente Agente Esclavo Aquellos ordenadores que se encargan deejecutar las tareas
bull Maestro Servidor Su objetivo es mantener el estado del cluster ygestionar sus recursos
411 Clasificacioacuten
A lo largo de los uacuteltimos antildeos se han desarrollado diferentes tipos de plani-ficadores[2]
Monoliacutetico
Un solo planificador que se encarga de distribuir todas las tareas entran-tes La mayoriacutea de los planificadores en computacioacuten de alto rendimiento asiacutecomo Borg desarrollado por Google son de este tipo En la figura 3 se pue-de observar de forma graacutefica el procedimiento siendo las cajas grises maacutequinaspertenecientes al cluster y los ciacuterculos las tareas a asignar
10
Figura 3 Planificador monoliacuteticoFuente httpswwwclcamacuk
Planificacioacuten de dos niveles
La mayoriacutea de los clusters ejecutan aplicaciones con distintas necesidadesdesde procesos casi instantaacuteneos hasta servicios persistenteslo que implica dis-tintas necesidades de recursos
Por ello la planificacioacuten a dos niveles distingue dos funciones la gestioacutende recursos (gestor) y la disposicioacuten de las tareas (planificador) Cada serviciotiene su propio planificador de tal manera que el gestor les ldquoofertardquo recursosde acuerdo a una poliacutetica y los planificadores se encargan de escoger la maacutesadecuada Esto permite que el proceso de distribucioacuten sea maacutes acorde con lasnecesidades de los diferentes servicios Apache Mesos que detallaremos maacutesadelante sigue este esquema
Como desventaja cabriacutea sentildealar que esta programacioacuten implica que los pla-nificadores pierden la vista general de la infraestructura y las tareas soacutelo puedenejecutarse con los recursos que les son ofrecidos lo que dificulta la implementa-cioacuten de prioridades de ejecucioacuten de tareas entre otras
Figura 4 Planificador de dos niveles
11
Planificacioacuten de estado compartido
Muacuteltiples reacuteplicas del estado del cluster se actualizan independientementepara cada planificador como se observa en la figura 5 cuando sucede un cambiode forma local el planificador se encarga de informar al resto
Ejemplo de este tipo son Omega la evolucioacuten de Borg por parte de GoogleMicrosoft Apollo y Nomad que usaremos para los casos de uso
De entre las desventajas se puede destacar el hecho de que en general losnodos trabajan con informacioacuten desactualizada lo que conlleva una degradacioacutendel rendimiento en situaciones de alta contienda
Figura 5 Planificador de estado compartido
Planificacioacuten distribuida
En este caso no existe coordinacioacuten entre los distintos planificadores Cadauno de ellos funciona con su propia vista del cluster Las tareas pueden serorganizadas por cualquiera de ellos y desplegadas en cualquier parte del clusteren base a la aleatoriedad y multiplexacioacuten estadiacutestica de los flujos de trabajosin ninguacuten control central
Figura 6 Planificador distribuido
12
5 Herramientas
En la industria comienzan a aparecer soluciones software de coacutedigo abiertoque aglutinan los servicios necesarios para gestionar la infraestructura TI de ma-nera maacutes eficaz El objetivo es doble se busca facilitar la gestioacuten de los recursosde computacioacuten para organizaciones con instalaciones propias mediante su usocon un enfoque cloud esto es desplegar aplicaciones a traveacutes de un conjuntode ordenadores de forma transparente y sin tener en cuenta la infraestructurasubyacente o aprovechar el maacuteximo rendimiento de la infraestructura de losproveedores cloud puacuteblicos de forma que se tiene el maacuteximo control sobre eacutestapero no se depende de las soluciones propietarias permitiendo asiacute despliegueshiacutebridos
Entre estas herramientas se pueden destacar
OpenStack Proyecto desarrollado por la fundacioacuten del mismo nombre paraproporcionar servicios de infraestructuras (IaaS) basado en componentesque se comunican a traveacutes de APIs El componente Magnum incluye mo-tores de orquestacioacuten de contenedores
Kubernetes Sistema de orquestacioacuten de contenedores Docker creado por Goo-gle
CoreOs Sistema operativo basado en Linux disentildeado para despliegues distri-buidos sobre contenedores incluyendo mecanismos de descubrimiento deservicio y comparticioacuten de configuracioacuten
Docker Swarm Herramienta nativa de orquestacioacuten de contenedores Docker
YARN Entorno de gestioacuten de recursos y aplicaciones distribuidas de Hadoopuna libreriacutea software de procesamiento de grandes conjuntos de datos
Como podemos observar existe un gran rango de opciones para gestionar lainfraestructura desde un bajo nivel como puede ser OpenStack hasta Kuberne-tes o Docker Swarm que ofrecen exclusivamente orquestacioacuten de contenedores
En este trabajo se ha optado por Mesosphere DCOS y HashiCorp Nomadque se encuentran en el teacutermino medio su objetivo es proporcionar serviciosde plataforma que permitan la coexistencia dediferentes cargas de trabajo en elcluster
13
51 DCOS
DCOS es un proyecto de coacutedigo abierto7 creado y desarrollado por la empre-sa Mesosphere Se describe como un sistema operativo distribuido que abstraelos recursos de un cluster (capacidad de procesamiento memoria) permite lagestioacuten de muacuteltiples ordenadores de forma transparente y simplifica la instala-cioacuten de aplicaciones distribuidas
Su arquitectura se puede comparar a la de Linux en teacuterminos de nuacutecleo(kernel) y espacio de usuario El primero consta de recursos protegidos a losque no puede acceder el usuario e involucra operaciones de bajo nivel comoasignacioacuten de recursos o aislamiento de procesos En el espacio de usuario seejecutan las aplicaciones y servicios de maacutes alto nivel
Siguiendo con este siacutemil el nuacutecleo de DCOS estaacute basado en Apache Mesosque se explicaraacute en un apartado posterior y el espacio de usuario que estaacute com-prendido por los componentes del sistema esto es las diferentes herramientasque en conjunto conforman DCOS y los servicios encargados de planificar yejecutar las aplicaciones y tareas del usuario
Figura 7 Arquitectura DCOSFuente httpsdcosio
De entre los componentes que conforman DCOS destacan
Admin Router Balanceador de carga central basado en NGINX que dis-pone un proxy entre todos los servicios en el puerto 80 permitiendo sugestioacuten mediante la interfaz graacutefica Ademaacutes se encarga de la autenticacioacutenpara acceder al panel de administracioacuten
Cosmos Gestor de paquetes de las aplicaciones
Diagnostics Se ejecuta en todos los nodos y se encarga de monitorizar elestado de los daemons que sustentan DCOS
7Desde abril de 2016 httpsmesospherecomblog20160419open-source-dcos
14
Exhibitor Gestiona y automatiza el despliegue de ZooKeper la herra-mienta que provee de configuracioacuten centralizada y registro de nombres
Marathon Equivale al proceso init de los sistemas tipo Unix esto es elprimer proceso en ejecucioacuten tras la carga del kernel y que genera los demaacutesprocesos Se encarga de arrancar y monitorizar las aplicaciones y servicios
Mesos-DNS Servicio de DNS interno que define el dominio mesos pa-ra nodos y tareas en el cluster es decir permite resolver nombres conindependencia de la direccioacuten fiacutesica
Minuteman Balanceador de carga integrado a nivel TCPUDP disponiblepara las propias aplicaciones
Por otra parte se definen como servicios a las diferentes aplicaciones dis-tribuidas que DCOS permite instalar en el cluster y que pueden haber sidodesarrollados por la misma empresa Mesosphere o por terceros por ejemploApache Spark Jenkins o Apache Hadoop En la figura 8 se muestra un diagramade los servicios disponibles incluyendo algunos de las aplicaciones distribuidasque soporta DCOS
Figura 8 Servicios DCOSFuente httpsdcosio
511 Apache Mesos
El nuacutecleo de DCOS estaacute basado en Apache Mesos un proyecto de coacutedigoabierto creado por la Universidad de California Berkeley y desarrollado actual-mente por la fundacioacuten Apache Se trata de un administrador de clusters queabstrae los recursos y los dispone para diferentes aplicaciones y entornos de tra-bajo distribuidos (frameworks) mediante una interfaz comuacuten En el momento deredaccioacuten de este proyecto Apache Mesos soportaba una variedad de entornosque abarcaba desde Big Data (Apache Spark Hadoop) hasta bases de datos(Cassandra Hypertable)
15
Arquitectura
Mesos se basa en la asignacioacuten de dos roles diferentes a los nodos
Maestros (Masters) Se encargan de la gestioacuten y reparticioacuten de los recursospara los diferentes entornos de trabajo mediante ldquoofertas de recursosrdquo deacuerdo a los disponibles y a la poliacutetica de asignacioacuten (planificacioacuten en dosniveles)
Esclavos (Slaves) Ordenadores donde se ejecutaraacuten las aplicaciones y cu-yos recursos son ofertados por los maestros
En el caso de fallo del maestro las tareas pueden seguir ejecutaacutendose perono se podraacute asignar nuevos recursos ni tareas por ello pueden existir varios enel cluster para configuraciones de alta disponibilidad pero soacutelo uno orquesta alos esclavos
Para la eleccioacuten del master liacuteder Mesos usa Apache ZooKeeper un proyectode software desarrollado por la misma fundacioacuten cuyo objetivo es proveer deun servicio de configuracioacuten centralizado y registro de nombres8
Por otra parte los entornos de trabajo son los programas que deciden final-mente queacute recursos se van a usar y se encargan de que los esclavos ejecuten lastareas Eacutestos se ejecutan sobre Mesos y constan de dos componentes
Planificador (Scheduler) Optimiza y decide los recursos a utilizar de losofertados informando a los Masters
Procesador (Executor) Ejecuta las aplicaciones o servicios en los esclavos
El objetivo final es conseguir una interfaz liviana tolerante a fallos paracualquier tipo de entorno de trabajo de tal manera que en los esclavos del clusterpuedan ejecutarse simultaacuteneamente tareas con necesidades y duracioacuten diferentesPara ello se basa en dos conceptos asignacioacuten y aislamiento de recursos
Asignacioacuten de recursos
En el cluster pueden coexistir entornos de trabajo con tareas de larga dura-cioacuten y con gran consumo de recursos con tareas cortas que los ocupan y liberancon rapidez El maestro integra un moacutedulo de asignacioacuten de recursos (allocationmodule) que se encarga del algoritmo de distribucioacuten
En el momento de escribir este proyecto estaban desarrollados dos moacutedulosuno mediante el cual el usuario puede asignar prioridades y otro que implementa
8httpszookeeperapacheorg
16
el algoritmo Dominant Resource Fairness9 a grandes rasgos se determina entodos los esclavos la tarea en ejecucioacuten que necesita maacutes recursos y se calcula laproporcioacuten del recurso de mayor peso con respecto al total por ejemplo si unatarea ocupa 2 GB de memoria con respecto a 10 GB totales que tiene el clusterse le asigna un dominant share del 20 la tarea se asignaraacute al nodo con menordominant share
Aislamiento de recursos
Para conseguir que tareas de diferentes entornos de trabajo y con distin-ta naturaleza se ejecuten simultaacuteneamente en un mismo nodo Mesos usa loscontenedores Linux (descritos en la seccioacuten 3)
Funcionamiento
La figura 9 muestra el esquema de la arquitectura de Apache Mesos conalta disponibilidad (tres maestros) y con dos entornos de trabajo ejecutaacutendo-se Hadoop que permite el almacenamiento y procesamiento de gran cantidadde datos para proyectos de big data y un sistema que implementa la interfazsistema de paso de mensajes MPI
Como se puede observar el sistema ZooKeeper elige a un solo maestro comoliacuteder y eacuteste orquesta el cluster comunicando los esclavos con los planificadoresde los diferentes entornos de trabajo Tambieacuten se puede observar como las tareasde los distintos entornos estaacuten distribuidas entre los tres esclavos disponibles
Figura 9 Arquitectura de Apache MesosFuente httpsmesosapacheorg
El proceso de asignacioacuten se realiza como sigue en primer lugar un usuariosolicita la ejecucioacuten de una tarea mediante la interfaz de cada entorno de traba-jo (interfaz graacutefica API HTTP ) De forma paralela un esclavo informa almaestro de los recursos que tiene libres En consecuencia eacuteste se lo notifica almoacutedulo de asignacioacuten que en funcioacuten de su configuracioacuten decide cuaacutento ofertar
9httpspeopleeecsberkeleyedu~aligpapersdrfpdf
17
y a queacute entorno de trabajo y enviacutea la oferta a los planificadores Eacutestos respondenal maestro con queacute recursos ha decidido usar para cada tarea Finalmente lastareas son enviadas al esclavo seleccionado el cual asigna los recursos indicadosal procesador (executor) quien finalmente las ejecuta
Cabriacutea pensar que esta metodologiacutea puede conducir a situaciones en lasque un entorno podriacutea quedarse con tareas sin ejecutarse a la espera de unaoferta satisfactoria para ello Mesos implementa un sistema de filtros medianteel cual los entornos especifican los requisitos miacutenimos que debe cumplir unaoferta por ejemplo se puede especificar en queacute nodos debe desplegarse la tareaEste sistema estaacute disentildeado asiacute con el objetivo de mantener lo maacutes transparenteposible esta herramientas de forma que acepte entornos de trabajo de distintasnaturalezas
512 Ejemplos de uso
Grandes empresas estaacuten usando Apache Mesos con eficacia de acuerdo a susnecesidades e infraestructuras Caben destacar
Ebay En el modelo de implementacioacuten continua en esta empresa10 cadadesarrollador cuenta con su propia instancia que se ejecuta en una maacutequinavirtual dedicada lo que ha conllevado un uso de los recursos poco eficiente Enuna prueba de concepto consiguieron realizar una herramienta de integracioacutencontinua distribuida basada en un cluster con Apache mesos y con el entornoMarathon y Jenkins
Apple Anuncioacute que el motor de su famosa herramienta de asistencia per-sonal para iPhones Siri estaacute desplegada sobre Apache Mesos11 Para ello handesarrollado su propio entorno para facilitar a los ingenieros a desplegar los ser-vicios que la herramienta necesita para resolver las peticiones de los usuarios
Twitter Desarrolloacute su propio entorno denominado Aurora y actualmentegestionan sus recursos y miden el coste de las tareas que los empleados usancon el objetivo de que sean conscientes del gasto que puede suponer un usoinadecuado de la infraestructura12
10httpwwwebaytechblogcom20140404delivering-ebays-ci-solution-with-apache-mesos-part-i11httpwwwbusinessinsidercomapple-siri-uses-apache-mesos-2015-812httpswwwlinuxcomNEWS4-UNIQUE-WAYS-UBER-TWITTER-PAYPAL-AND-HUBSPOT-USE-APACHE-MESOS
18
52 Nomad
Herramienta de coacutedigo abierto de gestioacuten de clusters creada y desarrolladapor Hashicorp13 que permite el despliegue de aplicaciones y procesos de formadistribuida
Las principales diferencias con Apache Mesos a grandes rasgos son
Arquitectura maacutes ligera Nomad soacutelo requiere de un fichero para funcionarejecutaacutendolo con las correspondientes configuraciones en todos los nodosrealiza las funciones de gestioacuten del cluster eleccioacuten de liacuteder planificacioacutende recursos y ejecucioacuten de las tareas
Centro de datos y regiones muacuteltiples Su arquitectura estaacute orientada afacilitar la gestioacuten de diferentes centros de datos geograacuteficamente distri-buidos
Entorno de ejecucioacuten Las tareas se definen y son interpretadas mediantecontroladores integrados en Nomad que se valen de los recursos y herra-mientas de los nodos clientes para ejecutarlas Esta integracioacuten dificultael desarrollo de controladores por parte de terceros a diferencia de Mesosque delega dicha responsabilidad en los entornos de trabajo externos alproyecto
Usa un planificador de estado compartido con respecto a la planificacioacutenen dos niveles de Mesos
Antes de entrar en maacutes detalle en la arquitectura es importante definir lossiguientes teacuterminos
Controlador (Driver) Software que se encarga de interpretar las definicionesde las tareas y ejecutarlas semejante a los procesadores de los entornosde trabajo de Mesos A la hora de redactar este proyecto Nomad contabacon controladores para contenedores Docker virtualizacioacuten de maacutequinasmediante el emulador QEMU aplicaciones java y archivos binarios
Grupo de trabajo (Task Group) Conjunto de tareas que se ejecutan en elmismo nodo cliente
Trabajo (Job) Conjunto loacutegico de tareas y grupos de trabajo que se despliegana la vez
Asignacioacuten (Allocation) Relacioacuten entre un grupo de trabajo y el cliente don-de se ejecuta
Evaluacioacuten (Evaluation) Proceso mediante el cual Nomad planifica y ges-tiona el registro o actualizaciones de los trabajos
13httpswwwhashicorpcom
19
Nomad sigue una arquitectura maestro-esclavo similar a la de Apache Mesosmuacuteltiples servidores acuerdan entre siacute un liacuteder que gestiona la planificacioacuten detareas en los clientes que soacutelo conocen sus asignaciones y las ejecutan
Todos los servidores participan paralelamente en tareas de planificacioacuten derecursos y asignacioacuten de tareas y ademaacutes entre ellos eligen un liacuteder que seencarga de la coordinacioacuten de la suscripcioacuten de los clientes al cluster y de lagestioacuten de las peticiones
Los clientes estaacuten configurados para comunicarse con el servidor usando lla-madas a procedimiento remoto (RPC por sus siglas en ingleacutes) que permite unordenador ejecutar coacutedigo en otra maacutequina Mediante esta tecnologiacutea los nodosclientes avisan de su estado e informa de sus asignaciones recursos y controla-dores disponibles
Existe la posibilidad de gestionar varios centros de datos agrupados en regio-nes eacutestas son independientes pero permite definir tareas o comprobar el estadode todas ellas desde cualquier punto A continuacioacuten se muestra una figura dela arquitectura a alto nivel de esta configuracioacuten
Figura 10 Arquitectura multi-regioacuten en NomadFuente httpswwwnomadprojectio
La herramienta se sustenta sobre tres protocolos fundamentales un protocolode consenso entre los servidores para compartir informacioacuten sobre su estado yel liacuteder un protocolo Gossip para la gestioacuten entre regiones y el planificador detareas
521 Protocolo de consenso Raft
El objetivo es obtener consistencia en un conjunto de nodos que comparteninformacioacuten es decir si un cliente realiza un cambio que todos los nodos veanla misma informacioacuten a la vez y ademaacutes sea tolerante a fallos Para ello se basaen el algoritmo Raft[13] que se detalla brevemente a continuacioacuten
20
Los nodos participantes en el algoritmo pueden estar en tres estados
Liacuteder (Leader) Todos los cambios que realicen en el cluster pasan por eacutel pri-mero
Seguidor (Follower) Nodo pasivo cuya responsabilidad es responder a laspeticiones del nodo liacuteder
Candidato (Candidate) Maacutequina que no ha encontrado liacuteder y solicita sueleccioacuten
Supongamos que tenemos cinco equipos que acaban de arrancar el protocoloEn la figura 11 se observan los nodos y sus respectivos registros a la derecha
Figura 11 Equipos sin consenso ejecutando el protocolo RAFTFuente httpsgithubcomongardieraftscope
Al comenzar todos los nodos son seguidores esperando recibir comunicacioacutende un nodo que actuacutee como liacuteder Cada nodo tiene un tiempo de espera aleatoriodespueacutes del cual si no es informado por un liacuteder pasa a estado candidato y pideel ldquovotordquo al resto de los participantes El algoritmo divide el tiempo en plazos uncandidato pasa a liacuteder si recibe la mayoriacutea de los votos en un plazo determinadoSe define mayoriacutea o cuoacuterum (quorum) comolceil
N2rceil
+ 1 (1)
donde N representa el nuacutemero de nodos
Para el ejemplo propuesto de 5 equipos se requieren de 3 votos Soacutelo losnodos que se encuentren en estado seguidor pueden votar una uacutenica vez a laprimera solicitud que reciba dentro de un plazo
Supoacutengase que el nodo denotado con S1 ha cumplido su tiempo de espera yrealiza la peticioacuten de voto (figura 12) A partir de este momento se pueden dartres casos
La maacutequina gana la eleccioacuten y pasa a ser liacuteder informando al resto
Otro servidor se establece como liacuteder en el mismo momento
Varios nodos pasan a ser candidatos por lo que ninguno consigue los votos
21
Figura 12 Un equipo pasa a estado candidato (RAFT)
Si un candidato recibe un aviso de un liacuteder en el mismo plazo el primeropasa a ser seguidor y se acaba la eleccioacuten de liacuteder
Por otro lado si un equipo candidato no recibe los votos en el plazo y agotasu tiempo de espera avanza al siguiente plazo y repite el proceso de votacioacutenLa tercera posibilidad puede conllevar a un estado indefinido ya que varioscandidatos pueden agotar su tiempo de espera al mismo tiempo y repartir losvotos Para solventarlo el algoritmo establece tiempos de espera aleatorios paralos candidatos
Siguiendo con el ejemplo propuesto el servidor S1 pasa a ser el liacuteder Cadacierto tiempo eacuteste debe realizar avisos a los nodos seguidores para no agotar sutiempo de espera
En este momento el cluster de servidores estaacute en ldquoconsensordquo y la informacioacutenen todos los nodos estaacute actualizada Un cambio en la informacioacuten inicia unproceso de replicacioacuten el liacuteder registra el cambio lo pasa al resto de nodos yuna vez eacutestos responden el cambio se hace efectivo
Supoacutengase que se realiza un cambio en los datos en la figura 13 en la partederecha se observa el cambio en el registro del servidor S1 que informa a losnodos seguidores En consecuencia los nodos registran el cambio y responden aS1
Figura 13 Cambio en un registro (RAFT)
Una vez el cuoacuterum (en el ejemplo tres equipos) informa al liacuteder de que
22
ha registrado el cambio el liacuteder lo hace efectivo en su sistema y notifica a losnodos que hacen lo mismo En la figura 14 el enviacuteo todaviacutea no ha llegado ala maacutequina S3 y se observa que no ha hecho efectivo el cambio (en el registroaparece punteado)
Figura 14 Aprobacioacuten del resto de equipos (RAFT)
Este protocolo funcionaraacute correctamente mientras exista un nuacutemero de nodosen funcionamiento igual o superior al cuoacuterum en el ejemplo propuesto elcuoacuterum es tres por lo que el sistema puede tolerar la caiacuteda de dos de los equipos
522 Protocolo gossip SWIM
Nomad permite la gestioacuten simultaacutenea de varios centros de datos reparti-dos en regiones geograacuteficamente separadas requiriendo de un protocolo ligeroque mantenga a los miembros actualizados sobre los participantes del conjun-to Para ello usa una ligera variante del protocolo SWIM[3] (Scalable Weakly-consistent Infection-style Process Group Membership Protocol) desarrollada porHashiCorp Estaacute clasificado como un protocolo de tipo gossip que debe su nom-bre a la semejanza con coacutemo se distribuye un rumor en una red social
SWIM se sustenta en dos caracteriacutesticas fundamentales la deteccioacuten de fallosy la distribucioacuten de la informacioacuten relativa a los miembros A continuacioacuten sedetalla el funcionamiento de ambos componentes
Deteccioacuten de fallos
Este componente tiene dos paraacutemetros el periodo de protocolo T y el nuacutemerode subgrupos de deteccioacuten de fallos k en los que se dividen los nodos Paracomprobar la comunicacioacuten entre dos maacutequinas usa la utilidad ping basadaen el protocolo ICMP La deteccioacuten de caiacuteda de un servidor sigue el siguientealgoritmo
Durante el periodo T cada miembro Mi de un subgrupo elige otro al azar Mjdel mismo subgrupo y le enviacutea un mensaje ping para comprobar su estado Enel caso de que se cumpla un tiempo de espera determinado por una estimacioacuten
23
del tiempo de ida y vuelta (RTT por sus siglas en ingleacutes) de la red y no hayarespuesta Mi le vuelve a enviar un mensaje ping indirectamente a traveacutes deun nuacutemero k de miembros escogidos aleatoriamente De no recibir ninguna res-puesta Mi establece que Mj ha sufrido un fallo y lo etiqueta como ldquosospechosordquoinformando al componente de distribucioacuten
Figura 15 Diagrama de tiempo del protocolo SWIMFuente httpswwwcscornelledu
Componente de distribucioacuten
Se encarga de informar de cualquier cambio en los miembros a todo el con-junto Los eventos de nodo caiacutedo y la unioacuten o disociacioacuten de un miembro setransmiten a todos los servidores para que actualicen sus lista Para distribuirla informacioacuten a todos los nodos se podriacutea usar el meacutetodo de multicast perosuele estar deshabilitado Por ello se utiliza una teacutecnica de transmisioacuten denomi-nada Piggybacking mediante la cual se adjunta a los propios mensajes PINGy ACK del algoritmo la informacioacuten a distribuir reduciendo asiacute la congestioacutenen la red
523 Planificacioacuten
Proceso encargado de distribuir las tareas entre los nodos clientes de acuerdoa su estado
El planificador de Nomad estaacute basado en las publicaciones de Google sobresus herramientas de gestioacuten de clusters Borg y Omega14 y entiende los trabajosdescritos por el usuario como un estado deseado es decir su despliegue en unamaacutequina cliente de forma correcta y los clientes como el estado actual esto eslo que se encuentra en ejecucioacuten El registro actualizacioacuten o cancelacioacuten de un
14httpresearchgooglecompubspub43438html
24
trabajo asiacute como el fallo de un nodo cliente implican un cambio de estado atramitar por el sistema lo que se define como evaluacioacuten (evaluation) Esto uacutelti-mo supone comparar el estado actual (clientes) con el estado deseado (conjuntode trabajos registrados) y enviarlos a los planificadores correspondientes que seencargaraacuten de asignar las tareas a los nodos clientes
Figura 16 Procedimiento de asignacioacuten en NomadFuente httpswwwnomadprojectio
En la figura 16 se observa el flujo de trabajo en el que las distintas evalua-ciones se encolan en el evaluation broker que se ejecuta en el servidor liacuteder ygestiona las evaluaciones pendientes asignaacutendoles prioridades
A continuacioacuten los nodos servidores ejecutan los scheduling workers queprocesan las evaluaciones llamando a los distintos planificadores que generanun plan de asignacioacuten esto es un conjunto de relaciones entre las tareas y losnodos clientes donde se ejecutaraacuten Este proceso se divide en dos fases primerose descartan aquellos clientes que no cumplan los requisitos y posteriormentese asigna una calificacioacuten al resto Se selecciona el nodo con mayor puntuacioacuteny se encola el plan en el gestor que se ejecuta en el servidor liacuteder Existen tresplanificadores de acuerdo al tipo de trabajo
Service Incluye aquellos trabajos que estaacuten destinados a ejecutarse en un pe-riacuteodo largo de tiempo Para realizar las asignaciones el planificador evaluacuteala mayor parte de los nodos y usa una versioacuten del algoritmo Best fit in-fluenciada por el trabajo de Google en su herramienta Borg Se trata deun algoritmo de planificacioacuten que sacrifica tiempo a cambio de maximizarel rendimiento de los clientes asignando la tarea a la maacutequina que tengala mayor carga de trabajo con el objetivo de reducir equipos en funciona-
25
miento
Batch Tareas que incluyen listas de comandos en general de menor duracioacuteny que no requieren interaccioacuten con el usuario Se vale del algoritmo deSparrow desarrollado por la universidad de Berkeley15 para limitar losnodos clientes a evaluar
System Trabajos destinados a ejecutarse en todos los nodos incluso los que seunen al cluster posteriormente
Core Mantenimiento interno de Nomad
Una vez se ha realizado el proceso de planificacioacuten el nodo liacuteder lo registra enla cola de planes (plan queue) que se encarga de asignarles prioridad y manejarcondiciones de carrera es decir que no accedan a los recursos de los clientes sincontrol y evitar que eacutestos superen su capacidad
La maacutequina liacuteder del conjunto puede de este modo aceptar una asignacioacuteny ser ejecutada por los clientes o por el contrario rechazaacutersela al planificadorlo que implicariacutea realizar un plan parcial o totalmente nuevo
Finalmente el estado de las evaluaciones se actualizan y los clientes soninformados de las asignaciones ejecutaacutendose las tareas
15httppeopleeecsberkeleyedu~keopublicationssosp13-final17pdf
26
6 Casos de uso y despliegue
Con el objetivo de mostrar las posibles utilidades que este tipo de sistemaspueden tener en las infraestructuras TI actuales se han desplegado las dos he-rramientas en la nube Microsoft Azure usando su servicio cloud de instancias demaacutequinas virtuales Linux para simular un conjunto de ordenadores conectadosentre siacute por una red LAN Sobre ellas se ha implementado dos casos de usouna aplicacioacuten web con una arquitectura con cierta orientacioacuten a microserviciosy un sistema de integracioacuten continua
El coacutedigo y todos los ficheros de configuracioacuten se pueden encontrar en elrepositorio del proyecto en GitHub16
61 Aplicacioacuten Web
Se busca simular el proceso de adaptacioacuten de una solucioacuten web para su des-pliegue en un sistema distribuido con las herramientas anteriormente descritascon el objetivo de aumentar tanto su escalabilidad como disponibilidad medianteredundancia
Se ha partido de una aplicacioacuten ya existente17 un servicio de almacenamien-to y reproduccioacuten de canciones A grandes rasgos este servicio permite crearusuarios subir canciones con sus respectivas portadas tener playlists propias yescuchar las canciones a traveacutes de un navegador web
La solucioacuten estaacute dividida en 4 partes (figura 17)
Una vista web con la loacutegica
Un almacenamiento conectado en red (NAS por sus siglas en ingleacutes)
Una API REST para gestionar las peticiones al almacenamiento
Base de datos NoSQL basada en MongoDB
La nueva tendencia de los proyectos web es su implementacioacuten en contene-dores Docker ya que facilitan su portabilidad y ofrecen un procedimiento dedespliegue raacutepido sobre todo a la hora de desarrollar y realizar pruebas en en-tornos de produccioacuten simulados Por ello en este caso se va a hacer uso de los
16httpsgithubcomAntonioAlfrzCloud-Orchestrators17httpsgithubcomsonsoleslpCDPSfy
27
motores de orquestacioacuten de contenedores de ambas herramientas Marathon enDCOS y el controlador Docker en el caso de Nomad
Figura 17 Arquitectura aplicacioacuten web
A continuacioacuten vamos detallar el despliegue en ambas herramientas de es-ta solucioacuten y observar tanto queacute dificultades se encuentran como que ventajasofrecen El objetivo final es adaptar el proyecto modificaacutendolo lo menos posiblecon objeto de analizar la capacidad de estas herramientas para desplegar cual-quier aplicacioacuten sin que eso conlleve la modificacioacuten de la arquitectura de eacutestaes decir que no sea dependiente del entorno
611 DCOS
Se ha descrito DCOS como una herramienta que se despliega sobre un con-junto de ordenadores y que permite instalar gestionar el despliegue de sistemasdistribuidos
Microsoft Azure cuenta con una plantilla para desplegar en su servicio cloudun cluster de maacutequinas virtuales con DCOS ya instalado que cuenta con
Maacutequinas maestras (1 3 o 5 a seleccionar por el usuario) configuradascomo un conjunto de disponibilidad esto eso Azure da ciertas garantiacuteasde que al menos una maacutequina estaraacute en funcionamiento
Maacutequinas agentes Por motivos de seguridad se distinguen dos roles
bull Nodos privados solo accesibles desde la red interna y configuradoscomo un conjunto de escala un recurso de Azure para gestionar ydesplegar maacutequinas con configuraciones ideacutenticas para permitir unraacutepido escalado
bull Un equipo conectado accesible desde Internet a travntildees de un balan-ceador de carga puacuteblico y situado en una subred externa
28
Dos balanceadores de carga
bull La interfaz puacuteblica del cluster que se conecta con el cliente puacuteblicobull Acceso a los equipos maestros para el administrador que soacutelo permiteconexioacuten mediante SSH y credenciales
Almacenamiento para todas las maacutequinas
Configuraciones necesarias de red y seguridad
En la figura 18 se observa un diagrama de la infraestructura
Figura 18 Infraestructura en Azure
El primer obstaacuteculo es la persistencia de estado de la aplicacioacuten que seconsigue gracias a una base de datos no relacional basada en MongoDB asiacutecomo el almacenamiento de las canciones Para implementarla tenemos variasposibilidades
Montar un sistema externo de almacenamiento conectado en red en todoslos agentes donde se ejecuten las tareas de esta manera si una tarea pasade un nodo a otro por cualquier motivo puede tener acceso a los mismosficheros (opcioacuten del caso de uso original)
Implementar un sistema de ficheros distribuidos en los agentes
Usar los servicios de almacenamiento de las nubes puacuteblicas
Aprovechar el sistema de voluacutemenes persistentes de Apache Mesos Eacutestepermite reservar recursos de un agente de forma que al arrancar una tarease crea un volumen independiente del ciclo de vida de eacutesta con ello esosrecursos donde se ha almacenado la informacioacuten pueden volver a ofrecerseal mismo entorno de tal manera que otra tarea pueda acceder a ella
DCOS aprovecha este sistema de voluacutemenes persistentes y permite instalarbases de datos distribuidas como ArangoDB o Apache Cassandra sin embargoesto implicariacutea modificar todo el coacutedigo referente al modelo de la base de datos
29
Por motivos de eficiencia y latencia asiacute como de una mayor gobernabilidadde los datos la mejor opcioacuten es usar el recurso de voluacutemenes persistentes queofrece Apache Mesos ya que de esta manera se gestionariacutea la aplicacioacuten completamediante una uacutenica herramienta Sin embargo esto implica que la informacioacutense encuentra exclusivamente en el agente donde se haya ejecutado la tarea y porlo tanto se sigue requiriendo de software externo para distribuir la informacioacutenpara que se accesible para todos los agentes A la hora de realizar este proyectose encontraba en desarrollo Flocker una solucioacuten desarrollada por ClusterHQque permite compartir los voluacutemenes de Docker a traveacutes de un cluster quesi bien es compatible con el planificador de Mesos el proyecto se encontrabatodaviacutea en fases tempranas de desarrollo y los sistemas de almacenamiento quesoporta quedaban fuera del aacutembito de este trabajo
Por todo ello dado que las maacutequinas se han desplegado en la nube puacuteblicade Azure se decidioacute usar su servicio de almacenamiento de objetos para lascanciones y otra maacutequina para desplegar MongoDB y asiacute mantener el modelode datos original de la aplicacioacuten La diferencia del almacenamiento de obje-tos con respecto a nivel de fichero es que el primero no tiene jerarquiacutea paraorganizar los archivos eacutestos se guardan como objetos (con sus metadatos) enun mismo espacio soacutelo diferenciaacutendose por un identificador uacutenico esto implicaentre otras cosas que se puede acceder a un fichero dado uacutenicamente su IDindependientemente de la localizacioacuten fiacutesica de eacuteste facilitando pues la gestioacuteny el desarrollo
El coacutedigo del proyecto se ha modificado en los siguientes apartados
Las direcciones de la base de datos y los balanceadores de carga asiacute comosus puertos estaban originalmente fijos Se han configurado como variablesde entorno para facilitar el descubrimiento del servicio y hacer transpa-rente la aplicacioacuten al entorno de despliegue
La API REST se ha adaptado al almacenamiento en Azure en vez de enlocal
Estas modificaciones no suponen un cambio sustancial pero permiten separala persistencia de las tareas ejecutadas por DCOS lo que facilita en granmedida su ejecucioacuten al ser totalmente sin estado y ademaacutes implican tenerlos datos bajo un mayor control
Para la orquestacioacuten de contenedores se va a usar el entorno Marathondesarrollado tambieacuten por Mesosphere Eacuteste se puede usar a traveacutes de una interfazgraacutefica la interfaz de liacutenea de comandos (en lo que sigue CLI por sus siglas eningleacutes) de DCOS o con su API HTTP
Primero se han publicado la imaacutegenes de los contenedores que encapsulanla interfaz web y la api de la aplicacioacuten en el repositorio puacuteblico DockerHub
Los despliegues en este entorno se describen mediante ficheros JSON en losque se detalla entre otras opciones la imagen del contenedor los puertos a usar
30
los recursos que debe ocupar en un nodo o las instrucciones de monitorizacioacuten
Para el servicio de descubrimiento DCOS ofrece la posibilidad de asignardirecciones IP virtuales (VIP por sus siglas en ingleacutes) a tareas que se compartenen todos los nodos DCOS lleva integrado un balanceador de carga a nivel TCP(el componente denominado Minuteman) que balancea entre las direccionesvirtuales de las tareas y todas las instancias de eacutestas a lo largo del cluster Estoes necesario por dos motivos equilibrar la carga de los equipos con el fin deevitar un punto de uacutenico fallo mediante redundancia y evitar la contienda dedirecciones al ejecutar las tareas en puertos aleatorios
Este balanceador de carga estaacute basado en el trabajo de Michael Mitzenma-cher The Power of Two Choices in Randomized Load Balancing18 A grandesrasgos el algoritmo mantiene una media moacutevil exponencial de latencias paracada destino (backend) ademaacutes de las caiacutedas consecutivas Si un destino noresponde a una negociacioacuten en tres pasos (three way handshake) de forma con-secutiva en un periodo inferior a 5 ms se considera caiacutedo El algoritmo iterasobre los destinos disponibles en base a su histoacuterico de fallos y escoge dos deforma aleatoria de los cuales coge el de mejor meacutetrica
Las direcciones virtuales soacutelo se pueden resolver dentro del cluster porello para implementar la interfaz puacuteblica de la aplicacioacuten esto es el balancea-dor de carga de la interfaz web usaremos un paquete de DCOS denominadomarathon-lb un balanceador basado en HAProxy y adaptado por MesosphereEn este caso equilibra la carga de todas instancias de las tareas ejecutadas porel entorno Marathon por sus etiquetas y permite ademaacutes definir como puntode entrada muacuteltiples hosts virtuales definidos por sus nombres completos dedominio (FQDN por sus siglas en ingleacutes) en nuestro caso la interfaz puacuteblicadel balanceador de Azure para los agentes
Por motivos de seguridad todas las tareas se ejecutan en los agentes privadoses decir los que son exclusivamente accesibles desde la red interna Por su partemarathon-lb se ejecuta en el agente puacuteblico que cuenta con IP puacuteblica y lospuertos 80 (HTTP) y 8080 abiertos de forma que la aplicacioacuten sea accesibledesde Internet Esto es posible debido a que Apache Mesos permite reservarrecursos mediante roles asignados a nodos para un uso especiacutefico De esta formala arquitectura vista desde la aplicacioacuten quedariacutea como en la figura 19
18httpswwweecsharvardedu~michaelmpostscriptstpds2001pdf
31
Figura 19 Arquitectura de la aplicacioacuten web en DCOS
Ejecucioacuten
A la hora de desplegar la aplicacioacuten DCOS puede gestionarse medianteuna interfaz graacutefica o una interfaz de liacutenea de comandos La primera se accedea traveacutes de un navegador web en el puerto 80 (HTTP) y permite instalar losentornos disponibles observar el estado de los nodos y las tareas que se estaacutenejecutando y los ficheros de registros que eacutestas generan
La CLI permite el control desde un nodo o una maacutequina remota (suponiendoque los maestros tienen IP puacuteblica y el puerto 80 abierto) ya que DCOS tieneun sistema de autorizacioacuten que permite tener una interfaz puacuteblica con ciertasgarantiacuteas de seguridad
Por su parte cada entorno de trabajo puede ser controlado por la CLI peroademaacutes cuenta con sus propias interfaces Marathon expone una API HTTPen el puerto 8080 de la direccioacuten puacuteblica de los maestros del cluster asiacute comootra interfaz graacutefica Para desplegar un contenedor se podriacutea usar la CLI
$ dcos marathon app add lt f i l e j songt
O la API HTTP
$ cu r l minusX POST http lt ip_maestro gt8080v2apps minusd ltf i l e jsongt minusH Contentminustype app l i c a t i o n j son
32
612 Nomad
La arquitectura de Nomad es maacutes sencilla ya que solo requiere de un ficheroejecutable en todos los nodos para funcionar Si DCOS es la base de instala-cioacuten de entornos de terceros Nomad integra todas las funcionalidades baacutesicasesto es gestor de recursos planificador y ejecutor en los nodos cliente Estaherramienta cuenta con un menor tiempo de desarrollo y en el momento deescribir este documento cuenta exclusivamente con los siguientes controladoresen comparacioacuten con los entornos de DCOS
Motor Docker es decir funcioacuten de orquestacioacuten de contenedores
Ejecucioacuten de archivos binarios como comandos de Shell
Ejecucioacuten de aplicaciones Java
Virtualizacioacuten de maacutequinas mediante tecnologiacutea QEMU
Todos ellos necesitan que la tecnologiacutea subyacente esteacute instalada en las maacute-quinas clientes (Docker Java QEMU) Actualmente no permite el registro decontroladores por parte de terceros aunque estaacute planificado en un futuro ofreceruna interfaz para su desarrollo
Nomad no cuenta con el servicio de descubrimiento sin embargo puede inte-grarse con la herramienta Consul desarrollada por la misma empresa Por otrolado para el balanceo de carga usaremos un contenedor Docker con HAProxyuna herramienta de coacutedigo abierto que ofrece tanto servicios de proxy como debalanceador y cuyos ficheros de configuracioacuten completaremos con el proyectoConsul Template19
Consul
Consul sigue la misma arquitectura que Nomad es decir un nodo servidorque orquesta un conjunto de maacutequinas clientes y permite a los procesos que seejecutan en los equipos definirlos como servicios ofreciendo diversas caracteriacutes-ticas entorno a estos de los cuales vamos a usar dos
Descubrimiento de servicio Las maacutequinas clientes publican en el cataacutelogode servicios las tareas en ejecucioacuten y Consul les asigna nombres de dominioaccesibles por todos los miembros del cluster a traveacutes de la interfaz DNSincluida en esta herramientaConsul se integra con Nomad de forma que todas las tareas que se ejecu-ten en la segunda son automaacuteticamente publicados como servicios de laprimera de esta manera no hace falta conocer la direccioacuten de la maacutequinacliente donde se esteacute ejecutando el proceso ya que se puede acceder a eacutela traveacutes de su nombre de dominio de forma transparente Por ejemplo si
19[httpsgithubcomhashicorpconsul-template]
33
ejecutamos una tarea con ID web en el puerto 8080 se puede acceder aella en la direccioacuten webserviceconsul8080Para que las direcciones propias de Consul las resuelva su propio DNS y noel que esteacute asignado por defecto en la maacutequina usaremos la herramientadnsmasq20 que permite especificar la direccioacuten de un servidor DNS paraconsultas de direcciones especiacuteficas
Monitorizacioacuten Permite realizar comprobaciones del servicio y seguir su esta-do Aprovecharemos esta funcionalidad tanto para definir el propio procesode Nomad como servicio de Consul como las tareas desplegadas
HAProxy + Consul Template
HAProxy es una solucioacuten versaacutetil de coacutedigo abierto que ofrece solucionesde balanceo de carga y proxy Existen otras herramientas en el mercado comoNGINX o ldirectord sin embargo HAProxy suponiacutea una solucioacuten sencilla deconfigurar para mostrar el caso de uso
El uso de estas herramientas se debe a dos motivos para que no existacontienda con respecto a los puertos de los clientes usados por las tareas eacutestos sevan a asignar de forma dinaacutemica lo que en principio implicariacutea que la aplicacioacutendeberiacutea realizar consultas DNS de tipo SRV (que incluye puertos) a la interfazde Consul y balancear la carga entre tareas por redundancia y capacidad
Como la direccioacuten IP y puerto son variables cada vez que las tareas seactualicen o se reasignen es necesario volver a configurar HAProxy de formamanual Por ello HashiCorp ha desarrollado un programa denominado Con-sul Template que realiza peticiones sucesivas a la interfaz HTTP de Consul delas direcciones fiacutesicas de un servicio y reinicia automaacuteticamente el proceso deHAProxy Asiacute definiendo estas tareas como servicios Consul podremos tantomonitorizarlas como escalar las tareas dinaacutemicamente sin necesidad de cambiarel balanceador A partir del contenedor Docker oficial de HAProxy se ha desa-rrollado otro con la configuracioacuten baacutesica y con Consul Template para desplegarlocomo una tarea en Nomad
Despliegue
Se ha usado el mismo coacutedigo que en el apartado anterior con la persistenciaen el servicio de almacenamiento de Azure Desde la perspectiva del hardwarese implementaraacute la misma infraestructura que en el caso de DCOS (figura 18)estos es definiremos dos tipos de maacutequinas clientes un agente que se conectaraacutecon el balanceador de carga con nombre de dominio puacuteblico y donde se desple-garaacute el balanceador de carga de la vista web y agentes privados no accesiblesdesde fuera del cluster y donde se ejecutaraacuten el resto de tareas en la red inter-na La principal diferencia radica en las tareas que ejecutan HAproxy y ConsulTemplate que sustituye a las direcciones IP virtuales que ofrece DCOS
20httpwwwthekelleysorgukdnsmasqdochtml
34
Figura 20 Despliegue en Azure de Nomad+Consul
Cabe matizar que los balanceadores basados en HAProxy se implementanpor necesidad de la aplicacioacuten para el descubrimiento del servicio a diferenciade los de Azure que se implementan por motivos de seguridad y escalabilidaddel cluster en siacute
Configuracioacuten Nomad
Los ficheros de configuracioacuten de las maacutequinas maacutester y cliente son similaresy comparten la mayoriacutea de las opciones como por ejemplo el nombre del nodoo la interfaz de red donde escucha Nomad las peticiones Sus opciones son engeneral auto-explicativas sin embargo existen dos detalles que matizar
El proceso de Nomad escucha las peticiones tanto de los protocolos deconsenso como del usuario a traveacutes de una interfaz de red que se debeindicar en el fichero de configuracioacuten
En el caso de los clientes se deben indicar las direcciones de los servidoresdel cluster sin embargo se trata de un sistema dinaacutemico en el que losnodos pueden sufrir errores y cambiar de direccioacuten Por ello se ha definidoNomad como un servicio de Consul y asiacute poder definir la direccioacuten de losservidores como un nombre de dominio no por su direccioacuten fiacutesica que elservidor DNS de Consul se encargaraacute de resolver
Por defecto Nomad usa los siguientes puertos
API HTTP 4646 Peticiones HTTP y recepcioacuten de oacuterdenes mediante laliacutenea de comandos
RPC 4647 Protocolo de consenso entre los nodos del cluster
Serf 4648 Protocolo de gossip entre los servidores de los centros de datosgobernados por Nomad
35
Los dos uacuteltimos deben ser interfaces alcanzables por otros nodos sin embargo laAPI HTTP por motivos de seguridad deberiacutea ser local ya que en caso contrariocualquier persona con acceso a ella tiene el control sobre la herramienta Eacutestasolo deberiacutea estar accesible en un servidor o gestionarlo mediante una terminalSSH por ejemplo En este trabajo al ser una prueba de concepto se ha abiertoen todos los nodos
Trabajos de Nomad
Las tareas se detallan en ficheros con formato HashiCorp Configuration Lan-guage un derivado del formato JSON creado por la empresa que le da nombrecompatible con eacuteste y que permite comentarios
En estos ficheros se puede definir
La regioacuten y el centro de datos donde se ejecutaraacute (Nomad permite lagestioacuten de centros de datos geograacuteficamente distribuidos en regiones)
La poliacutetica de actualizacioacuten de la tarea
Grupo de tareas esto es que se ejecutaraacuten en el mismo nodo
El nuacutemero de grupos a ejecutarescalar asiacute como los liacutemite que debencumplir los nodos asignados
La poliacutetica de reinicio ante fallo o error
Tareas El controlador su configuracioacuten los paraacutemetros del servicio aso-ciado a registrar en Consul asiacute como los recursos que consume (puertosmemoria)
En nuestro caso usamos sobre todo el controlador Docker esto eso orques-tacioacuten de contenedores en los nodos clientes y tres de sus opciones
Imagen del contenedor Se han subido todas las imaacutegenes del proyecto a Doc-ker Hub donde por defecto se busca la imagen
Puertos Los puertos a usar por el contenedor que pueden ser estaacuteticos asigna-dos por el usuario o dinaacutemicos siendo Nomad el que se encarga de mapearun puerto libre del nodo cliente al expuesto por el contenedor
Servidores DNS Como usamos la interfaz DNS de Consul como descubri-miento de servicio se debe configurar el contenedor para que use cualquiernodo del cluster como servidor DNS
Configuracioacuten Consul
Al ser desarrolladas por la misma empresa los ficheros de configuracioacuten deConsul y Nomad comparten muchas opciones Consul tambieacuten acepta peticionesa traveacutes de una interfaz de red siendo los puertos usados por defecto
36
RPC 8300 8400 Maneja la peticiones del resto de nodos y usuarios
Serf 8301 8302 Protocolo gossip
HTTP API 8500
HTTPS API Desactivada por defecto
Interfaz DNS 8600
Se debe asignar a los protocolos internos del cluster esto es RPC y Serf unainterfaz alcanzable por los nodos y por el contrarioasignar a los dos uacuteltimos ala interfaz de loopback por motivos de seguridad
Cabe destacar que Consul tambieacuten cuenta con una interfaz graacutefica que per-mite ver el estado de los equipos y los servicios registrados y que se encuentra enel mismo puerto que la API HTTP en la direccioacuten httpIP_EQUIPO8500ui
Ejecucioacuten
Tanto Nomad como Consul requieren de la ejecucioacuten de un fichero en todoslos nodos integrantes del cluster Como prueba de concepto se ha decidido usardos servidores para ambos aunque cabe matizar que es un nuacutemero ineficienteya que la caiacuteda de uno de ellos supondriacutea la peacuterdida del cuoacuterum y por tantodel consenso del cluster
En primer lugar se arrancan los servidores que son los encargados de ejecu-tar el protocolo de consenso y gestionar el cluster y a continuacioacuten los clientesque no tienen praacutecticamente estado y dependen de los servidores
En el caso de Consul se debe indicar el directorio donde se guardan losficheros que describen los servicios asiacute como el archivo que especifica el resto delas opciones
1 Se inicia el primer servidor en uno de los equipos
$ consu l agent minuscon f i gminusd i r e t c consu l d s e r v i c e s minuscon f i gminus f i l e consu l_server j son
2 Los siguientes equipos deben unirse al anterior por lo que antildeadimos elargumento join con la direccioacuten del primer servidor Para el caso de otrosservidores
$ consu l agent minuscon f i gminusd i r e t c consu l d s e r v i c e s minuscon f i gminus f i l e consu l_server j son minus j o i n ltIP_servidor1gt
37
Una vez los servidores han alcanzado el consenso y elegido un liacuteder en losclientes
$ consu l agent minuscon f i gminusd i r e t c consu l d s e r v i c e s minuscon f i gminus f i l e c on su l_c l i en t j son minus j o i n ltIP_cualquierServ idorgt
El proceso para iniciar Nomad es igual y los comandos similares sin embargoya no es necesario indicar una direccioacuten IP fija en los equipos sino el nombre dedominio del servicio de Nomad registrado por Consul En el primer servidor
$ nomad agent minusc on f i g nomad_server j son
Y el resto de equipos (con su fichero de configuracioacuten correspondiente)$ nomad agent minusc on f i g nomad_server j son minus j o i n nomad s e r v i c e consu l
Por uacuteltimo para desplegar la aplicacioacuten web se han escrito tres ficherosque detallan las tareas de la interfaz web API y los balanceadores de cargaMediante la CLI
$ nomad run minusaddress=http lt ip_c lus te r gt4646 lt f i l e hclgt
O mediante la API HTTP de Nomad$ cu r l minusX POST minusd ltf i l e hclgthttp lt ip_c lus te r gt4646 jobltjob_namegt
Ansible
Como se puede comprobar con el aumento del nuacutemero de equipos pasa aser inviable manejar todos los nodos a traveacutes de terminal Ademaacutes como seha comentado con anterioridad Nomad requiere que en los nodos clientes es-teacuten instalados las herramientas que soporten las tareas por ejemplo el motorde Docker Por ello para facilitar tanto el arranque como la instalacioacuten de lasdependencias vamos a usar Ansible una herramienta de coacutedigo abierto desarro-llada en Python que permite gestionar configuraciones aprovisionar recursosdespliegue de aplicaciones de forma automaacutetica
A grandes rasgos esta herramienta funciona mediante ficheros en formatoYAML denominados play-books que describen un conjunto de pasos a ejecutaren una lista de equipos remotos Estos pasos son ejecutados por moacutedulos inde-pendientes a traveacutes de SSH es decir en cualquier ordenador con conexioacuten a los
38
hosts dado su contrasentildea o clave puacuteblica puede arrancar el script y realizariacutealos pasos de forma remota gestionando el cluster desde un solo equipo
Se han desarrollado guiones para lo siguiente
Descarga de los binarios de Nomad y Consul en todos los nodos copiade los ficheros de configuracioacuten baacutesicos y modificarlos de acuerdo a cadanodo (nombre del equipo direccioacuten IP)
Instalacioacuten de las dependencias
Arranque de Nomad y Consul
Ansible extiende su funcionalidad a traveacutes de moacutedulos independientes que per-miten por ejemplo instalar paquetes mediante herramientas de gestioacuten de pa-quetes (APT yum) aprovisionar automaacuteticamente maacutequinas virtuales de Ama-zon EC2
Algunas opciones de los ficheros de configuracioacuten de Nomad y Consul sondependientes del nodo particular por ejemplo la interfaz de red Para estetrabajo se ha realizado un moacutedulo para modificar los ficheros de configuracioacutende forma automaacutetica En el repositorio del proyecto se encuentra una carpetadonde se encuentran todos los ficheros necesarios para desplegar un clustertotalmente funcional solo requiere de una liacutenea de terminal con Ansible
$ ans ib l eminusplaybook minus i hos t s minusk ltssh_passgt minusu ltnode_usergt s i t e yml
39
62 Servicio de integracioacuten continua
Se ha implementado un sistema de integracioacuten continua que permite ejecu-tar tareas de compilacioacuten y pruebas de forma distribuida aumentando asiacute elrendimiento de los equipos En primer lugar se detallaraacute los motivos por los quepuede resultar beneficioso para las empresas una implementacioacuten de este tipo alo que seguiraacute los detalles del despliegue
621 DevOps
Metodologiacutea que defiende la comunicacioacuten y colaboracioacuten entre desarrolla-dores de software y los profesionales de operaciones a lo largo de todo el ciclo devida de una aplicacioacuten Estaacute muy relacionado con el desarrollo aacutegil de softwareesto es un enfoque para los proyectos que defiende el desarrollo iterativo e in-cremental donde los requisitos y soluciones evolucionan con el tiempo seguacuten lanecesidad del proyecto DevOps extiende esta filosofiacutea a todas los componentesde un servicio incluyendo sistemas y operaciones
Se trata de un concepto que cada organizacioacuten o empresa adapta a suspropias necesidades y procesos de negocio en este proyecto nos vamos a centraren la integracioacuten continua una praacutectica fundamental tanto del desarrollo aacutegilcomo de esta filosofiacutea
622 Integracioacuten Continua
Se define como una praacutectica de desarrollo software donde los miembros delequipo ponen en comuacuten su trabajo frecuentemente al menos una vez al diacutea21Cada integracioacuten se verifica con una compilacioacuten automaacutetica que incluye laejecucioacuten de pruebas para detectar errores de integracioacuten tan pronto como seaposible
Desde el punto de vista operativo esto supone automatizar la configuracioacutende equipos o el despliegue de maacutequinas virtuales donde compilar el proyecto yejecutar las pruebas y posteriormente eliminarlas Este flujo de trabajo se vebeneficiado en entornos distribuidos ya que el objetivo del desarrollador es com-probar el resultado de las pruebas raacutepidamente sin preocuparse del despliegueo los propios equipos
Para esta prueba de concepto vamos a usar Jenkins un servidor de integra-cioacuten continua escrito en Java que nos permite definir trabajos que contendraacutenla descripcioacuten tanto del entorno como su ejecucioacuten
Este sigue una estructura maestro-esclavo muy similar al de los gestores declusters usados en este proyecto el maestro contiene toda la loacutegica del servicio
21httpmartinfowlercomarticlescontinuousIntegrationhtml
40
trabajos autenticacioacuten y los esclavos son los encargados de la ejecucioacuten ensiacute Jenkins tiene varias viacuteas para aprovisionar los uacuteltimos
Mediante SSH
Interfaz graacutefica
Desarrollar un script propio
Ejecucioacuten de un fichero java
La ventaja de usar planificadores es que el despliegue de esclavos es dinaacutemicoes decir no tener una maacutequina especiacuteficamente configurada para ello DCOS yNomad se encargaraacuten de configurar estos despliegues en sus maacutequinas y poste-riormente eliminarlos Para ello se ha usado la uacuteltima opcioacuten definiendo tareasque descarguen el fichero java Con todo ello se consigue un entorno de inte-gracioacuten continua eficiente que ademaacutes permite la ejecucioacuten de otros servicios deforma independiente
Jenkins permite la creacioacuten de plugins que extienden sus funcionalidadesTanto Nomad22 como Apache Mesos cuentan con uno que permite su integra-cioacuten
Para esta prueba se va a usar el mismo proyecto que para el caso de usode orquestacioacuten de contenedores la aplicacioacuten web al que se le ha antildeadido untest para comprobar que se conecta correctamente a la base de datos medianteMocha un framework de Nodejs Por otro lado se antildeade el plugin de git ya queel coacutedigo se obtiene de GitHub el repositorio remoto de control de versiones delproyecto
El proceso general de ejecucioacuten seriacutea como sigue
1 Se ejecuta el maestro de Jenkins como tarea Docker partiendo de la imagenoficial
2 Al arrancar un trabajo se manda una tarea a los planificadores que laasignaraacuten a un nodo cliente Esta tarea consiste en la descarga del ficherode configuracioacuten Java y arrancarlo configurando el equipo como un clientede Jenkins temporalmente
3 Jenkins ejecuta el trabajo en el nuevo cliente en este caso iniciar la apli-cacioacuten web iniciar las pruebas y generar un informe
4 Se elimina el cliente
A continuacioacuten se detallan los matices de cada herramienta a la hora de imple-mentar este servicio
22Desarrollado por Ivo Verberk httpwwwivoverberknl
41
623 Jenkins con Nomad
El plugin permite la ejecucioacuten del fichero Java mediante dos controladorescontenedores Docker y Java En este proyecto nos hemos decantado por el pri-mero ya que nos ahorra instalar la maacutequina virtual de java en todos los nodoscliente Por ello se ha construido un contenedor base con Java para la ejecucioacutendel fichero de configuracioacuten y Nodejs para lanzar la aplicacioacuten web
El plugin se configura con la direccioacuten IP del cluster y el contenedor queejecuta el esclavo Jenkins Por su parte el trabajo en Jenkins se define conel repositorio en GitHub donde se aloja el coacutedigo del proyecto a probar y loscomandos a ejecutar en este caso npm update y npm test
624 Jenkins con DCOS
En el caso de DCOS su sistema de paquetes incluye Jenkins por lo queal instalarlo ya se tiene la configuracioacuten de Mesos totalmente funcional Sinembargo para ejecutar la aplicacioacuten en particular y las pruebas se requiere deNodejs en los equipos esclavos por ello debemos antildeadir un plugin de Jenkinsque permite instalar este entorno antes de ejecutar el trabajo Una vez hechoesto soacutelo queda definir la tarea igual que en el caso anterior
Cabe destacar que Mesosphere tambieacuten ha desarrollado un plugin que per-mite hacer despliegues en Marathon de tal manera que permitiriacutea con cadacommit del coacutedigo compilar la imagen del contenedor Docker y desplegarlaautomaacuteticamente aunque en este proyecto no se ha hecho pruebas de esta fun-cionalidad
42
7 Escalando la infraestructura
Uno de los factores clave que se busca a la hora de implementar sistemasdistribuidos es el poder escalar la infraestructura de forma maacutes sencilla estoes detectar que las maacutequinas estaacuten alcanzando el liacutemite de su capacidad yaumentar eacutesta ya sea mejorando sus caracteriacutesticas teacutecnicas o antildeadiendo maacutesnodos al cluster
El coacutedigo y todos los ficheros de configuracioacuten de esta seccioacuten tambieacuten sepueden encontrar en el repositorio del proyecto en GitHub23
71 Disentildeo
Microsoft Azure permite organizar los servicios cloud de forma loacutegica a traveacutesde grupos de recursos y asiacute poder crear o eliminar eacutestos en conjunto parauna aplicacioacuten determinada (por ejemplo una aplicacioacuten web suele requerir demaacutequinas virtuales bases de datos almacenamiento) Ademaacutes dispone dela opcioacuten de crear plantillas en formato JSON que permite al desarrolladordefinir los recursos y su interrelacioacuten para desplegar de forma automaacutetica unainfraestructura TI en la nube
Azure tambieacuten ofrece la posibilidad de monitorizar el estado de las maacutequinasvirtuales a traveacutes de extensiones lo que permite configurar el escalado automaacute-tico al alcanzar cierto liacutemite definido por el operador Eacutesta es a priori la formaen que deberiacutea implementarse hablando en teacuterminos de eficiencia sin embargoesta aproximacioacuten es totalmente dependiente de la plataforma es decir no sepuede extrapolar a otro proveedor o sobre recursos propios sin realizar un nue-vo disentildeo En este proyecto las tareas que son ejecutadas por estos equipos notienen estado ya que todo lo relativo a la persistencia lo hemos asignado fueradel cluster esto permite escalar la plataforma a traveacutes de otra aproximaciones
Las plantillas aceptan una serie de variables a indicar por el usuario entreotras los conjuntos de escala para definir los nodos aceptan una variable quedefine el nuacutemero de maacutequinas que los componen Por otro lado Azure ofreceuna API REST y kits de desarrollo software (SDK por sus siglas en ingleacutes) quepermiten su despliegue de forma programaacutetica Aprovechando estas facilidadesen este proyecto se va a aproximar la escalabilidad con el sucesivo desplieguede la infraestructura de forma automaacutetica se monitorizan los equipos y si sedetecta una maacutequina excesivamente cargada se aumenta el nuacutemero de equiposen la plantilla y se vuelve a desplegar
23httpsgithubcomAntonioAlfrzCloud-Orchestrators
43
En este proyecto se han disentildeado las plantillas para desplegar la arquitec-tura necesaria tanto de Nomad como de DCOS En el caso de la primera eldespliegue es maacutes descriptivo ya que incluye maacutequinas virtuales grupos de se-guridad redes En el caso de DCOS Azure cuenta con un servicio especiacuteficopara clusters gobernados por DCOS denominado Azure Container Service queincluye los componentes necesarios y la instalacioacuten ya realizada
72 Implementacioacuten
En primer lugar para monitorizar el estado de los equipos se va a usar laherramienta Nagios un sistema que permite controlar el estado del hardwarey los servicios de un equipo Se trata de una herramienta muy completa de laque se va a usar su capacidad para ejecutar comandos (plugins) en los nodospara detectar picos de carga generar alertas y ejecutar programas para estoseventos
Se ha desplegado una maacutequina virtual con esta herramienta en ambos siste-mas y se ha instalado una extensioacuten de Nagios (Nagios Remote Plugin Executor)en todos los nodos que permite ejecutar comprobaciones remotamente en con-creto para esta prueba de concepto medir el nivel de saturacioacuten de la unidadcentral de procesamiento (CPU por sus siglas del ingleacutes) Cuando sucede uncambio de estado de una maacutequina esto es cuando este paraacutemetro supera el liacutemi-te definido por el operador Nagios permite actuar en consecuencia ejecutandoprogramas por ello se ha desarrollado un script que ejecuta lo siguiente
Un programa desarrollado en Python con el SDK de Azure que modificalas plantillas y despliega los recursos
Un guioacuten de Ansible para instalar todos los componentes necesarios en lasnuevas maacutequinas y arrancar de nuevo el cluster y las aplicaciones
44
8 Resultados y conclusiones
En este uacuteltimo apartado se da una visioacuten global del proyecto asiacute como a lasconclusiones maacutes importantes a las que se ha llegado y posibles temas futurosde desarrollo
81 Comparacioacuten
Ambas herramientas ofrecen las funcionalidades para gestionar los recursoseficientemente ofreciendo a los desarrolladores una plataforma donde desplegarsus aplicaciones de forma distribuida independientemente de los equipos fiacutesicosy el hardware que las soporten
DCOS es una herramienta que en un comienzo fue privativa pero cuyos res-ponsables la empresa Mesosphere decidieron publicar una versioacuten de coacutedigoEacutesta nos permite gestionar un cluster de una forma sencilla y usable ademaacutes decomplementarlo con otras herramientas como el balanceador de carga integradoo la autenticacioacuten de usuarios ademaacutes estaacute basada en Apache Mesos un pro-yecto de relativa madurez y con el soporte de la Apache Software FoundationDe forma resumida DCOS ofrece muchas posibilidades y servicios a cambiode una arquitectura e instalacioacuten maacutes compleja
Por su parte HashiCorp con menor tiempo de desarrollo ha conseguidouna herramienta muy sencilla de desplegar que ademaacutes cumple con todas lasfuncionalidades baacutesicas ejecutando un simple binario en cada nodo se puededesplegar un gestor de clusters totalmente funcional Sin embargo no cuentacon todas las posibilidades de Mesos (Nomad cuenta con menos controladoresque entornos posibles de Mesos) ni con los antildeadidos de DCOS lo que implicael uso de otras herramientas para complementar el servicio (Consul HAProxy)
De entre las dificultades encontradas al usar estas herramientas y desplegaraplicaciones sobre ellas se puede destacar la depuracioacuten en ocasiones se desco-noce si un error viene de la propia herramienta de la aplicacioacuten desplegada o delequipo fiacutesico si no se cuenta con un sistema de procesamiento de registro unose puede encontrar con muacuteltiples terminales abiertas inspeccionando numerososficheros de registro buscando posibles errores Ademaacutes no dejan de ser solucio-nes que para usar eficientemente se debe conocer parte de su funcionamientoy sintaxis a la hora de describir la tareas lo que supone un esfuerzo antildeadido yaque cada una tiene sus particularidades y liacutemites
45
82 Conclusiones
En una sociedad cada vez maacutes digital las empresas deben adaptarse a unmercado cuya demanda de contenido no deja de crecer Las nuevas arquitecturascomo microservicios asiacute como la gran cantidad de datos generada implica queuna mejor gestioacuten de los recursos y la rapidez para desplegar o escalar solucionesdando valor al cliente lo maacutes raacutepido posible es uno de los objetivos de todas lasempresas de base tecnoloacutegica
Las ventajas que ofrecen los planificadores con aplicaciones distribuidas sonnumerosas sin ir maacutes lejos empresas tan punteras como Google llevan maacutesde 10 antildeos orquestando contenedores24 Por un lado permiten aumentar elrendimiento de los equipos propios y por otro implementar un servicio comoplataforma para despliegues distribuidos sobre cualquier conjunto hardware deesta forma se provee un servicio similar al de la nube puacuteblica pero con laprincipal diferencia de que se elimina la independencia con el proveedor (vendorlock-in) esto es las aplicaciones no tienen limitaciones impuestas por eacuteste talescomo lenguaje de programacioacuten o herramientas y permite despliegues hiacutebridosentre recursos propios y la nube
83 Objetivos conseguidos
Implementacioacuten de los planificadores propuestos en la nube Se ha en-tendido y detallado el funcionamiento de estas herramientas y se hanimplementado en el servicio de infraestructura de Microsoft Azure
Despliegue de aplicaciones y servicios distribuidos Servicios que se usanactualmente en la industria del desarrollo software asiacute como una aplica-cioacuten web con una arquitectura moderna han sido desplegados de formadistribuida en los equipos cumpliendo con la funcionalidad esperada ade-maacutes de consiguiendo una alta disponibilidad
Aproximacioacuten de arquitectura escalable Se ha hecho una aproximacioacutende infraestructura escalable de forma que sea parcialmente extrapolable aotros proveedores
24httpwwwnextplatformcom20160322decade-container-control-google
46
84 Liacuteneas de investigacioacuten
Siguiendo con la materia de este proyecto se presentan posibles liacuteneas deinvestigacioacuten
Analizar el despliegue con estas herramientas de aplicaciones de Big Datay comparar la eficiencia con respecto a soluciones especializadas
Analizar el rendimiento de los algoritmos de planificacioacuten antes pruebasde estreacutes y situaciones de alta contienda
Comparar el uso de estas herramientas con las praacutecticas actuales de laindustria o implementacioacuten en un sistema de produccioacuten real
47
Referencias
[1] LA Barroso y U Houmllzle laquoThe Datacenter as a Computer An Introduc-tion to the Design of Warehouse-Scale Machinesraquo En Morgan amp ClaypoolPublishers ()
[2] Systems Research Group ndash NetOS (University of Cambridge) The evolu-tion of cluster scheduler architectures 2016 url httpswwwclcamacukresearchsrgnetoscamsasblog2016-03-09-scheduler-architectureshtml
[3] A Das I Gupta y A Motivala SWIM Scalable Weakly-consistent Infection-style Process Group Membership Protocol Inf teacutec Dept of ComputerScience Cornell University url https www cs cornell edu ~asdasresearchdsn02-swimpdf
[4] D Dubhashi y A Das Mastering Mesos PACKT Publishing mayo de2016
[5] The Apache Software Foundation Apache Mesos documentation urlhttpsmesosapacheorg
[6] David Greenberg Building Applications on Mesos OrsquoReilly Media 2016[7] Armand Grillet Comparison of Container Schedulers Inf teacutec Technische
Universitaumlt Berlin[8] HashiCorp Consul documentation url httpswwwconsulio[9] HashiCorp Nomad documentation url httpsdcosio[10] Dan C Marinescu Cloud computing theory and practice Morgan Kauf-
mann 2013[11] Mesosphere DCOS documentation url httpswwwnomadproject
io[12] Microsoft Azure documentation url httpsazuremicrosoftcom
es-esdocumentation[13] D Ongaro y J Ousterhout In Search of an Understandable Consensus
Algorithm Inf teacutec Stanford University url httpsraftgithubioraftpdf
[14] Fei Teng laquoRessource allocation and schelduling models for cloud compu-tingraquo Tesis de mtriacutea Ecole Centrale Paris 2011
[15] A Williams y col Automation and Orchestration with Docker and Contai-ners A Comprehensive Overview of the Docker and Container Ecosystem3 The New Stack 2016
48
- Resumen
- Summary
- Iacutendice de figuras
- Introduccioacuten y objetivos
-
- Contexto
- Objetivos
- Estructura del documento
-
- Cloud Computing
- Nuevas cargas de trabajo
- Gestioacuten de recursos Planificadores
-
- Sistemas distribuidos
-
- Clasificacioacuten
-
- Herramientas
-
- DCOS
-
- Apache Mesos
- Ejemplos de uso
-
- Nomad
-
- Protocolo de consenso Raft
- Protocolo gossip SWIM
- Planificacioacuten
-
- Casos de uso y despliegue
-
- Aplicacioacuten Web
-
- DCOS
- Nomad
-
- Servicio de integracioacuten continua
-
- DevOps
- Integracioacuten Continua
- Jenkins con Nomad
- Jenkins con DCOS
-
- Escalando la infraestructura
-
- Disentildeo
- Implementacioacuten
-
- Resultados y conclusiones
-
- Comparacioacuten
- Conclusiones
- Objetivos conseguidos
- Liacuteneas de investigacioacuten
-
12 Objetivos
El propoacutesito de este proyecto es estudiar la viabilidad del uso de planifica-dores de recursos para aumentar la eficiencia de eacutestos y facilitar al desarrolladorel despliegue de aplicaciones de forma distribuida y asiacute ofrecer un servicio ca-racterizado por una alta disponibilidad y escalabilidad
A lo largo de este trabajo se han usado algunas de las herramientas quese estaacuten comenzando a desarrollar para hacer frente a este nuevo enfoque degestioacuten de infraestructuras de las tecnologiacuteas de la informacioacuten (en adelanteinfraestructuras TI) realizando pruebas de concepto sobre cada una de ellas
13 Estructura del documento
A continuacioacuten se detalla las secciones que componen este trabajo La es-tructura queda como sigue
Cloud computing Se entra en detalle en este nuevo modelo de negocio queha originado nuevos enfoques y disentildeos de las infraestructuras TI dentrode las organizaciones
Nuevas cargas de trabajo Se explican algunas tecnologiacuteas representativasque estaacuten suponiendo un desafiacuteo para los profesionales de TI a la horade planificar los recursos y que se ven beneficiadas por entornos de tipocloud
Gestioacuten de recursos Planificadores Estado del arte de las tecnologiacuteas degestioacuten de clusters y planificacioacuten de recursos
Herramientas Descripcioacuten detallada del funcionamiento y arquitectura de lasherramientas usadas a lo largo del proyecto
Casos de uso y despliegue Se describe el proceso de implementacioacuten de unaaplicacioacuten web y un servicio de integracioacuten continua con el software pro-puesto
Escalando la infraestructura Se propone un procedimiento con cierta inde-pendencia del proveedor cloud
Resultados y conclusiones Resume las ideas y hechos a los que se ha llegadoademaacutes de introducir liacuteneas de investigacioacuten futuras
2
2 Cloud Computing
El NIST (National Insitute of Standards and Technology) define este con-cepto como un modelo que permite un acceso ubicuo y bajo demanda de formaremota a un conjunto compartido de recursos de computacioacuten que pueden seraprovisionados y liberados con unos miacutenimos esfuerzos de gestioacuten por parte delproveedor del servicio3
Clasificacioacuten
La computacioacuten en la nube abarca una amplia variedad de servicios y enfo-ques por lo que en primer lugar se va a dar una clasificacioacuten para posterior-mente entrar maacutes en detalle Existen distintos modelos de nube atendiendo a lagobernabilidad de la infraestructura seguacuten el NIST
Nubes puacuteblicas Los servicios y recursos son ofertados de forma puacuteblica yson provistos por una organizacioacuten que los comercializa bajo demanda
Nube privada Los recursos son gestionados por una uacutenica organizacioacutenpara su propio uso
Nube comunitaria En este caso la infraestructura es administrada por unconjunto de organizaciones con objetivos comunes
Nube hiacutebrida Una combinacioacuten de las anteriores
A su vez los distintos servicios que ofrece se pueden clasificar atendiendo algrado de control del usuario
Servicios de software (Software as a Service SaaS) El proveedor se encargade toda la gestioacuten de la infraestructura y oferta aplicaciones a las cuales elcliente puede acceder de forma ubicua a traveacutes de diversos clientes comoun navegador web Por ejemplo Office 365 o Google docs
Servicios de plataforma (Platform as a Service PaaS) Modelo de distribu-cioacuten que ofrece la capacidad de desplegar aplicaciones desarrolladas por elcliente usando las herramientas y lenguajes de programacioacuten soportadaspor el proveedor pero sin la posibilidad de gestionar los recursos consu-midos En este caso el cliente solo tiene control sobre la propia aplicacioacuteny algunas configuraciones del entorno Es el caso de Heroku o Google AppEngine
3httpnvlpubsnistgovnistpubsLegacySPnistspecialpublication800-145pdf
3
Servicios de infraestructura (Infrastructure as a Service IaaS) Se ofertanrecursos de computacioacuten puros como procesamiento o almacenamientomediante una plataforma de virtualizacioacuten El cliente puede controlar elsistema operativo componentes de red y aplicaciones
Figura 1 Comparacioacuten Centro de datos - Computacioacuten en la nubeFuente httpsad-hocnet
De entre las numerosas ventajas que ofrece la computacioacuten en la nube se puededestacar su flexibilidad ya que permite aprovisionar recursos y adaptarlos deacuerdo a la demanda reduce el capital inmovilizado y su amortizacioacuten laubicuidad que permite su consumo desde cualquier parte con conexioacuten a la redy la seguridad y fiabilidad que ofrece el proveedor que normalmente cuenta conrecursos geograacuteficamente distribuidos frente a la gestioacuten y mantenimiento derecursos propios
4
3 Nuevas cargas de trabajo
Las organizaciones que cuentan con sus propios infraestructuras TI han co-menzado a adoptar un enfoque de nube privada para gestionar las tareas ofunciones informaacuteticas sobre las que se sustentan el negocio ya que una es-tructura virtualizada puede ofrecer ventajas con respecto a las adaptaciones decentros de datos tradicionales en los aacutembitos de rendimiento escalabilidad eincluso seguridad4
A su vez se han desarrollado nuevas tecnologiacuteas que suponen cargas detrabajo dinaacutemicas y con gran intensidad de consumo de datos para las empresasque se ven beneficiadas al desplegarlas en recursos virtualizados
Big data
Con la creciente aceptacioacuten de las tecnologiacuteas TIC por parte de la sociedadla cantidad de datos generados en la red es ingente Las profesionales de TI tienecomo objetivo extraer valor de eacutestos para por ejemplo prever las tendencias delmercado Sin embargo este incremento exponencial hace que su procesamientoy almacenamiento requiera de un sistema con gran escalabilidad dado el hechode que una sola maacutequina no puede proveer de la capacidad necesaria
Integracioacuten continua
Modelo informaacutetico que consiste en hacer integraciones automaacuteticas de unproyecto con cualquier cambio en el coacutedigo con el objetivo de detectar fallosde forma temprana Esto implica la compilacioacuten del coacutedigo y su ejecucioacuten enun entorno de pruebas automaacuteticamente un proceso que mediante tecnologiacuteasde virtualizacioacuten permiten simular entornos con eficiencia y rapidez Su imple-mentacioacuten en sistemas distribuidos permite tanto una mejor planificacioacuten comoun mejor rendimiento de los recursos
Arquitectura de microservicios
Enfoque para desarrollar aplicaciones software como un conjunto de serviciosautoacutenomos que se comunican entre siacute a diferencia de aproximaciones monoliacuteti-cas donde la loacutegica del servicio estaacute desarrollada como una unidad Un sistemadistribuido permite el despliegue de los componentes en distintas maacutequinas loque mejora tanto su escalabilidad como la tolerancia a fallos
4httpswwwakamaicomesesresourcespublic-private-cloudjsp
5
Docker
Proyecto de coacutedigo abierto que facilita y automatiza el despliegue de aplica-ciones al encapsular el entorno de trabajo en contenedores Linux una tecnologiacuteaque permite a un sistema fiacutesico ejecutar muacuteltiples instancias de sistemas opera-tivos aislados mediante entornos virtuales con sus propios espacios de procesosy redes pero compartiendo el nuacutecleo (kernel) con el equipo anfitrioacuten
En la figura 2 se compara la pila de una virtualizacioacuten tradicional con res-pecto a los contenedores no se simula el sistema operativo por lo que el procesoes mucho maacutes ligero
Docker se caracteriza por
Autosuficiencia Los contenedores cuentan con las libreriacuteas y configuracio-nes necesarias para ejecutarse de manera autoacutenoma al compartir el nuacutecleo
Portabilidad El hecho de que sean autosuficientes implica que es inde-pendiente del host es decir se puede desplegar en cualquier equipo quesoporte esta tecnologiacutea
Tamantildeo El peso de un contenedor es sustancialmente inferior a otrastecnologiacuteas de virtualizacioacuten
Figura 2 Arquitectura DockerFuente httpsdockercom
6
Los componentes fundamentales de esta herramienta son
Imaacutegenes Describen el entorno de base sobre el que ejecutar el contene-dor por ejemplo la imagen del sistema operativo Ubuntu Sobre eacutesta seconstruyen las aplicaciones particulares del usuario dando lugar a otraimagen
Contenedores Se crean a partir de las imaacutegenes y comprenden todo aquellonecesario para arrancar la aplicacioacuten decir su entorno de ejecucioacuten
bull Voluacutemenes Encargados de gestionar la persistencia de datos e inde-pendientes del ciclo de vida del contenedor
Registros Pueden ser puacuteblicos o privados y almacenan las imaacutegenes elregistro puacuteblico oficial de Docker es Docker Hub
Dadas estas caracteriacutesticas los profesionales TI estaacuten comenzando a adoptarDocker ya que facilita tanto los despliegues como el trabajo compartido en dis-tintos entornos Sin embargo esto requiere de un software que permita desplegarlos distintos contenedores de forma que puedan trabajar en conjunto procesoque se ha denominado orquestacioacuten de contenedores
7
4 Gestioacuten de recursos Planificadores
Para sacar el maacuteximo provecho a las tecnologiacuteas anteriormente descritaslo ideal es desplegarlas en sistemas distribuidos sin embargo esto aumenta lacomplejidad del propio despliegue asiacute como la necesidad de software especiali-zado para ello Se necesitan algoritmos de planificacioacuten que permitan obtener elmaacuteximo rendimiento de los recursos por un lado y dar ciertas garantiacuteas de quetodas las tareas y procesos se van a ejecuta por otro
41 Sistemas distribuidos
En primer lugar se definen los sistemas distribuidos o clusters como unconjunto de ordenadores conectados entre siacute cuyo objetivo es trabajar como unauacutenica instancia de gran capacidad5
Su clasificacioacuten variacutea de acuerdo a cada autor pero en general se puedendividir seguacuten su objetivo en alto rendimiento aquellos cuyo objetivos es proveerde gran capacidad de coacutemputo gracias al conjunto de los nodos y alta disponi-bilidad con los cuales se busca la fiabilidad del sistema mediante redundanciayo balanceo de carga
El intereacutes de este proyecto recae en los uacuteltimos ya que el objetivo es porun lado ofrecer al desarrollador un entorno donde desplegar sus aplicaciones deforma distribuida y por otro maximizar el rendimiento de los recursos
De forma general las caracteriacutesticas que se buscan son las siguientes
Elasticidad Adaptacioacuten a cargas dinaacutemicas de trabajo aumentando (o dis-minuyendo) recursos de manera automaacutetica de tal forma que la utilizacioacutensea lo maacutes cercana a la demanda
Disponibilidad Capacidad de un sistema para mantener el servicio fun-cional
Tolerancia a fallos Recuperacioacuten del servicio ante el fallo de un compo-nente
Balanceo de carga Compartir las tareas entre las diferentes maacutequinasredundadas evitando asiacute puntos de uacutenico fallo
5httpsenwikipediaorgwikiComputer_cluster
8
Los programas que se implementan en entornos distribuidos se caracterizanpor ejecutarse de forma concurrente en equipos independientes estar conectadospor una red que introduce fallos aleatorios y no compartir memoria ni reloj Estoimplica entre otras cosas que
Los nodos soacutelo tienen un acceso raacutepido a su memoria local por lo quecualquier informacioacuten relativa al estado global puede ser potencialmenteerroacutenea
Las maacutequinas pueden sufrir caiacutedas de forma aleatoria
El intercambio de informacioacuten puede fallar ya sea por error en transmisioacuteno por caiacuteda de los nodos
Estas dificultades se ponen de manifiesto en el teorema de CAP en cienciasde la computacioacuten el teorema de CAP que lanzado inicialmente como conjetu-ra en el antildeo 2000 por Eric Brewer (motivo por el cual al teorema se le conoceformalmente como teorema de Brewer) y posteriormente demostrado en el antildeo20026 establece que es imposible para un sistema de coacutemputo distribuido ga-rantizar simultaacuteneamente dos de las tres propiedades siguientes
Consistencia (Consistency) es decir que todos los nodos vean la mismainformacioacuten al mismo tiempo Se busca que un cambio en el sistema soacutelose ejecute satisfactoriamente si y soacutelo si se efectuacutea a todos las maacutequinasde tal forma que los datos entre ellos nunca difieren y la respuesta a unapeticioacuten sea la misma independientemente del nodo que la atienda
Disponibilidad (Availability) esto es la garantiacutea de que toda peticioacuten debeobtener una respuesta (servicio funcional) aunque exista inconsistenciaentre nodos
Tolerancia al particionado (Partition Tolerance) es decir que el sistemasiga funcionado a pesar de un fallo en la comunicacioacuten entre los equipos
Por todo lo expresado anteriormente conseguir un sistema distribuido capazde ofrecer procesamiento de forma transparente implica una arquitectura TIcompleja Se requieren de subsistemas y herramientas que permitan la cohesioacutenentre todos los nodos
Gestor de los recursos de las diferentes maacutequinas
Monitorizacioacuten tanto de los servicios activos como de la funcionalidad delsistema ademaacutes de poliacuteticas para recuperacioacuten de fallo
Protocolos de consenso que permitan a los nodos ser consistentes con elestado global del cluster
6urlhttpsgroupscsailmitedutdspapersGilbertBrewer2pdf
9
Herramientas de descubrimiento de servicios que permita la comunicacioacutenentre tareas distribuidas
Planificadores Encargados de distribuir las tareas y procesos en las dife-rentes maacutequinas asignaacutendole parte de su capacidad
Los planificadores del ingleacutes cluster schedulers son un componente funda-mental por lo que vamos a entrar un poco maacutes en detalle en ellos
Planificadores (Cluster Schedulers)
Es el software encargado de monitorizar los recursos usados por cada maacute-quina perteneciente a un cluster y distribuir la carga de trabajo entre ellas deacuerdo a un poliacutetica o reglas
Este tipo de herramientas comparten cierta terminologiacutea que es relevantedefinir
Tarea Unidad de trabajo computacional comprendida por una secuenciade instrucciones datos de entrada y recursos asociados Por ejemplo laejecucioacuten de un comando o el arranque de una base de datos
Nodo Cualquier maacutequina integrante de un cluster En una arquitecturamaestro-esclavo se definen dos roles
bull Cliente Agente Esclavo Aquellos ordenadores que se encargan deejecutar las tareas
bull Maestro Servidor Su objetivo es mantener el estado del cluster ygestionar sus recursos
411 Clasificacioacuten
A lo largo de los uacuteltimos antildeos se han desarrollado diferentes tipos de plani-ficadores[2]
Monoliacutetico
Un solo planificador que se encarga de distribuir todas las tareas entran-tes La mayoriacutea de los planificadores en computacioacuten de alto rendimiento asiacutecomo Borg desarrollado por Google son de este tipo En la figura 3 se pue-de observar de forma graacutefica el procedimiento siendo las cajas grises maacutequinaspertenecientes al cluster y los ciacuterculos las tareas a asignar
10
Figura 3 Planificador monoliacuteticoFuente httpswwwclcamacuk
Planificacioacuten de dos niveles
La mayoriacutea de los clusters ejecutan aplicaciones con distintas necesidadesdesde procesos casi instantaacuteneos hasta servicios persistenteslo que implica dis-tintas necesidades de recursos
Por ello la planificacioacuten a dos niveles distingue dos funciones la gestioacutende recursos (gestor) y la disposicioacuten de las tareas (planificador) Cada serviciotiene su propio planificador de tal manera que el gestor les ldquoofertardquo recursosde acuerdo a una poliacutetica y los planificadores se encargan de escoger la maacutesadecuada Esto permite que el proceso de distribucioacuten sea maacutes acorde con lasnecesidades de los diferentes servicios Apache Mesos que detallaremos maacutesadelante sigue este esquema
Como desventaja cabriacutea sentildealar que esta programacioacuten implica que los pla-nificadores pierden la vista general de la infraestructura y las tareas soacutelo puedenejecutarse con los recursos que les son ofrecidos lo que dificulta la implementa-cioacuten de prioridades de ejecucioacuten de tareas entre otras
Figura 4 Planificador de dos niveles
11
Planificacioacuten de estado compartido
Muacuteltiples reacuteplicas del estado del cluster se actualizan independientementepara cada planificador como se observa en la figura 5 cuando sucede un cambiode forma local el planificador se encarga de informar al resto
Ejemplo de este tipo son Omega la evolucioacuten de Borg por parte de GoogleMicrosoft Apollo y Nomad que usaremos para los casos de uso
De entre las desventajas se puede destacar el hecho de que en general losnodos trabajan con informacioacuten desactualizada lo que conlleva una degradacioacutendel rendimiento en situaciones de alta contienda
Figura 5 Planificador de estado compartido
Planificacioacuten distribuida
En este caso no existe coordinacioacuten entre los distintos planificadores Cadauno de ellos funciona con su propia vista del cluster Las tareas pueden serorganizadas por cualquiera de ellos y desplegadas en cualquier parte del clusteren base a la aleatoriedad y multiplexacioacuten estadiacutestica de los flujos de trabajosin ninguacuten control central
Figura 6 Planificador distribuido
12
5 Herramientas
En la industria comienzan a aparecer soluciones software de coacutedigo abiertoque aglutinan los servicios necesarios para gestionar la infraestructura TI de ma-nera maacutes eficaz El objetivo es doble se busca facilitar la gestioacuten de los recursosde computacioacuten para organizaciones con instalaciones propias mediante su usocon un enfoque cloud esto es desplegar aplicaciones a traveacutes de un conjuntode ordenadores de forma transparente y sin tener en cuenta la infraestructurasubyacente o aprovechar el maacuteximo rendimiento de la infraestructura de losproveedores cloud puacuteblicos de forma que se tiene el maacuteximo control sobre eacutestapero no se depende de las soluciones propietarias permitiendo asiacute despliegueshiacutebridos
Entre estas herramientas se pueden destacar
OpenStack Proyecto desarrollado por la fundacioacuten del mismo nombre paraproporcionar servicios de infraestructuras (IaaS) basado en componentesque se comunican a traveacutes de APIs El componente Magnum incluye mo-tores de orquestacioacuten de contenedores
Kubernetes Sistema de orquestacioacuten de contenedores Docker creado por Goo-gle
CoreOs Sistema operativo basado en Linux disentildeado para despliegues distri-buidos sobre contenedores incluyendo mecanismos de descubrimiento deservicio y comparticioacuten de configuracioacuten
Docker Swarm Herramienta nativa de orquestacioacuten de contenedores Docker
YARN Entorno de gestioacuten de recursos y aplicaciones distribuidas de Hadoopuna libreriacutea software de procesamiento de grandes conjuntos de datos
Como podemos observar existe un gran rango de opciones para gestionar lainfraestructura desde un bajo nivel como puede ser OpenStack hasta Kuberne-tes o Docker Swarm que ofrecen exclusivamente orquestacioacuten de contenedores
En este trabajo se ha optado por Mesosphere DCOS y HashiCorp Nomadque se encuentran en el teacutermino medio su objetivo es proporcionar serviciosde plataforma que permitan la coexistencia dediferentes cargas de trabajo en elcluster
13
51 DCOS
DCOS es un proyecto de coacutedigo abierto7 creado y desarrollado por la empre-sa Mesosphere Se describe como un sistema operativo distribuido que abstraelos recursos de un cluster (capacidad de procesamiento memoria) permite lagestioacuten de muacuteltiples ordenadores de forma transparente y simplifica la instala-cioacuten de aplicaciones distribuidas
Su arquitectura se puede comparar a la de Linux en teacuterminos de nuacutecleo(kernel) y espacio de usuario El primero consta de recursos protegidos a losque no puede acceder el usuario e involucra operaciones de bajo nivel comoasignacioacuten de recursos o aislamiento de procesos En el espacio de usuario seejecutan las aplicaciones y servicios de maacutes alto nivel
Siguiendo con este siacutemil el nuacutecleo de DCOS estaacute basado en Apache Mesosque se explicaraacute en un apartado posterior y el espacio de usuario que estaacute com-prendido por los componentes del sistema esto es las diferentes herramientasque en conjunto conforman DCOS y los servicios encargados de planificar yejecutar las aplicaciones y tareas del usuario
Figura 7 Arquitectura DCOSFuente httpsdcosio
De entre los componentes que conforman DCOS destacan
Admin Router Balanceador de carga central basado en NGINX que dis-pone un proxy entre todos los servicios en el puerto 80 permitiendo sugestioacuten mediante la interfaz graacutefica Ademaacutes se encarga de la autenticacioacutenpara acceder al panel de administracioacuten
Cosmos Gestor de paquetes de las aplicaciones
Diagnostics Se ejecuta en todos los nodos y se encarga de monitorizar elestado de los daemons que sustentan DCOS
7Desde abril de 2016 httpsmesospherecomblog20160419open-source-dcos
14
Exhibitor Gestiona y automatiza el despliegue de ZooKeper la herra-mienta que provee de configuracioacuten centralizada y registro de nombres
Marathon Equivale al proceso init de los sistemas tipo Unix esto es elprimer proceso en ejecucioacuten tras la carga del kernel y que genera los demaacutesprocesos Se encarga de arrancar y monitorizar las aplicaciones y servicios
Mesos-DNS Servicio de DNS interno que define el dominio mesos pa-ra nodos y tareas en el cluster es decir permite resolver nombres conindependencia de la direccioacuten fiacutesica
Minuteman Balanceador de carga integrado a nivel TCPUDP disponiblepara las propias aplicaciones
Por otra parte se definen como servicios a las diferentes aplicaciones dis-tribuidas que DCOS permite instalar en el cluster y que pueden haber sidodesarrollados por la misma empresa Mesosphere o por terceros por ejemploApache Spark Jenkins o Apache Hadoop En la figura 8 se muestra un diagramade los servicios disponibles incluyendo algunos de las aplicaciones distribuidasque soporta DCOS
Figura 8 Servicios DCOSFuente httpsdcosio
511 Apache Mesos
El nuacutecleo de DCOS estaacute basado en Apache Mesos un proyecto de coacutedigoabierto creado por la Universidad de California Berkeley y desarrollado actual-mente por la fundacioacuten Apache Se trata de un administrador de clusters queabstrae los recursos y los dispone para diferentes aplicaciones y entornos de tra-bajo distribuidos (frameworks) mediante una interfaz comuacuten En el momento deredaccioacuten de este proyecto Apache Mesos soportaba una variedad de entornosque abarcaba desde Big Data (Apache Spark Hadoop) hasta bases de datos(Cassandra Hypertable)
15
Arquitectura
Mesos se basa en la asignacioacuten de dos roles diferentes a los nodos
Maestros (Masters) Se encargan de la gestioacuten y reparticioacuten de los recursospara los diferentes entornos de trabajo mediante ldquoofertas de recursosrdquo deacuerdo a los disponibles y a la poliacutetica de asignacioacuten (planificacioacuten en dosniveles)
Esclavos (Slaves) Ordenadores donde se ejecutaraacuten las aplicaciones y cu-yos recursos son ofertados por los maestros
En el caso de fallo del maestro las tareas pueden seguir ejecutaacutendose perono se podraacute asignar nuevos recursos ni tareas por ello pueden existir varios enel cluster para configuraciones de alta disponibilidad pero soacutelo uno orquesta alos esclavos
Para la eleccioacuten del master liacuteder Mesos usa Apache ZooKeeper un proyectode software desarrollado por la misma fundacioacuten cuyo objetivo es proveer deun servicio de configuracioacuten centralizado y registro de nombres8
Por otra parte los entornos de trabajo son los programas que deciden final-mente queacute recursos se van a usar y se encargan de que los esclavos ejecuten lastareas Eacutestos se ejecutan sobre Mesos y constan de dos componentes
Planificador (Scheduler) Optimiza y decide los recursos a utilizar de losofertados informando a los Masters
Procesador (Executor) Ejecuta las aplicaciones o servicios en los esclavos
El objetivo final es conseguir una interfaz liviana tolerante a fallos paracualquier tipo de entorno de trabajo de tal manera que en los esclavos del clusterpuedan ejecutarse simultaacuteneamente tareas con necesidades y duracioacuten diferentesPara ello se basa en dos conceptos asignacioacuten y aislamiento de recursos
Asignacioacuten de recursos
En el cluster pueden coexistir entornos de trabajo con tareas de larga dura-cioacuten y con gran consumo de recursos con tareas cortas que los ocupan y liberancon rapidez El maestro integra un moacutedulo de asignacioacuten de recursos (allocationmodule) que se encarga del algoritmo de distribucioacuten
En el momento de escribir este proyecto estaban desarrollados dos moacutedulosuno mediante el cual el usuario puede asignar prioridades y otro que implementa
8httpszookeeperapacheorg
16
el algoritmo Dominant Resource Fairness9 a grandes rasgos se determina entodos los esclavos la tarea en ejecucioacuten que necesita maacutes recursos y se calcula laproporcioacuten del recurso de mayor peso con respecto al total por ejemplo si unatarea ocupa 2 GB de memoria con respecto a 10 GB totales que tiene el clusterse le asigna un dominant share del 20 la tarea se asignaraacute al nodo con menordominant share
Aislamiento de recursos
Para conseguir que tareas de diferentes entornos de trabajo y con distin-ta naturaleza se ejecuten simultaacuteneamente en un mismo nodo Mesos usa loscontenedores Linux (descritos en la seccioacuten 3)
Funcionamiento
La figura 9 muestra el esquema de la arquitectura de Apache Mesos conalta disponibilidad (tres maestros) y con dos entornos de trabajo ejecutaacutendo-se Hadoop que permite el almacenamiento y procesamiento de gran cantidadde datos para proyectos de big data y un sistema que implementa la interfazsistema de paso de mensajes MPI
Como se puede observar el sistema ZooKeeper elige a un solo maestro comoliacuteder y eacuteste orquesta el cluster comunicando los esclavos con los planificadoresde los diferentes entornos de trabajo Tambieacuten se puede observar como las tareasde los distintos entornos estaacuten distribuidas entre los tres esclavos disponibles
Figura 9 Arquitectura de Apache MesosFuente httpsmesosapacheorg
El proceso de asignacioacuten se realiza como sigue en primer lugar un usuariosolicita la ejecucioacuten de una tarea mediante la interfaz de cada entorno de traba-jo (interfaz graacutefica API HTTP ) De forma paralela un esclavo informa almaestro de los recursos que tiene libres En consecuencia eacuteste se lo notifica almoacutedulo de asignacioacuten que en funcioacuten de su configuracioacuten decide cuaacutento ofertar
9httpspeopleeecsberkeleyedu~aligpapersdrfpdf
17
y a queacute entorno de trabajo y enviacutea la oferta a los planificadores Eacutestos respondenal maestro con queacute recursos ha decidido usar para cada tarea Finalmente lastareas son enviadas al esclavo seleccionado el cual asigna los recursos indicadosal procesador (executor) quien finalmente las ejecuta
Cabriacutea pensar que esta metodologiacutea puede conducir a situaciones en lasque un entorno podriacutea quedarse con tareas sin ejecutarse a la espera de unaoferta satisfactoria para ello Mesos implementa un sistema de filtros medianteel cual los entornos especifican los requisitos miacutenimos que debe cumplir unaoferta por ejemplo se puede especificar en queacute nodos debe desplegarse la tareaEste sistema estaacute disentildeado asiacute con el objetivo de mantener lo maacutes transparenteposible esta herramientas de forma que acepte entornos de trabajo de distintasnaturalezas
512 Ejemplos de uso
Grandes empresas estaacuten usando Apache Mesos con eficacia de acuerdo a susnecesidades e infraestructuras Caben destacar
Ebay En el modelo de implementacioacuten continua en esta empresa10 cadadesarrollador cuenta con su propia instancia que se ejecuta en una maacutequinavirtual dedicada lo que ha conllevado un uso de los recursos poco eficiente Enuna prueba de concepto consiguieron realizar una herramienta de integracioacutencontinua distribuida basada en un cluster con Apache mesos y con el entornoMarathon y Jenkins
Apple Anuncioacute que el motor de su famosa herramienta de asistencia per-sonal para iPhones Siri estaacute desplegada sobre Apache Mesos11 Para ello handesarrollado su propio entorno para facilitar a los ingenieros a desplegar los ser-vicios que la herramienta necesita para resolver las peticiones de los usuarios
Twitter Desarrolloacute su propio entorno denominado Aurora y actualmentegestionan sus recursos y miden el coste de las tareas que los empleados usancon el objetivo de que sean conscientes del gasto que puede suponer un usoinadecuado de la infraestructura12
10httpwwwebaytechblogcom20140404delivering-ebays-ci-solution-with-apache-mesos-part-i11httpwwwbusinessinsidercomapple-siri-uses-apache-mesos-2015-812httpswwwlinuxcomNEWS4-UNIQUE-WAYS-UBER-TWITTER-PAYPAL-AND-HUBSPOT-USE-APACHE-MESOS
18
52 Nomad
Herramienta de coacutedigo abierto de gestioacuten de clusters creada y desarrolladapor Hashicorp13 que permite el despliegue de aplicaciones y procesos de formadistribuida
Las principales diferencias con Apache Mesos a grandes rasgos son
Arquitectura maacutes ligera Nomad soacutelo requiere de un fichero para funcionarejecutaacutendolo con las correspondientes configuraciones en todos los nodosrealiza las funciones de gestioacuten del cluster eleccioacuten de liacuteder planificacioacutende recursos y ejecucioacuten de las tareas
Centro de datos y regiones muacuteltiples Su arquitectura estaacute orientada afacilitar la gestioacuten de diferentes centros de datos geograacuteficamente distri-buidos
Entorno de ejecucioacuten Las tareas se definen y son interpretadas mediantecontroladores integrados en Nomad que se valen de los recursos y herra-mientas de los nodos clientes para ejecutarlas Esta integracioacuten dificultael desarrollo de controladores por parte de terceros a diferencia de Mesosque delega dicha responsabilidad en los entornos de trabajo externos alproyecto
Usa un planificador de estado compartido con respecto a la planificacioacutenen dos niveles de Mesos
Antes de entrar en maacutes detalle en la arquitectura es importante definir lossiguientes teacuterminos
Controlador (Driver) Software que se encarga de interpretar las definicionesde las tareas y ejecutarlas semejante a los procesadores de los entornosde trabajo de Mesos A la hora de redactar este proyecto Nomad contabacon controladores para contenedores Docker virtualizacioacuten de maacutequinasmediante el emulador QEMU aplicaciones java y archivos binarios
Grupo de trabajo (Task Group) Conjunto de tareas que se ejecutan en elmismo nodo cliente
Trabajo (Job) Conjunto loacutegico de tareas y grupos de trabajo que se despliegana la vez
Asignacioacuten (Allocation) Relacioacuten entre un grupo de trabajo y el cliente don-de se ejecuta
Evaluacioacuten (Evaluation) Proceso mediante el cual Nomad planifica y ges-tiona el registro o actualizaciones de los trabajos
13httpswwwhashicorpcom
19
Nomad sigue una arquitectura maestro-esclavo similar a la de Apache Mesosmuacuteltiples servidores acuerdan entre siacute un liacuteder que gestiona la planificacioacuten detareas en los clientes que soacutelo conocen sus asignaciones y las ejecutan
Todos los servidores participan paralelamente en tareas de planificacioacuten derecursos y asignacioacuten de tareas y ademaacutes entre ellos eligen un liacuteder que seencarga de la coordinacioacuten de la suscripcioacuten de los clientes al cluster y de lagestioacuten de las peticiones
Los clientes estaacuten configurados para comunicarse con el servidor usando lla-madas a procedimiento remoto (RPC por sus siglas en ingleacutes) que permite unordenador ejecutar coacutedigo en otra maacutequina Mediante esta tecnologiacutea los nodosclientes avisan de su estado e informa de sus asignaciones recursos y controla-dores disponibles
Existe la posibilidad de gestionar varios centros de datos agrupados en regio-nes eacutestas son independientes pero permite definir tareas o comprobar el estadode todas ellas desde cualquier punto A continuacioacuten se muestra una figura dela arquitectura a alto nivel de esta configuracioacuten
Figura 10 Arquitectura multi-regioacuten en NomadFuente httpswwwnomadprojectio
La herramienta se sustenta sobre tres protocolos fundamentales un protocolode consenso entre los servidores para compartir informacioacuten sobre su estado yel liacuteder un protocolo Gossip para la gestioacuten entre regiones y el planificador detareas
521 Protocolo de consenso Raft
El objetivo es obtener consistencia en un conjunto de nodos que comparteninformacioacuten es decir si un cliente realiza un cambio que todos los nodos veanla misma informacioacuten a la vez y ademaacutes sea tolerante a fallos Para ello se basaen el algoritmo Raft[13] que se detalla brevemente a continuacioacuten
20
Los nodos participantes en el algoritmo pueden estar en tres estados
Liacuteder (Leader) Todos los cambios que realicen en el cluster pasan por eacutel pri-mero
Seguidor (Follower) Nodo pasivo cuya responsabilidad es responder a laspeticiones del nodo liacuteder
Candidato (Candidate) Maacutequina que no ha encontrado liacuteder y solicita sueleccioacuten
Supongamos que tenemos cinco equipos que acaban de arrancar el protocoloEn la figura 11 se observan los nodos y sus respectivos registros a la derecha
Figura 11 Equipos sin consenso ejecutando el protocolo RAFTFuente httpsgithubcomongardieraftscope
Al comenzar todos los nodos son seguidores esperando recibir comunicacioacutende un nodo que actuacutee como liacuteder Cada nodo tiene un tiempo de espera aleatoriodespueacutes del cual si no es informado por un liacuteder pasa a estado candidato y pideel ldquovotordquo al resto de los participantes El algoritmo divide el tiempo en plazos uncandidato pasa a liacuteder si recibe la mayoriacutea de los votos en un plazo determinadoSe define mayoriacutea o cuoacuterum (quorum) comolceil
N2rceil
+ 1 (1)
donde N representa el nuacutemero de nodos
Para el ejemplo propuesto de 5 equipos se requieren de 3 votos Soacutelo losnodos que se encuentren en estado seguidor pueden votar una uacutenica vez a laprimera solicitud que reciba dentro de un plazo
Supoacutengase que el nodo denotado con S1 ha cumplido su tiempo de espera yrealiza la peticioacuten de voto (figura 12) A partir de este momento se pueden dartres casos
La maacutequina gana la eleccioacuten y pasa a ser liacuteder informando al resto
Otro servidor se establece como liacuteder en el mismo momento
Varios nodos pasan a ser candidatos por lo que ninguno consigue los votos
21
Figura 12 Un equipo pasa a estado candidato (RAFT)
Si un candidato recibe un aviso de un liacuteder en el mismo plazo el primeropasa a ser seguidor y se acaba la eleccioacuten de liacuteder
Por otro lado si un equipo candidato no recibe los votos en el plazo y agotasu tiempo de espera avanza al siguiente plazo y repite el proceso de votacioacutenLa tercera posibilidad puede conllevar a un estado indefinido ya que varioscandidatos pueden agotar su tiempo de espera al mismo tiempo y repartir losvotos Para solventarlo el algoritmo establece tiempos de espera aleatorios paralos candidatos
Siguiendo con el ejemplo propuesto el servidor S1 pasa a ser el liacuteder Cadacierto tiempo eacuteste debe realizar avisos a los nodos seguidores para no agotar sutiempo de espera
En este momento el cluster de servidores estaacute en ldquoconsensordquo y la informacioacutenen todos los nodos estaacute actualizada Un cambio en la informacioacuten inicia unproceso de replicacioacuten el liacuteder registra el cambio lo pasa al resto de nodos yuna vez eacutestos responden el cambio se hace efectivo
Supoacutengase que se realiza un cambio en los datos en la figura 13 en la partederecha se observa el cambio en el registro del servidor S1 que informa a losnodos seguidores En consecuencia los nodos registran el cambio y responden aS1
Figura 13 Cambio en un registro (RAFT)
Una vez el cuoacuterum (en el ejemplo tres equipos) informa al liacuteder de que
22
ha registrado el cambio el liacuteder lo hace efectivo en su sistema y notifica a losnodos que hacen lo mismo En la figura 14 el enviacuteo todaviacutea no ha llegado ala maacutequina S3 y se observa que no ha hecho efectivo el cambio (en el registroaparece punteado)
Figura 14 Aprobacioacuten del resto de equipos (RAFT)
Este protocolo funcionaraacute correctamente mientras exista un nuacutemero de nodosen funcionamiento igual o superior al cuoacuterum en el ejemplo propuesto elcuoacuterum es tres por lo que el sistema puede tolerar la caiacuteda de dos de los equipos
522 Protocolo gossip SWIM
Nomad permite la gestioacuten simultaacutenea de varios centros de datos reparti-dos en regiones geograacuteficamente separadas requiriendo de un protocolo ligeroque mantenga a los miembros actualizados sobre los participantes del conjun-to Para ello usa una ligera variante del protocolo SWIM[3] (Scalable Weakly-consistent Infection-style Process Group Membership Protocol) desarrollada porHashiCorp Estaacute clasificado como un protocolo de tipo gossip que debe su nom-bre a la semejanza con coacutemo se distribuye un rumor en una red social
SWIM se sustenta en dos caracteriacutesticas fundamentales la deteccioacuten de fallosy la distribucioacuten de la informacioacuten relativa a los miembros A continuacioacuten sedetalla el funcionamiento de ambos componentes
Deteccioacuten de fallos
Este componente tiene dos paraacutemetros el periodo de protocolo T y el nuacutemerode subgrupos de deteccioacuten de fallos k en los que se dividen los nodos Paracomprobar la comunicacioacuten entre dos maacutequinas usa la utilidad ping basadaen el protocolo ICMP La deteccioacuten de caiacuteda de un servidor sigue el siguientealgoritmo
Durante el periodo T cada miembro Mi de un subgrupo elige otro al azar Mjdel mismo subgrupo y le enviacutea un mensaje ping para comprobar su estado Enel caso de que se cumpla un tiempo de espera determinado por una estimacioacuten
23
del tiempo de ida y vuelta (RTT por sus siglas en ingleacutes) de la red y no hayarespuesta Mi le vuelve a enviar un mensaje ping indirectamente a traveacutes deun nuacutemero k de miembros escogidos aleatoriamente De no recibir ninguna res-puesta Mi establece que Mj ha sufrido un fallo y lo etiqueta como ldquosospechosordquoinformando al componente de distribucioacuten
Figura 15 Diagrama de tiempo del protocolo SWIMFuente httpswwwcscornelledu
Componente de distribucioacuten
Se encarga de informar de cualquier cambio en los miembros a todo el con-junto Los eventos de nodo caiacutedo y la unioacuten o disociacioacuten de un miembro setransmiten a todos los servidores para que actualicen sus lista Para distribuirla informacioacuten a todos los nodos se podriacutea usar el meacutetodo de multicast perosuele estar deshabilitado Por ello se utiliza una teacutecnica de transmisioacuten denomi-nada Piggybacking mediante la cual se adjunta a los propios mensajes PINGy ACK del algoritmo la informacioacuten a distribuir reduciendo asiacute la congestioacutenen la red
523 Planificacioacuten
Proceso encargado de distribuir las tareas entre los nodos clientes de acuerdoa su estado
El planificador de Nomad estaacute basado en las publicaciones de Google sobresus herramientas de gestioacuten de clusters Borg y Omega14 y entiende los trabajosdescritos por el usuario como un estado deseado es decir su despliegue en unamaacutequina cliente de forma correcta y los clientes como el estado actual esto eslo que se encuentra en ejecucioacuten El registro actualizacioacuten o cancelacioacuten de un
14httpresearchgooglecompubspub43438html
24
trabajo asiacute como el fallo de un nodo cliente implican un cambio de estado atramitar por el sistema lo que se define como evaluacioacuten (evaluation) Esto uacutelti-mo supone comparar el estado actual (clientes) con el estado deseado (conjuntode trabajos registrados) y enviarlos a los planificadores correspondientes que seencargaraacuten de asignar las tareas a los nodos clientes
Figura 16 Procedimiento de asignacioacuten en NomadFuente httpswwwnomadprojectio
En la figura 16 se observa el flujo de trabajo en el que las distintas evalua-ciones se encolan en el evaluation broker que se ejecuta en el servidor liacuteder ygestiona las evaluaciones pendientes asignaacutendoles prioridades
A continuacioacuten los nodos servidores ejecutan los scheduling workers queprocesan las evaluaciones llamando a los distintos planificadores que generanun plan de asignacioacuten esto es un conjunto de relaciones entre las tareas y losnodos clientes donde se ejecutaraacuten Este proceso se divide en dos fases primerose descartan aquellos clientes que no cumplan los requisitos y posteriormentese asigna una calificacioacuten al resto Se selecciona el nodo con mayor puntuacioacuteny se encola el plan en el gestor que se ejecuta en el servidor liacuteder Existen tresplanificadores de acuerdo al tipo de trabajo
Service Incluye aquellos trabajos que estaacuten destinados a ejecutarse en un pe-riacuteodo largo de tiempo Para realizar las asignaciones el planificador evaluacuteala mayor parte de los nodos y usa una versioacuten del algoritmo Best fit in-fluenciada por el trabajo de Google en su herramienta Borg Se trata deun algoritmo de planificacioacuten que sacrifica tiempo a cambio de maximizarel rendimiento de los clientes asignando la tarea a la maacutequina que tengala mayor carga de trabajo con el objetivo de reducir equipos en funciona-
25
miento
Batch Tareas que incluyen listas de comandos en general de menor duracioacuteny que no requieren interaccioacuten con el usuario Se vale del algoritmo deSparrow desarrollado por la universidad de Berkeley15 para limitar losnodos clientes a evaluar
System Trabajos destinados a ejecutarse en todos los nodos incluso los que seunen al cluster posteriormente
Core Mantenimiento interno de Nomad
Una vez se ha realizado el proceso de planificacioacuten el nodo liacuteder lo registra enla cola de planes (plan queue) que se encarga de asignarles prioridad y manejarcondiciones de carrera es decir que no accedan a los recursos de los clientes sincontrol y evitar que eacutestos superen su capacidad
La maacutequina liacuteder del conjunto puede de este modo aceptar una asignacioacuteny ser ejecutada por los clientes o por el contrario rechazaacutersela al planificadorlo que implicariacutea realizar un plan parcial o totalmente nuevo
Finalmente el estado de las evaluaciones se actualizan y los clientes soninformados de las asignaciones ejecutaacutendose las tareas
15httppeopleeecsberkeleyedu~keopublicationssosp13-final17pdf
26
6 Casos de uso y despliegue
Con el objetivo de mostrar las posibles utilidades que este tipo de sistemaspueden tener en las infraestructuras TI actuales se han desplegado las dos he-rramientas en la nube Microsoft Azure usando su servicio cloud de instancias demaacutequinas virtuales Linux para simular un conjunto de ordenadores conectadosentre siacute por una red LAN Sobre ellas se ha implementado dos casos de usouna aplicacioacuten web con una arquitectura con cierta orientacioacuten a microserviciosy un sistema de integracioacuten continua
El coacutedigo y todos los ficheros de configuracioacuten se pueden encontrar en elrepositorio del proyecto en GitHub16
61 Aplicacioacuten Web
Se busca simular el proceso de adaptacioacuten de una solucioacuten web para su des-pliegue en un sistema distribuido con las herramientas anteriormente descritascon el objetivo de aumentar tanto su escalabilidad como disponibilidad medianteredundancia
Se ha partido de una aplicacioacuten ya existente17 un servicio de almacenamien-to y reproduccioacuten de canciones A grandes rasgos este servicio permite crearusuarios subir canciones con sus respectivas portadas tener playlists propias yescuchar las canciones a traveacutes de un navegador web
La solucioacuten estaacute dividida en 4 partes (figura 17)
Una vista web con la loacutegica
Un almacenamiento conectado en red (NAS por sus siglas en ingleacutes)
Una API REST para gestionar las peticiones al almacenamiento
Base de datos NoSQL basada en MongoDB
La nueva tendencia de los proyectos web es su implementacioacuten en contene-dores Docker ya que facilitan su portabilidad y ofrecen un procedimiento dedespliegue raacutepido sobre todo a la hora de desarrollar y realizar pruebas en en-tornos de produccioacuten simulados Por ello en este caso se va a hacer uso de los
16httpsgithubcomAntonioAlfrzCloud-Orchestrators17httpsgithubcomsonsoleslpCDPSfy
27
motores de orquestacioacuten de contenedores de ambas herramientas Marathon enDCOS y el controlador Docker en el caso de Nomad
Figura 17 Arquitectura aplicacioacuten web
A continuacioacuten vamos detallar el despliegue en ambas herramientas de es-ta solucioacuten y observar tanto queacute dificultades se encuentran como que ventajasofrecen El objetivo final es adaptar el proyecto modificaacutendolo lo menos posiblecon objeto de analizar la capacidad de estas herramientas para desplegar cual-quier aplicacioacuten sin que eso conlleve la modificacioacuten de la arquitectura de eacutestaes decir que no sea dependiente del entorno
611 DCOS
Se ha descrito DCOS como una herramienta que se despliega sobre un con-junto de ordenadores y que permite instalar gestionar el despliegue de sistemasdistribuidos
Microsoft Azure cuenta con una plantilla para desplegar en su servicio cloudun cluster de maacutequinas virtuales con DCOS ya instalado que cuenta con
Maacutequinas maestras (1 3 o 5 a seleccionar por el usuario) configuradascomo un conjunto de disponibilidad esto eso Azure da ciertas garantiacuteasde que al menos una maacutequina estaraacute en funcionamiento
Maacutequinas agentes Por motivos de seguridad se distinguen dos roles
bull Nodos privados solo accesibles desde la red interna y configuradoscomo un conjunto de escala un recurso de Azure para gestionar ydesplegar maacutequinas con configuraciones ideacutenticas para permitir unraacutepido escalado
bull Un equipo conectado accesible desde Internet a travntildees de un balan-ceador de carga puacuteblico y situado en una subred externa
28
Dos balanceadores de carga
bull La interfaz puacuteblica del cluster que se conecta con el cliente puacuteblicobull Acceso a los equipos maestros para el administrador que soacutelo permiteconexioacuten mediante SSH y credenciales
Almacenamiento para todas las maacutequinas
Configuraciones necesarias de red y seguridad
En la figura 18 se observa un diagrama de la infraestructura
Figura 18 Infraestructura en Azure
El primer obstaacuteculo es la persistencia de estado de la aplicacioacuten que seconsigue gracias a una base de datos no relacional basada en MongoDB asiacutecomo el almacenamiento de las canciones Para implementarla tenemos variasposibilidades
Montar un sistema externo de almacenamiento conectado en red en todoslos agentes donde se ejecuten las tareas de esta manera si una tarea pasade un nodo a otro por cualquier motivo puede tener acceso a los mismosficheros (opcioacuten del caso de uso original)
Implementar un sistema de ficheros distribuidos en los agentes
Usar los servicios de almacenamiento de las nubes puacuteblicas
Aprovechar el sistema de voluacutemenes persistentes de Apache Mesos Eacutestepermite reservar recursos de un agente de forma que al arrancar una tarease crea un volumen independiente del ciclo de vida de eacutesta con ello esosrecursos donde se ha almacenado la informacioacuten pueden volver a ofrecerseal mismo entorno de tal manera que otra tarea pueda acceder a ella
DCOS aprovecha este sistema de voluacutemenes persistentes y permite instalarbases de datos distribuidas como ArangoDB o Apache Cassandra sin embargoesto implicariacutea modificar todo el coacutedigo referente al modelo de la base de datos
29
Por motivos de eficiencia y latencia asiacute como de una mayor gobernabilidadde los datos la mejor opcioacuten es usar el recurso de voluacutemenes persistentes queofrece Apache Mesos ya que de esta manera se gestionariacutea la aplicacioacuten completamediante una uacutenica herramienta Sin embargo esto implica que la informacioacutense encuentra exclusivamente en el agente donde se haya ejecutado la tarea y porlo tanto se sigue requiriendo de software externo para distribuir la informacioacutenpara que se accesible para todos los agentes A la hora de realizar este proyectose encontraba en desarrollo Flocker una solucioacuten desarrollada por ClusterHQque permite compartir los voluacutemenes de Docker a traveacutes de un cluster quesi bien es compatible con el planificador de Mesos el proyecto se encontrabatodaviacutea en fases tempranas de desarrollo y los sistemas de almacenamiento quesoporta quedaban fuera del aacutembito de este trabajo
Por todo ello dado que las maacutequinas se han desplegado en la nube puacuteblicade Azure se decidioacute usar su servicio de almacenamiento de objetos para lascanciones y otra maacutequina para desplegar MongoDB y asiacute mantener el modelode datos original de la aplicacioacuten La diferencia del almacenamiento de obje-tos con respecto a nivel de fichero es que el primero no tiene jerarquiacutea paraorganizar los archivos eacutestos se guardan como objetos (con sus metadatos) enun mismo espacio soacutelo diferenciaacutendose por un identificador uacutenico esto implicaentre otras cosas que se puede acceder a un fichero dado uacutenicamente su IDindependientemente de la localizacioacuten fiacutesica de eacuteste facilitando pues la gestioacuteny el desarrollo
El coacutedigo del proyecto se ha modificado en los siguientes apartados
Las direcciones de la base de datos y los balanceadores de carga asiacute comosus puertos estaban originalmente fijos Se han configurado como variablesde entorno para facilitar el descubrimiento del servicio y hacer transpa-rente la aplicacioacuten al entorno de despliegue
La API REST se ha adaptado al almacenamiento en Azure en vez de enlocal
Estas modificaciones no suponen un cambio sustancial pero permiten separala persistencia de las tareas ejecutadas por DCOS lo que facilita en granmedida su ejecucioacuten al ser totalmente sin estado y ademaacutes implican tenerlos datos bajo un mayor control
Para la orquestacioacuten de contenedores se va a usar el entorno Marathondesarrollado tambieacuten por Mesosphere Eacuteste se puede usar a traveacutes de una interfazgraacutefica la interfaz de liacutenea de comandos (en lo que sigue CLI por sus siglas eningleacutes) de DCOS o con su API HTTP
Primero se han publicado la imaacutegenes de los contenedores que encapsulanla interfaz web y la api de la aplicacioacuten en el repositorio puacuteblico DockerHub
Los despliegues en este entorno se describen mediante ficheros JSON en losque se detalla entre otras opciones la imagen del contenedor los puertos a usar
30
los recursos que debe ocupar en un nodo o las instrucciones de monitorizacioacuten
Para el servicio de descubrimiento DCOS ofrece la posibilidad de asignardirecciones IP virtuales (VIP por sus siglas en ingleacutes) a tareas que se compartenen todos los nodos DCOS lleva integrado un balanceador de carga a nivel TCP(el componente denominado Minuteman) que balancea entre las direccionesvirtuales de las tareas y todas las instancias de eacutestas a lo largo del cluster Estoes necesario por dos motivos equilibrar la carga de los equipos con el fin deevitar un punto de uacutenico fallo mediante redundancia y evitar la contienda dedirecciones al ejecutar las tareas en puertos aleatorios
Este balanceador de carga estaacute basado en el trabajo de Michael Mitzenma-cher The Power of Two Choices in Randomized Load Balancing18 A grandesrasgos el algoritmo mantiene una media moacutevil exponencial de latencias paracada destino (backend) ademaacutes de las caiacutedas consecutivas Si un destino noresponde a una negociacioacuten en tres pasos (three way handshake) de forma con-secutiva en un periodo inferior a 5 ms se considera caiacutedo El algoritmo iterasobre los destinos disponibles en base a su histoacuterico de fallos y escoge dos deforma aleatoria de los cuales coge el de mejor meacutetrica
Las direcciones virtuales soacutelo se pueden resolver dentro del cluster porello para implementar la interfaz puacuteblica de la aplicacioacuten esto es el balancea-dor de carga de la interfaz web usaremos un paquete de DCOS denominadomarathon-lb un balanceador basado en HAProxy y adaptado por MesosphereEn este caso equilibra la carga de todas instancias de las tareas ejecutadas porel entorno Marathon por sus etiquetas y permite ademaacutes definir como puntode entrada muacuteltiples hosts virtuales definidos por sus nombres completos dedominio (FQDN por sus siglas en ingleacutes) en nuestro caso la interfaz puacuteblicadel balanceador de Azure para los agentes
Por motivos de seguridad todas las tareas se ejecutan en los agentes privadoses decir los que son exclusivamente accesibles desde la red interna Por su partemarathon-lb se ejecuta en el agente puacuteblico que cuenta con IP puacuteblica y lospuertos 80 (HTTP) y 8080 abiertos de forma que la aplicacioacuten sea accesibledesde Internet Esto es posible debido a que Apache Mesos permite reservarrecursos mediante roles asignados a nodos para un uso especiacutefico De esta formala arquitectura vista desde la aplicacioacuten quedariacutea como en la figura 19
18httpswwweecsharvardedu~michaelmpostscriptstpds2001pdf
31
Figura 19 Arquitectura de la aplicacioacuten web en DCOS
Ejecucioacuten
A la hora de desplegar la aplicacioacuten DCOS puede gestionarse medianteuna interfaz graacutefica o una interfaz de liacutenea de comandos La primera se accedea traveacutes de un navegador web en el puerto 80 (HTTP) y permite instalar losentornos disponibles observar el estado de los nodos y las tareas que se estaacutenejecutando y los ficheros de registros que eacutestas generan
La CLI permite el control desde un nodo o una maacutequina remota (suponiendoque los maestros tienen IP puacuteblica y el puerto 80 abierto) ya que DCOS tieneun sistema de autorizacioacuten que permite tener una interfaz puacuteblica con ciertasgarantiacuteas de seguridad
Por su parte cada entorno de trabajo puede ser controlado por la CLI peroademaacutes cuenta con sus propias interfaces Marathon expone una API HTTPen el puerto 8080 de la direccioacuten puacuteblica de los maestros del cluster asiacute comootra interfaz graacutefica Para desplegar un contenedor se podriacutea usar la CLI
$ dcos marathon app add lt f i l e j songt
O la API HTTP
$ cu r l minusX POST http lt ip_maestro gt8080v2apps minusd ltf i l e jsongt minusH Contentminustype app l i c a t i o n j son
32
612 Nomad
La arquitectura de Nomad es maacutes sencilla ya que solo requiere de un ficheroejecutable en todos los nodos para funcionar Si DCOS es la base de instala-cioacuten de entornos de terceros Nomad integra todas las funcionalidades baacutesicasesto es gestor de recursos planificador y ejecutor en los nodos cliente Estaherramienta cuenta con un menor tiempo de desarrollo y en el momento deescribir este documento cuenta exclusivamente con los siguientes controladoresen comparacioacuten con los entornos de DCOS
Motor Docker es decir funcioacuten de orquestacioacuten de contenedores
Ejecucioacuten de archivos binarios como comandos de Shell
Ejecucioacuten de aplicaciones Java
Virtualizacioacuten de maacutequinas mediante tecnologiacutea QEMU
Todos ellos necesitan que la tecnologiacutea subyacente esteacute instalada en las maacute-quinas clientes (Docker Java QEMU) Actualmente no permite el registro decontroladores por parte de terceros aunque estaacute planificado en un futuro ofreceruna interfaz para su desarrollo
Nomad no cuenta con el servicio de descubrimiento sin embargo puede inte-grarse con la herramienta Consul desarrollada por la misma empresa Por otrolado para el balanceo de carga usaremos un contenedor Docker con HAProxyuna herramienta de coacutedigo abierto que ofrece tanto servicios de proxy como debalanceador y cuyos ficheros de configuracioacuten completaremos con el proyectoConsul Template19
Consul
Consul sigue la misma arquitectura que Nomad es decir un nodo servidorque orquesta un conjunto de maacutequinas clientes y permite a los procesos que seejecutan en los equipos definirlos como servicios ofreciendo diversas caracteriacutes-ticas entorno a estos de los cuales vamos a usar dos
Descubrimiento de servicio Las maacutequinas clientes publican en el cataacutelogode servicios las tareas en ejecucioacuten y Consul les asigna nombres de dominioaccesibles por todos los miembros del cluster a traveacutes de la interfaz DNSincluida en esta herramientaConsul se integra con Nomad de forma que todas las tareas que se ejecu-ten en la segunda son automaacuteticamente publicados como servicios de laprimera de esta manera no hace falta conocer la direccioacuten de la maacutequinacliente donde se esteacute ejecutando el proceso ya que se puede acceder a eacutela traveacutes de su nombre de dominio de forma transparente Por ejemplo si
19[httpsgithubcomhashicorpconsul-template]
33
ejecutamos una tarea con ID web en el puerto 8080 se puede acceder aella en la direccioacuten webserviceconsul8080Para que las direcciones propias de Consul las resuelva su propio DNS y noel que esteacute asignado por defecto en la maacutequina usaremos la herramientadnsmasq20 que permite especificar la direccioacuten de un servidor DNS paraconsultas de direcciones especiacuteficas
Monitorizacioacuten Permite realizar comprobaciones del servicio y seguir su esta-do Aprovecharemos esta funcionalidad tanto para definir el propio procesode Nomad como servicio de Consul como las tareas desplegadas
HAProxy + Consul Template
HAProxy es una solucioacuten versaacutetil de coacutedigo abierto que ofrece solucionesde balanceo de carga y proxy Existen otras herramientas en el mercado comoNGINX o ldirectord sin embargo HAProxy suponiacutea una solucioacuten sencilla deconfigurar para mostrar el caso de uso
El uso de estas herramientas se debe a dos motivos para que no existacontienda con respecto a los puertos de los clientes usados por las tareas eacutestos sevan a asignar de forma dinaacutemica lo que en principio implicariacutea que la aplicacioacutendeberiacutea realizar consultas DNS de tipo SRV (que incluye puertos) a la interfazde Consul y balancear la carga entre tareas por redundancia y capacidad
Como la direccioacuten IP y puerto son variables cada vez que las tareas seactualicen o se reasignen es necesario volver a configurar HAProxy de formamanual Por ello HashiCorp ha desarrollado un programa denominado Con-sul Template que realiza peticiones sucesivas a la interfaz HTTP de Consul delas direcciones fiacutesicas de un servicio y reinicia automaacuteticamente el proceso deHAProxy Asiacute definiendo estas tareas como servicios Consul podremos tantomonitorizarlas como escalar las tareas dinaacutemicamente sin necesidad de cambiarel balanceador A partir del contenedor Docker oficial de HAProxy se ha desa-rrollado otro con la configuracioacuten baacutesica y con Consul Template para desplegarlocomo una tarea en Nomad
Despliegue
Se ha usado el mismo coacutedigo que en el apartado anterior con la persistenciaen el servicio de almacenamiento de Azure Desde la perspectiva del hardwarese implementaraacute la misma infraestructura que en el caso de DCOS (figura 18)estos es definiremos dos tipos de maacutequinas clientes un agente que se conectaraacutecon el balanceador de carga con nombre de dominio puacuteblico y donde se desple-garaacute el balanceador de carga de la vista web y agentes privados no accesiblesdesde fuera del cluster y donde se ejecutaraacuten el resto de tareas en la red inter-na La principal diferencia radica en las tareas que ejecutan HAproxy y ConsulTemplate que sustituye a las direcciones IP virtuales que ofrece DCOS
20httpwwwthekelleysorgukdnsmasqdochtml
34
Figura 20 Despliegue en Azure de Nomad+Consul
Cabe matizar que los balanceadores basados en HAProxy se implementanpor necesidad de la aplicacioacuten para el descubrimiento del servicio a diferenciade los de Azure que se implementan por motivos de seguridad y escalabilidaddel cluster en siacute
Configuracioacuten Nomad
Los ficheros de configuracioacuten de las maacutequinas maacutester y cliente son similaresy comparten la mayoriacutea de las opciones como por ejemplo el nombre del nodoo la interfaz de red donde escucha Nomad las peticiones Sus opciones son engeneral auto-explicativas sin embargo existen dos detalles que matizar
El proceso de Nomad escucha las peticiones tanto de los protocolos deconsenso como del usuario a traveacutes de una interfaz de red que se debeindicar en el fichero de configuracioacuten
En el caso de los clientes se deben indicar las direcciones de los servidoresdel cluster sin embargo se trata de un sistema dinaacutemico en el que losnodos pueden sufrir errores y cambiar de direccioacuten Por ello se ha definidoNomad como un servicio de Consul y asiacute poder definir la direccioacuten de losservidores como un nombre de dominio no por su direccioacuten fiacutesica que elservidor DNS de Consul se encargaraacute de resolver
Por defecto Nomad usa los siguientes puertos
API HTTP 4646 Peticiones HTTP y recepcioacuten de oacuterdenes mediante laliacutenea de comandos
RPC 4647 Protocolo de consenso entre los nodos del cluster
Serf 4648 Protocolo de gossip entre los servidores de los centros de datosgobernados por Nomad
35
Los dos uacuteltimos deben ser interfaces alcanzables por otros nodos sin embargo laAPI HTTP por motivos de seguridad deberiacutea ser local ya que en caso contrariocualquier persona con acceso a ella tiene el control sobre la herramienta Eacutestasolo deberiacutea estar accesible en un servidor o gestionarlo mediante una terminalSSH por ejemplo En este trabajo al ser una prueba de concepto se ha abiertoen todos los nodos
Trabajos de Nomad
Las tareas se detallan en ficheros con formato HashiCorp Configuration Lan-guage un derivado del formato JSON creado por la empresa que le da nombrecompatible con eacuteste y que permite comentarios
En estos ficheros se puede definir
La regioacuten y el centro de datos donde se ejecutaraacute (Nomad permite lagestioacuten de centros de datos geograacuteficamente distribuidos en regiones)
La poliacutetica de actualizacioacuten de la tarea
Grupo de tareas esto es que se ejecutaraacuten en el mismo nodo
El nuacutemero de grupos a ejecutarescalar asiacute como los liacutemite que debencumplir los nodos asignados
La poliacutetica de reinicio ante fallo o error
Tareas El controlador su configuracioacuten los paraacutemetros del servicio aso-ciado a registrar en Consul asiacute como los recursos que consume (puertosmemoria)
En nuestro caso usamos sobre todo el controlador Docker esto eso orques-tacioacuten de contenedores en los nodos clientes y tres de sus opciones
Imagen del contenedor Se han subido todas las imaacutegenes del proyecto a Doc-ker Hub donde por defecto se busca la imagen
Puertos Los puertos a usar por el contenedor que pueden ser estaacuteticos asigna-dos por el usuario o dinaacutemicos siendo Nomad el que se encarga de mapearun puerto libre del nodo cliente al expuesto por el contenedor
Servidores DNS Como usamos la interfaz DNS de Consul como descubri-miento de servicio se debe configurar el contenedor para que use cualquiernodo del cluster como servidor DNS
Configuracioacuten Consul
Al ser desarrolladas por la misma empresa los ficheros de configuracioacuten deConsul y Nomad comparten muchas opciones Consul tambieacuten acepta peticionesa traveacutes de una interfaz de red siendo los puertos usados por defecto
36
RPC 8300 8400 Maneja la peticiones del resto de nodos y usuarios
Serf 8301 8302 Protocolo gossip
HTTP API 8500
HTTPS API Desactivada por defecto
Interfaz DNS 8600
Se debe asignar a los protocolos internos del cluster esto es RPC y Serf unainterfaz alcanzable por los nodos y por el contrarioasignar a los dos uacuteltimos ala interfaz de loopback por motivos de seguridad
Cabe destacar que Consul tambieacuten cuenta con una interfaz graacutefica que per-mite ver el estado de los equipos y los servicios registrados y que se encuentra enel mismo puerto que la API HTTP en la direccioacuten httpIP_EQUIPO8500ui
Ejecucioacuten
Tanto Nomad como Consul requieren de la ejecucioacuten de un fichero en todoslos nodos integrantes del cluster Como prueba de concepto se ha decidido usardos servidores para ambos aunque cabe matizar que es un nuacutemero ineficienteya que la caiacuteda de uno de ellos supondriacutea la peacuterdida del cuoacuterum y por tantodel consenso del cluster
En primer lugar se arrancan los servidores que son los encargados de ejecu-tar el protocolo de consenso y gestionar el cluster y a continuacioacuten los clientesque no tienen praacutecticamente estado y dependen de los servidores
En el caso de Consul se debe indicar el directorio donde se guardan losficheros que describen los servicios asiacute como el archivo que especifica el resto delas opciones
1 Se inicia el primer servidor en uno de los equipos
$ consu l agent minuscon f i gminusd i r e t c consu l d s e r v i c e s minuscon f i gminus f i l e consu l_server j son
2 Los siguientes equipos deben unirse al anterior por lo que antildeadimos elargumento join con la direccioacuten del primer servidor Para el caso de otrosservidores
$ consu l agent minuscon f i gminusd i r e t c consu l d s e r v i c e s minuscon f i gminus f i l e consu l_server j son minus j o i n ltIP_servidor1gt
37
Una vez los servidores han alcanzado el consenso y elegido un liacuteder en losclientes
$ consu l agent minuscon f i gminusd i r e t c consu l d s e r v i c e s minuscon f i gminus f i l e c on su l_c l i en t j son minus j o i n ltIP_cualquierServ idorgt
El proceso para iniciar Nomad es igual y los comandos similares sin embargoya no es necesario indicar una direccioacuten IP fija en los equipos sino el nombre dedominio del servicio de Nomad registrado por Consul En el primer servidor
$ nomad agent minusc on f i g nomad_server j son
Y el resto de equipos (con su fichero de configuracioacuten correspondiente)$ nomad agent minusc on f i g nomad_server j son minus j o i n nomad s e r v i c e consu l
Por uacuteltimo para desplegar la aplicacioacuten web se han escrito tres ficherosque detallan las tareas de la interfaz web API y los balanceadores de cargaMediante la CLI
$ nomad run minusaddress=http lt ip_c lus te r gt4646 lt f i l e hclgt
O mediante la API HTTP de Nomad$ cu r l minusX POST minusd ltf i l e hclgthttp lt ip_c lus te r gt4646 jobltjob_namegt
Ansible
Como se puede comprobar con el aumento del nuacutemero de equipos pasa aser inviable manejar todos los nodos a traveacutes de terminal Ademaacutes como seha comentado con anterioridad Nomad requiere que en los nodos clientes es-teacuten instalados las herramientas que soporten las tareas por ejemplo el motorde Docker Por ello para facilitar tanto el arranque como la instalacioacuten de lasdependencias vamos a usar Ansible una herramienta de coacutedigo abierto desarro-llada en Python que permite gestionar configuraciones aprovisionar recursosdespliegue de aplicaciones de forma automaacutetica
A grandes rasgos esta herramienta funciona mediante ficheros en formatoYAML denominados play-books que describen un conjunto de pasos a ejecutaren una lista de equipos remotos Estos pasos son ejecutados por moacutedulos inde-pendientes a traveacutes de SSH es decir en cualquier ordenador con conexioacuten a los
38
hosts dado su contrasentildea o clave puacuteblica puede arrancar el script y realizariacutealos pasos de forma remota gestionando el cluster desde un solo equipo
Se han desarrollado guiones para lo siguiente
Descarga de los binarios de Nomad y Consul en todos los nodos copiade los ficheros de configuracioacuten baacutesicos y modificarlos de acuerdo a cadanodo (nombre del equipo direccioacuten IP)
Instalacioacuten de las dependencias
Arranque de Nomad y Consul
Ansible extiende su funcionalidad a traveacutes de moacutedulos independientes que per-miten por ejemplo instalar paquetes mediante herramientas de gestioacuten de pa-quetes (APT yum) aprovisionar automaacuteticamente maacutequinas virtuales de Ama-zon EC2
Algunas opciones de los ficheros de configuracioacuten de Nomad y Consul sondependientes del nodo particular por ejemplo la interfaz de red Para estetrabajo se ha realizado un moacutedulo para modificar los ficheros de configuracioacutende forma automaacutetica En el repositorio del proyecto se encuentra una carpetadonde se encuentran todos los ficheros necesarios para desplegar un clustertotalmente funcional solo requiere de una liacutenea de terminal con Ansible
$ ans ib l eminusplaybook minus i hos t s minusk ltssh_passgt minusu ltnode_usergt s i t e yml
39
62 Servicio de integracioacuten continua
Se ha implementado un sistema de integracioacuten continua que permite ejecu-tar tareas de compilacioacuten y pruebas de forma distribuida aumentando asiacute elrendimiento de los equipos En primer lugar se detallaraacute los motivos por los quepuede resultar beneficioso para las empresas una implementacioacuten de este tipo alo que seguiraacute los detalles del despliegue
621 DevOps
Metodologiacutea que defiende la comunicacioacuten y colaboracioacuten entre desarrolla-dores de software y los profesionales de operaciones a lo largo de todo el ciclo devida de una aplicacioacuten Estaacute muy relacionado con el desarrollo aacutegil de softwareesto es un enfoque para los proyectos que defiende el desarrollo iterativo e in-cremental donde los requisitos y soluciones evolucionan con el tiempo seguacuten lanecesidad del proyecto DevOps extiende esta filosofiacutea a todas los componentesde un servicio incluyendo sistemas y operaciones
Se trata de un concepto que cada organizacioacuten o empresa adapta a suspropias necesidades y procesos de negocio en este proyecto nos vamos a centraren la integracioacuten continua una praacutectica fundamental tanto del desarrollo aacutegilcomo de esta filosofiacutea
622 Integracioacuten Continua
Se define como una praacutectica de desarrollo software donde los miembros delequipo ponen en comuacuten su trabajo frecuentemente al menos una vez al diacutea21Cada integracioacuten se verifica con una compilacioacuten automaacutetica que incluye laejecucioacuten de pruebas para detectar errores de integracioacuten tan pronto como seaposible
Desde el punto de vista operativo esto supone automatizar la configuracioacutende equipos o el despliegue de maacutequinas virtuales donde compilar el proyecto yejecutar las pruebas y posteriormente eliminarlas Este flujo de trabajo se vebeneficiado en entornos distribuidos ya que el objetivo del desarrollador es com-probar el resultado de las pruebas raacutepidamente sin preocuparse del despliegueo los propios equipos
Para esta prueba de concepto vamos a usar Jenkins un servidor de integra-cioacuten continua escrito en Java que nos permite definir trabajos que contendraacutenla descripcioacuten tanto del entorno como su ejecucioacuten
Este sigue una estructura maestro-esclavo muy similar al de los gestores declusters usados en este proyecto el maestro contiene toda la loacutegica del servicio
21httpmartinfowlercomarticlescontinuousIntegrationhtml
40
trabajos autenticacioacuten y los esclavos son los encargados de la ejecucioacuten ensiacute Jenkins tiene varias viacuteas para aprovisionar los uacuteltimos
Mediante SSH
Interfaz graacutefica
Desarrollar un script propio
Ejecucioacuten de un fichero java
La ventaja de usar planificadores es que el despliegue de esclavos es dinaacutemicoes decir no tener una maacutequina especiacuteficamente configurada para ello DCOS yNomad se encargaraacuten de configurar estos despliegues en sus maacutequinas y poste-riormente eliminarlos Para ello se ha usado la uacuteltima opcioacuten definiendo tareasque descarguen el fichero java Con todo ello se consigue un entorno de inte-gracioacuten continua eficiente que ademaacutes permite la ejecucioacuten de otros servicios deforma independiente
Jenkins permite la creacioacuten de plugins que extienden sus funcionalidadesTanto Nomad22 como Apache Mesos cuentan con uno que permite su integra-cioacuten
Para esta prueba se va a usar el mismo proyecto que para el caso de usode orquestacioacuten de contenedores la aplicacioacuten web al que se le ha antildeadido untest para comprobar que se conecta correctamente a la base de datos medianteMocha un framework de Nodejs Por otro lado se antildeade el plugin de git ya queel coacutedigo se obtiene de GitHub el repositorio remoto de control de versiones delproyecto
El proceso general de ejecucioacuten seriacutea como sigue
1 Se ejecuta el maestro de Jenkins como tarea Docker partiendo de la imagenoficial
2 Al arrancar un trabajo se manda una tarea a los planificadores que laasignaraacuten a un nodo cliente Esta tarea consiste en la descarga del ficherode configuracioacuten Java y arrancarlo configurando el equipo como un clientede Jenkins temporalmente
3 Jenkins ejecuta el trabajo en el nuevo cliente en este caso iniciar la apli-cacioacuten web iniciar las pruebas y generar un informe
4 Se elimina el cliente
A continuacioacuten se detallan los matices de cada herramienta a la hora de imple-mentar este servicio
22Desarrollado por Ivo Verberk httpwwwivoverberknl
41
623 Jenkins con Nomad
El plugin permite la ejecucioacuten del fichero Java mediante dos controladorescontenedores Docker y Java En este proyecto nos hemos decantado por el pri-mero ya que nos ahorra instalar la maacutequina virtual de java en todos los nodoscliente Por ello se ha construido un contenedor base con Java para la ejecucioacutendel fichero de configuracioacuten y Nodejs para lanzar la aplicacioacuten web
El plugin se configura con la direccioacuten IP del cluster y el contenedor queejecuta el esclavo Jenkins Por su parte el trabajo en Jenkins se define conel repositorio en GitHub donde se aloja el coacutedigo del proyecto a probar y loscomandos a ejecutar en este caso npm update y npm test
624 Jenkins con DCOS
En el caso de DCOS su sistema de paquetes incluye Jenkins por lo queal instalarlo ya se tiene la configuracioacuten de Mesos totalmente funcional Sinembargo para ejecutar la aplicacioacuten en particular y las pruebas se requiere deNodejs en los equipos esclavos por ello debemos antildeadir un plugin de Jenkinsque permite instalar este entorno antes de ejecutar el trabajo Una vez hechoesto soacutelo queda definir la tarea igual que en el caso anterior
Cabe destacar que Mesosphere tambieacuten ha desarrollado un plugin que per-mite hacer despliegues en Marathon de tal manera que permitiriacutea con cadacommit del coacutedigo compilar la imagen del contenedor Docker y desplegarlaautomaacuteticamente aunque en este proyecto no se ha hecho pruebas de esta fun-cionalidad
42
7 Escalando la infraestructura
Uno de los factores clave que se busca a la hora de implementar sistemasdistribuidos es el poder escalar la infraestructura de forma maacutes sencilla estoes detectar que las maacutequinas estaacuten alcanzando el liacutemite de su capacidad yaumentar eacutesta ya sea mejorando sus caracteriacutesticas teacutecnicas o antildeadiendo maacutesnodos al cluster
El coacutedigo y todos los ficheros de configuracioacuten de esta seccioacuten tambieacuten sepueden encontrar en el repositorio del proyecto en GitHub23
71 Disentildeo
Microsoft Azure permite organizar los servicios cloud de forma loacutegica a traveacutesde grupos de recursos y asiacute poder crear o eliminar eacutestos en conjunto parauna aplicacioacuten determinada (por ejemplo una aplicacioacuten web suele requerir demaacutequinas virtuales bases de datos almacenamiento) Ademaacutes dispone dela opcioacuten de crear plantillas en formato JSON que permite al desarrolladordefinir los recursos y su interrelacioacuten para desplegar de forma automaacutetica unainfraestructura TI en la nube
Azure tambieacuten ofrece la posibilidad de monitorizar el estado de las maacutequinasvirtuales a traveacutes de extensiones lo que permite configurar el escalado automaacute-tico al alcanzar cierto liacutemite definido por el operador Eacutesta es a priori la formaen que deberiacutea implementarse hablando en teacuterminos de eficiencia sin embargoesta aproximacioacuten es totalmente dependiente de la plataforma es decir no sepuede extrapolar a otro proveedor o sobre recursos propios sin realizar un nue-vo disentildeo En este proyecto las tareas que son ejecutadas por estos equipos notienen estado ya que todo lo relativo a la persistencia lo hemos asignado fueradel cluster esto permite escalar la plataforma a traveacutes de otra aproximaciones
Las plantillas aceptan una serie de variables a indicar por el usuario entreotras los conjuntos de escala para definir los nodos aceptan una variable quedefine el nuacutemero de maacutequinas que los componen Por otro lado Azure ofreceuna API REST y kits de desarrollo software (SDK por sus siglas en ingleacutes) quepermiten su despliegue de forma programaacutetica Aprovechando estas facilidadesen este proyecto se va a aproximar la escalabilidad con el sucesivo desplieguede la infraestructura de forma automaacutetica se monitorizan los equipos y si sedetecta una maacutequina excesivamente cargada se aumenta el nuacutemero de equiposen la plantilla y se vuelve a desplegar
23httpsgithubcomAntonioAlfrzCloud-Orchestrators
43
En este proyecto se han disentildeado las plantillas para desplegar la arquitec-tura necesaria tanto de Nomad como de DCOS En el caso de la primera eldespliegue es maacutes descriptivo ya que incluye maacutequinas virtuales grupos de se-guridad redes En el caso de DCOS Azure cuenta con un servicio especiacuteficopara clusters gobernados por DCOS denominado Azure Container Service queincluye los componentes necesarios y la instalacioacuten ya realizada
72 Implementacioacuten
En primer lugar para monitorizar el estado de los equipos se va a usar laherramienta Nagios un sistema que permite controlar el estado del hardwarey los servicios de un equipo Se trata de una herramienta muy completa de laque se va a usar su capacidad para ejecutar comandos (plugins) en los nodospara detectar picos de carga generar alertas y ejecutar programas para estoseventos
Se ha desplegado una maacutequina virtual con esta herramienta en ambos siste-mas y se ha instalado una extensioacuten de Nagios (Nagios Remote Plugin Executor)en todos los nodos que permite ejecutar comprobaciones remotamente en con-creto para esta prueba de concepto medir el nivel de saturacioacuten de la unidadcentral de procesamiento (CPU por sus siglas del ingleacutes) Cuando sucede uncambio de estado de una maacutequina esto es cuando este paraacutemetro supera el liacutemi-te definido por el operador Nagios permite actuar en consecuencia ejecutandoprogramas por ello se ha desarrollado un script que ejecuta lo siguiente
Un programa desarrollado en Python con el SDK de Azure que modificalas plantillas y despliega los recursos
Un guioacuten de Ansible para instalar todos los componentes necesarios en lasnuevas maacutequinas y arrancar de nuevo el cluster y las aplicaciones
44
8 Resultados y conclusiones
En este uacuteltimo apartado se da una visioacuten global del proyecto asiacute como a lasconclusiones maacutes importantes a las que se ha llegado y posibles temas futurosde desarrollo
81 Comparacioacuten
Ambas herramientas ofrecen las funcionalidades para gestionar los recursoseficientemente ofreciendo a los desarrolladores una plataforma donde desplegarsus aplicaciones de forma distribuida independientemente de los equipos fiacutesicosy el hardware que las soporten
DCOS es una herramienta que en un comienzo fue privativa pero cuyos res-ponsables la empresa Mesosphere decidieron publicar una versioacuten de coacutedigoEacutesta nos permite gestionar un cluster de una forma sencilla y usable ademaacutes decomplementarlo con otras herramientas como el balanceador de carga integradoo la autenticacioacuten de usuarios ademaacutes estaacute basada en Apache Mesos un pro-yecto de relativa madurez y con el soporte de la Apache Software FoundationDe forma resumida DCOS ofrece muchas posibilidades y servicios a cambiode una arquitectura e instalacioacuten maacutes compleja
Por su parte HashiCorp con menor tiempo de desarrollo ha conseguidouna herramienta muy sencilla de desplegar que ademaacutes cumple con todas lasfuncionalidades baacutesicas ejecutando un simple binario en cada nodo se puededesplegar un gestor de clusters totalmente funcional Sin embargo no cuentacon todas las posibilidades de Mesos (Nomad cuenta con menos controladoresque entornos posibles de Mesos) ni con los antildeadidos de DCOS lo que implicael uso de otras herramientas para complementar el servicio (Consul HAProxy)
De entre las dificultades encontradas al usar estas herramientas y desplegaraplicaciones sobre ellas se puede destacar la depuracioacuten en ocasiones se desco-noce si un error viene de la propia herramienta de la aplicacioacuten desplegada o delequipo fiacutesico si no se cuenta con un sistema de procesamiento de registro unose puede encontrar con muacuteltiples terminales abiertas inspeccionando numerososficheros de registro buscando posibles errores Ademaacutes no dejan de ser solucio-nes que para usar eficientemente se debe conocer parte de su funcionamientoy sintaxis a la hora de describir la tareas lo que supone un esfuerzo antildeadido yaque cada una tiene sus particularidades y liacutemites
45
82 Conclusiones
En una sociedad cada vez maacutes digital las empresas deben adaptarse a unmercado cuya demanda de contenido no deja de crecer Las nuevas arquitecturascomo microservicios asiacute como la gran cantidad de datos generada implica queuna mejor gestioacuten de los recursos y la rapidez para desplegar o escalar solucionesdando valor al cliente lo maacutes raacutepido posible es uno de los objetivos de todas lasempresas de base tecnoloacutegica
Las ventajas que ofrecen los planificadores con aplicaciones distribuidas sonnumerosas sin ir maacutes lejos empresas tan punteras como Google llevan maacutesde 10 antildeos orquestando contenedores24 Por un lado permiten aumentar elrendimiento de los equipos propios y por otro implementar un servicio comoplataforma para despliegues distribuidos sobre cualquier conjunto hardware deesta forma se provee un servicio similar al de la nube puacuteblica pero con laprincipal diferencia de que se elimina la independencia con el proveedor (vendorlock-in) esto es las aplicaciones no tienen limitaciones impuestas por eacuteste talescomo lenguaje de programacioacuten o herramientas y permite despliegues hiacutebridosentre recursos propios y la nube
83 Objetivos conseguidos
Implementacioacuten de los planificadores propuestos en la nube Se ha en-tendido y detallado el funcionamiento de estas herramientas y se hanimplementado en el servicio de infraestructura de Microsoft Azure
Despliegue de aplicaciones y servicios distribuidos Servicios que se usanactualmente en la industria del desarrollo software asiacute como una aplica-cioacuten web con una arquitectura moderna han sido desplegados de formadistribuida en los equipos cumpliendo con la funcionalidad esperada ade-maacutes de consiguiendo una alta disponibilidad
Aproximacioacuten de arquitectura escalable Se ha hecho una aproximacioacutende infraestructura escalable de forma que sea parcialmente extrapolable aotros proveedores
24httpwwwnextplatformcom20160322decade-container-control-google
46
84 Liacuteneas de investigacioacuten
Siguiendo con la materia de este proyecto se presentan posibles liacuteneas deinvestigacioacuten
Analizar el despliegue con estas herramientas de aplicaciones de Big Datay comparar la eficiencia con respecto a soluciones especializadas
Analizar el rendimiento de los algoritmos de planificacioacuten antes pruebasde estreacutes y situaciones de alta contienda
Comparar el uso de estas herramientas con las praacutecticas actuales de laindustria o implementacioacuten en un sistema de produccioacuten real
47
Referencias
[1] LA Barroso y U Houmllzle laquoThe Datacenter as a Computer An Introduc-tion to the Design of Warehouse-Scale Machinesraquo En Morgan amp ClaypoolPublishers ()
[2] Systems Research Group ndash NetOS (University of Cambridge) The evolu-tion of cluster scheduler architectures 2016 url httpswwwclcamacukresearchsrgnetoscamsasblog2016-03-09-scheduler-architectureshtml
[3] A Das I Gupta y A Motivala SWIM Scalable Weakly-consistent Infection-style Process Group Membership Protocol Inf teacutec Dept of ComputerScience Cornell University url https www cs cornell edu ~asdasresearchdsn02-swimpdf
[4] D Dubhashi y A Das Mastering Mesos PACKT Publishing mayo de2016
[5] The Apache Software Foundation Apache Mesos documentation urlhttpsmesosapacheorg
[6] David Greenberg Building Applications on Mesos OrsquoReilly Media 2016[7] Armand Grillet Comparison of Container Schedulers Inf teacutec Technische
Universitaumlt Berlin[8] HashiCorp Consul documentation url httpswwwconsulio[9] HashiCorp Nomad documentation url httpsdcosio[10] Dan C Marinescu Cloud computing theory and practice Morgan Kauf-
mann 2013[11] Mesosphere DCOS documentation url httpswwwnomadproject
io[12] Microsoft Azure documentation url httpsazuremicrosoftcom
es-esdocumentation[13] D Ongaro y J Ousterhout In Search of an Understandable Consensus
Algorithm Inf teacutec Stanford University url httpsraftgithubioraftpdf
[14] Fei Teng laquoRessource allocation and schelduling models for cloud compu-tingraquo Tesis de mtriacutea Ecole Centrale Paris 2011
[15] A Williams y col Automation and Orchestration with Docker and Contai-ners A Comprehensive Overview of the Docker and Container Ecosystem3 The New Stack 2016
48
- Resumen
- Summary
- Iacutendice de figuras
- Introduccioacuten y objetivos
-
- Contexto
- Objetivos
- Estructura del documento
-
- Cloud Computing
- Nuevas cargas de trabajo
- Gestioacuten de recursos Planificadores
-
- Sistemas distribuidos
-
- Clasificacioacuten
-
- Herramientas
-
- DCOS
-
- Apache Mesos
- Ejemplos de uso
-
- Nomad
-
- Protocolo de consenso Raft
- Protocolo gossip SWIM
- Planificacioacuten
-
- Casos de uso y despliegue
-
- Aplicacioacuten Web
-
- DCOS
- Nomad
-
- Servicio de integracioacuten continua
-
- DevOps
- Integracioacuten Continua
- Jenkins con Nomad
- Jenkins con DCOS
-
- Escalando la infraestructura
-
- Disentildeo
- Implementacioacuten
-
- Resultados y conclusiones
-
- Comparacioacuten
- Conclusiones
- Objetivos conseguidos
- Liacuteneas de investigacioacuten
-
2 Cloud Computing
El NIST (National Insitute of Standards and Technology) define este con-cepto como un modelo que permite un acceso ubicuo y bajo demanda de formaremota a un conjunto compartido de recursos de computacioacuten que pueden seraprovisionados y liberados con unos miacutenimos esfuerzos de gestioacuten por parte delproveedor del servicio3
Clasificacioacuten
La computacioacuten en la nube abarca una amplia variedad de servicios y enfo-ques por lo que en primer lugar se va a dar una clasificacioacuten para posterior-mente entrar maacutes en detalle Existen distintos modelos de nube atendiendo a lagobernabilidad de la infraestructura seguacuten el NIST
Nubes puacuteblicas Los servicios y recursos son ofertados de forma puacuteblica yson provistos por una organizacioacuten que los comercializa bajo demanda
Nube privada Los recursos son gestionados por una uacutenica organizacioacutenpara su propio uso
Nube comunitaria En este caso la infraestructura es administrada por unconjunto de organizaciones con objetivos comunes
Nube hiacutebrida Una combinacioacuten de las anteriores
A su vez los distintos servicios que ofrece se pueden clasificar atendiendo algrado de control del usuario
Servicios de software (Software as a Service SaaS) El proveedor se encargade toda la gestioacuten de la infraestructura y oferta aplicaciones a las cuales elcliente puede acceder de forma ubicua a traveacutes de diversos clientes comoun navegador web Por ejemplo Office 365 o Google docs
Servicios de plataforma (Platform as a Service PaaS) Modelo de distribu-cioacuten que ofrece la capacidad de desplegar aplicaciones desarrolladas por elcliente usando las herramientas y lenguajes de programacioacuten soportadaspor el proveedor pero sin la posibilidad de gestionar los recursos consu-midos En este caso el cliente solo tiene control sobre la propia aplicacioacuteny algunas configuraciones del entorno Es el caso de Heroku o Google AppEngine
3httpnvlpubsnistgovnistpubsLegacySPnistspecialpublication800-145pdf
3
Servicios de infraestructura (Infrastructure as a Service IaaS) Se ofertanrecursos de computacioacuten puros como procesamiento o almacenamientomediante una plataforma de virtualizacioacuten El cliente puede controlar elsistema operativo componentes de red y aplicaciones
Figura 1 Comparacioacuten Centro de datos - Computacioacuten en la nubeFuente httpsad-hocnet
De entre las numerosas ventajas que ofrece la computacioacuten en la nube se puededestacar su flexibilidad ya que permite aprovisionar recursos y adaptarlos deacuerdo a la demanda reduce el capital inmovilizado y su amortizacioacuten laubicuidad que permite su consumo desde cualquier parte con conexioacuten a la redy la seguridad y fiabilidad que ofrece el proveedor que normalmente cuenta conrecursos geograacuteficamente distribuidos frente a la gestioacuten y mantenimiento derecursos propios
4
3 Nuevas cargas de trabajo
Las organizaciones que cuentan con sus propios infraestructuras TI han co-menzado a adoptar un enfoque de nube privada para gestionar las tareas ofunciones informaacuteticas sobre las que se sustentan el negocio ya que una es-tructura virtualizada puede ofrecer ventajas con respecto a las adaptaciones decentros de datos tradicionales en los aacutembitos de rendimiento escalabilidad eincluso seguridad4
A su vez se han desarrollado nuevas tecnologiacuteas que suponen cargas detrabajo dinaacutemicas y con gran intensidad de consumo de datos para las empresasque se ven beneficiadas al desplegarlas en recursos virtualizados
Big data
Con la creciente aceptacioacuten de las tecnologiacuteas TIC por parte de la sociedadla cantidad de datos generados en la red es ingente Las profesionales de TI tienecomo objetivo extraer valor de eacutestos para por ejemplo prever las tendencias delmercado Sin embargo este incremento exponencial hace que su procesamientoy almacenamiento requiera de un sistema con gran escalabilidad dado el hechode que una sola maacutequina no puede proveer de la capacidad necesaria
Integracioacuten continua
Modelo informaacutetico que consiste en hacer integraciones automaacuteticas de unproyecto con cualquier cambio en el coacutedigo con el objetivo de detectar fallosde forma temprana Esto implica la compilacioacuten del coacutedigo y su ejecucioacuten enun entorno de pruebas automaacuteticamente un proceso que mediante tecnologiacuteasde virtualizacioacuten permiten simular entornos con eficiencia y rapidez Su imple-mentacioacuten en sistemas distribuidos permite tanto una mejor planificacioacuten comoun mejor rendimiento de los recursos
Arquitectura de microservicios
Enfoque para desarrollar aplicaciones software como un conjunto de serviciosautoacutenomos que se comunican entre siacute a diferencia de aproximaciones monoliacuteti-cas donde la loacutegica del servicio estaacute desarrollada como una unidad Un sistemadistribuido permite el despliegue de los componentes en distintas maacutequinas loque mejora tanto su escalabilidad como la tolerancia a fallos
4httpswwwakamaicomesesresourcespublic-private-cloudjsp
5
Docker
Proyecto de coacutedigo abierto que facilita y automatiza el despliegue de aplica-ciones al encapsular el entorno de trabajo en contenedores Linux una tecnologiacuteaque permite a un sistema fiacutesico ejecutar muacuteltiples instancias de sistemas opera-tivos aislados mediante entornos virtuales con sus propios espacios de procesosy redes pero compartiendo el nuacutecleo (kernel) con el equipo anfitrioacuten
En la figura 2 se compara la pila de una virtualizacioacuten tradicional con res-pecto a los contenedores no se simula el sistema operativo por lo que el procesoes mucho maacutes ligero
Docker se caracteriza por
Autosuficiencia Los contenedores cuentan con las libreriacuteas y configuracio-nes necesarias para ejecutarse de manera autoacutenoma al compartir el nuacutecleo
Portabilidad El hecho de que sean autosuficientes implica que es inde-pendiente del host es decir se puede desplegar en cualquier equipo quesoporte esta tecnologiacutea
Tamantildeo El peso de un contenedor es sustancialmente inferior a otrastecnologiacuteas de virtualizacioacuten
Figura 2 Arquitectura DockerFuente httpsdockercom
6
Los componentes fundamentales de esta herramienta son
Imaacutegenes Describen el entorno de base sobre el que ejecutar el contene-dor por ejemplo la imagen del sistema operativo Ubuntu Sobre eacutesta seconstruyen las aplicaciones particulares del usuario dando lugar a otraimagen
Contenedores Se crean a partir de las imaacutegenes y comprenden todo aquellonecesario para arrancar la aplicacioacuten decir su entorno de ejecucioacuten
bull Voluacutemenes Encargados de gestionar la persistencia de datos e inde-pendientes del ciclo de vida del contenedor
Registros Pueden ser puacuteblicos o privados y almacenan las imaacutegenes elregistro puacuteblico oficial de Docker es Docker Hub
Dadas estas caracteriacutesticas los profesionales TI estaacuten comenzando a adoptarDocker ya que facilita tanto los despliegues como el trabajo compartido en dis-tintos entornos Sin embargo esto requiere de un software que permita desplegarlos distintos contenedores de forma que puedan trabajar en conjunto procesoque se ha denominado orquestacioacuten de contenedores
7
4 Gestioacuten de recursos Planificadores
Para sacar el maacuteximo provecho a las tecnologiacuteas anteriormente descritaslo ideal es desplegarlas en sistemas distribuidos sin embargo esto aumenta lacomplejidad del propio despliegue asiacute como la necesidad de software especiali-zado para ello Se necesitan algoritmos de planificacioacuten que permitan obtener elmaacuteximo rendimiento de los recursos por un lado y dar ciertas garantiacuteas de quetodas las tareas y procesos se van a ejecuta por otro
41 Sistemas distribuidos
En primer lugar se definen los sistemas distribuidos o clusters como unconjunto de ordenadores conectados entre siacute cuyo objetivo es trabajar como unauacutenica instancia de gran capacidad5
Su clasificacioacuten variacutea de acuerdo a cada autor pero en general se puedendividir seguacuten su objetivo en alto rendimiento aquellos cuyo objetivos es proveerde gran capacidad de coacutemputo gracias al conjunto de los nodos y alta disponi-bilidad con los cuales se busca la fiabilidad del sistema mediante redundanciayo balanceo de carga
El intereacutes de este proyecto recae en los uacuteltimos ya que el objetivo es porun lado ofrecer al desarrollador un entorno donde desplegar sus aplicaciones deforma distribuida y por otro maximizar el rendimiento de los recursos
De forma general las caracteriacutesticas que se buscan son las siguientes
Elasticidad Adaptacioacuten a cargas dinaacutemicas de trabajo aumentando (o dis-minuyendo) recursos de manera automaacutetica de tal forma que la utilizacioacutensea lo maacutes cercana a la demanda
Disponibilidad Capacidad de un sistema para mantener el servicio fun-cional
Tolerancia a fallos Recuperacioacuten del servicio ante el fallo de un compo-nente
Balanceo de carga Compartir las tareas entre las diferentes maacutequinasredundadas evitando asiacute puntos de uacutenico fallo
5httpsenwikipediaorgwikiComputer_cluster
8
Los programas que se implementan en entornos distribuidos se caracterizanpor ejecutarse de forma concurrente en equipos independientes estar conectadospor una red que introduce fallos aleatorios y no compartir memoria ni reloj Estoimplica entre otras cosas que
Los nodos soacutelo tienen un acceso raacutepido a su memoria local por lo quecualquier informacioacuten relativa al estado global puede ser potencialmenteerroacutenea
Las maacutequinas pueden sufrir caiacutedas de forma aleatoria
El intercambio de informacioacuten puede fallar ya sea por error en transmisioacuteno por caiacuteda de los nodos
Estas dificultades se ponen de manifiesto en el teorema de CAP en cienciasde la computacioacuten el teorema de CAP que lanzado inicialmente como conjetu-ra en el antildeo 2000 por Eric Brewer (motivo por el cual al teorema se le conoceformalmente como teorema de Brewer) y posteriormente demostrado en el antildeo20026 establece que es imposible para un sistema de coacutemputo distribuido ga-rantizar simultaacuteneamente dos de las tres propiedades siguientes
Consistencia (Consistency) es decir que todos los nodos vean la mismainformacioacuten al mismo tiempo Se busca que un cambio en el sistema soacutelose ejecute satisfactoriamente si y soacutelo si se efectuacutea a todos las maacutequinasde tal forma que los datos entre ellos nunca difieren y la respuesta a unapeticioacuten sea la misma independientemente del nodo que la atienda
Disponibilidad (Availability) esto es la garantiacutea de que toda peticioacuten debeobtener una respuesta (servicio funcional) aunque exista inconsistenciaentre nodos
Tolerancia al particionado (Partition Tolerance) es decir que el sistemasiga funcionado a pesar de un fallo en la comunicacioacuten entre los equipos
Por todo lo expresado anteriormente conseguir un sistema distribuido capazde ofrecer procesamiento de forma transparente implica una arquitectura TIcompleja Se requieren de subsistemas y herramientas que permitan la cohesioacutenentre todos los nodos
Gestor de los recursos de las diferentes maacutequinas
Monitorizacioacuten tanto de los servicios activos como de la funcionalidad delsistema ademaacutes de poliacuteticas para recuperacioacuten de fallo
Protocolos de consenso que permitan a los nodos ser consistentes con elestado global del cluster
6urlhttpsgroupscsailmitedutdspapersGilbertBrewer2pdf
9
Herramientas de descubrimiento de servicios que permita la comunicacioacutenentre tareas distribuidas
Planificadores Encargados de distribuir las tareas y procesos en las dife-rentes maacutequinas asignaacutendole parte de su capacidad
Los planificadores del ingleacutes cluster schedulers son un componente funda-mental por lo que vamos a entrar un poco maacutes en detalle en ellos
Planificadores (Cluster Schedulers)
Es el software encargado de monitorizar los recursos usados por cada maacute-quina perteneciente a un cluster y distribuir la carga de trabajo entre ellas deacuerdo a un poliacutetica o reglas
Este tipo de herramientas comparten cierta terminologiacutea que es relevantedefinir
Tarea Unidad de trabajo computacional comprendida por una secuenciade instrucciones datos de entrada y recursos asociados Por ejemplo laejecucioacuten de un comando o el arranque de una base de datos
Nodo Cualquier maacutequina integrante de un cluster En una arquitecturamaestro-esclavo se definen dos roles
bull Cliente Agente Esclavo Aquellos ordenadores que se encargan deejecutar las tareas
bull Maestro Servidor Su objetivo es mantener el estado del cluster ygestionar sus recursos
411 Clasificacioacuten
A lo largo de los uacuteltimos antildeos se han desarrollado diferentes tipos de plani-ficadores[2]
Monoliacutetico
Un solo planificador que se encarga de distribuir todas las tareas entran-tes La mayoriacutea de los planificadores en computacioacuten de alto rendimiento asiacutecomo Borg desarrollado por Google son de este tipo En la figura 3 se pue-de observar de forma graacutefica el procedimiento siendo las cajas grises maacutequinaspertenecientes al cluster y los ciacuterculos las tareas a asignar
10
Figura 3 Planificador monoliacuteticoFuente httpswwwclcamacuk
Planificacioacuten de dos niveles
La mayoriacutea de los clusters ejecutan aplicaciones con distintas necesidadesdesde procesos casi instantaacuteneos hasta servicios persistenteslo que implica dis-tintas necesidades de recursos
Por ello la planificacioacuten a dos niveles distingue dos funciones la gestioacutende recursos (gestor) y la disposicioacuten de las tareas (planificador) Cada serviciotiene su propio planificador de tal manera que el gestor les ldquoofertardquo recursosde acuerdo a una poliacutetica y los planificadores se encargan de escoger la maacutesadecuada Esto permite que el proceso de distribucioacuten sea maacutes acorde con lasnecesidades de los diferentes servicios Apache Mesos que detallaremos maacutesadelante sigue este esquema
Como desventaja cabriacutea sentildealar que esta programacioacuten implica que los pla-nificadores pierden la vista general de la infraestructura y las tareas soacutelo puedenejecutarse con los recursos que les son ofrecidos lo que dificulta la implementa-cioacuten de prioridades de ejecucioacuten de tareas entre otras
Figura 4 Planificador de dos niveles
11
Planificacioacuten de estado compartido
Muacuteltiples reacuteplicas del estado del cluster se actualizan independientementepara cada planificador como se observa en la figura 5 cuando sucede un cambiode forma local el planificador se encarga de informar al resto
Ejemplo de este tipo son Omega la evolucioacuten de Borg por parte de GoogleMicrosoft Apollo y Nomad que usaremos para los casos de uso
De entre las desventajas se puede destacar el hecho de que en general losnodos trabajan con informacioacuten desactualizada lo que conlleva una degradacioacutendel rendimiento en situaciones de alta contienda
Figura 5 Planificador de estado compartido
Planificacioacuten distribuida
En este caso no existe coordinacioacuten entre los distintos planificadores Cadauno de ellos funciona con su propia vista del cluster Las tareas pueden serorganizadas por cualquiera de ellos y desplegadas en cualquier parte del clusteren base a la aleatoriedad y multiplexacioacuten estadiacutestica de los flujos de trabajosin ninguacuten control central
Figura 6 Planificador distribuido
12
5 Herramientas
En la industria comienzan a aparecer soluciones software de coacutedigo abiertoque aglutinan los servicios necesarios para gestionar la infraestructura TI de ma-nera maacutes eficaz El objetivo es doble se busca facilitar la gestioacuten de los recursosde computacioacuten para organizaciones con instalaciones propias mediante su usocon un enfoque cloud esto es desplegar aplicaciones a traveacutes de un conjuntode ordenadores de forma transparente y sin tener en cuenta la infraestructurasubyacente o aprovechar el maacuteximo rendimiento de la infraestructura de losproveedores cloud puacuteblicos de forma que se tiene el maacuteximo control sobre eacutestapero no se depende de las soluciones propietarias permitiendo asiacute despliegueshiacutebridos
Entre estas herramientas se pueden destacar
OpenStack Proyecto desarrollado por la fundacioacuten del mismo nombre paraproporcionar servicios de infraestructuras (IaaS) basado en componentesque se comunican a traveacutes de APIs El componente Magnum incluye mo-tores de orquestacioacuten de contenedores
Kubernetes Sistema de orquestacioacuten de contenedores Docker creado por Goo-gle
CoreOs Sistema operativo basado en Linux disentildeado para despliegues distri-buidos sobre contenedores incluyendo mecanismos de descubrimiento deservicio y comparticioacuten de configuracioacuten
Docker Swarm Herramienta nativa de orquestacioacuten de contenedores Docker
YARN Entorno de gestioacuten de recursos y aplicaciones distribuidas de Hadoopuna libreriacutea software de procesamiento de grandes conjuntos de datos
Como podemos observar existe un gran rango de opciones para gestionar lainfraestructura desde un bajo nivel como puede ser OpenStack hasta Kuberne-tes o Docker Swarm que ofrecen exclusivamente orquestacioacuten de contenedores
En este trabajo se ha optado por Mesosphere DCOS y HashiCorp Nomadque se encuentran en el teacutermino medio su objetivo es proporcionar serviciosde plataforma que permitan la coexistencia dediferentes cargas de trabajo en elcluster
13
51 DCOS
DCOS es un proyecto de coacutedigo abierto7 creado y desarrollado por la empre-sa Mesosphere Se describe como un sistema operativo distribuido que abstraelos recursos de un cluster (capacidad de procesamiento memoria) permite lagestioacuten de muacuteltiples ordenadores de forma transparente y simplifica la instala-cioacuten de aplicaciones distribuidas
Su arquitectura se puede comparar a la de Linux en teacuterminos de nuacutecleo(kernel) y espacio de usuario El primero consta de recursos protegidos a losque no puede acceder el usuario e involucra operaciones de bajo nivel comoasignacioacuten de recursos o aislamiento de procesos En el espacio de usuario seejecutan las aplicaciones y servicios de maacutes alto nivel
Siguiendo con este siacutemil el nuacutecleo de DCOS estaacute basado en Apache Mesosque se explicaraacute en un apartado posterior y el espacio de usuario que estaacute com-prendido por los componentes del sistema esto es las diferentes herramientasque en conjunto conforman DCOS y los servicios encargados de planificar yejecutar las aplicaciones y tareas del usuario
Figura 7 Arquitectura DCOSFuente httpsdcosio
De entre los componentes que conforman DCOS destacan
Admin Router Balanceador de carga central basado en NGINX que dis-pone un proxy entre todos los servicios en el puerto 80 permitiendo sugestioacuten mediante la interfaz graacutefica Ademaacutes se encarga de la autenticacioacutenpara acceder al panel de administracioacuten
Cosmos Gestor de paquetes de las aplicaciones
Diagnostics Se ejecuta en todos los nodos y se encarga de monitorizar elestado de los daemons que sustentan DCOS
7Desde abril de 2016 httpsmesospherecomblog20160419open-source-dcos
14
Exhibitor Gestiona y automatiza el despliegue de ZooKeper la herra-mienta que provee de configuracioacuten centralizada y registro de nombres
Marathon Equivale al proceso init de los sistemas tipo Unix esto es elprimer proceso en ejecucioacuten tras la carga del kernel y que genera los demaacutesprocesos Se encarga de arrancar y monitorizar las aplicaciones y servicios
Mesos-DNS Servicio de DNS interno que define el dominio mesos pa-ra nodos y tareas en el cluster es decir permite resolver nombres conindependencia de la direccioacuten fiacutesica
Minuteman Balanceador de carga integrado a nivel TCPUDP disponiblepara las propias aplicaciones
Por otra parte se definen como servicios a las diferentes aplicaciones dis-tribuidas que DCOS permite instalar en el cluster y que pueden haber sidodesarrollados por la misma empresa Mesosphere o por terceros por ejemploApache Spark Jenkins o Apache Hadoop En la figura 8 se muestra un diagramade los servicios disponibles incluyendo algunos de las aplicaciones distribuidasque soporta DCOS
Figura 8 Servicios DCOSFuente httpsdcosio
511 Apache Mesos
El nuacutecleo de DCOS estaacute basado en Apache Mesos un proyecto de coacutedigoabierto creado por la Universidad de California Berkeley y desarrollado actual-mente por la fundacioacuten Apache Se trata de un administrador de clusters queabstrae los recursos y los dispone para diferentes aplicaciones y entornos de tra-bajo distribuidos (frameworks) mediante una interfaz comuacuten En el momento deredaccioacuten de este proyecto Apache Mesos soportaba una variedad de entornosque abarcaba desde Big Data (Apache Spark Hadoop) hasta bases de datos(Cassandra Hypertable)
15
Arquitectura
Mesos se basa en la asignacioacuten de dos roles diferentes a los nodos
Maestros (Masters) Se encargan de la gestioacuten y reparticioacuten de los recursospara los diferentes entornos de trabajo mediante ldquoofertas de recursosrdquo deacuerdo a los disponibles y a la poliacutetica de asignacioacuten (planificacioacuten en dosniveles)
Esclavos (Slaves) Ordenadores donde se ejecutaraacuten las aplicaciones y cu-yos recursos son ofertados por los maestros
En el caso de fallo del maestro las tareas pueden seguir ejecutaacutendose perono se podraacute asignar nuevos recursos ni tareas por ello pueden existir varios enel cluster para configuraciones de alta disponibilidad pero soacutelo uno orquesta alos esclavos
Para la eleccioacuten del master liacuteder Mesos usa Apache ZooKeeper un proyectode software desarrollado por la misma fundacioacuten cuyo objetivo es proveer deun servicio de configuracioacuten centralizado y registro de nombres8
Por otra parte los entornos de trabajo son los programas que deciden final-mente queacute recursos se van a usar y se encargan de que los esclavos ejecuten lastareas Eacutestos se ejecutan sobre Mesos y constan de dos componentes
Planificador (Scheduler) Optimiza y decide los recursos a utilizar de losofertados informando a los Masters
Procesador (Executor) Ejecuta las aplicaciones o servicios en los esclavos
El objetivo final es conseguir una interfaz liviana tolerante a fallos paracualquier tipo de entorno de trabajo de tal manera que en los esclavos del clusterpuedan ejecutarse simultaacuteneamente tareas con necesidades y duracioacuten diferentesPara ello se basa en dos conceptos asignacioacuten y aislamiento de recursos
Asignacioacuten de recursos
En el cluster pueden coexistir entornos de trabajo con tareas de larga dura-cioacuten y con gran consumo de recursos con tareas cortas que los ocupan y liberancon rapidez El maestro integra un moacutedulo de asignacioacuten de recursos (allocationmodule) que se encarga del algoritmo de distribucioacuten
En el momento de escribir este proyecto estaban desarrollados dos moacutedulosuno mediante el cual el usuario puede asignar prioridades y otro que implementa
8httpszookeeperapacheorg
16
el algoritmo Dominant Resource Fairness9 a grandes rasgos se determina entodos los esclavos la tarea en ejecucioacuten que necesita maacutes recursos y se calcula laproporcioacuten del recurso de mayor peso con respecto al total por ejemplo si unatarea ocupa 2 GB de memoria con respecto a 10 GB totales que tiene el clusterse le asigna un dominant share del 20 la tarea se asignaraacute al nodo con menordominant share
Aislamiento de recursos
Para conseguir que tareas de diferentes entornos de trabajo y con distin-ta naturaleza se ejecuten simultaacuteneamente en un mismo nodo Mesos usa loscontenedores Linux (descritos en la seccioacuten 3)
Funcionamiento
La figura 9 muestra el esquema de la arquitectura de Apache Mesos conalta disponibilidad (tres maestros) y con dos entornos de trabajo ejecutaacutendo-se Hadoop que permite el almacenamiento y procesamiento de gran cantidadde datos para proyectos de big data y un sistema que implementa la interfazsistema de paso de mensajes MPI
Como se puede observar el sistema ZooKeeper elige a un solo maestro comoliacuteder y eacuteste orquesta el cluster comunicando los esclavos con los planificadoresde los diferentes entornos de trabajo Tambieacuten se puede observar como las tareasde los distintos entornos estaacuten distribuidas entre los tres esclavos disponibles
Figura 9 Arquitectura de Apache MesosFuente httpsmesosapacheorg
El proceso de asignacioacuten se realiza como sigue en primer lugar un usuariosolicita la ejecucioacuten de una tarea mediante la interfaz de cada entorno de traba-jo (interfaz graacutefica API HTTP ) De forma paralela un esclavo informa almaestro de los recursos que tiene libres En consecuencia eacuteste se lo notifica almoacutedulo de asignacioacuten que en funcioacuten de su configuracioacuten decide cuaacutento ofertar
9httpspeopleeecsberkeleyedu~aligpapersdrfpdf
17
y a queacute entorno de trabajo y enviacutea la oferta a los planificadores Eacutestos respondenal maestro con queacute recursos ha decidido usar para cada tarea Finalmente lastareas son enviadas al esclavo seleccionado el cual asigna los recursos indicadosal procesador (executor) quien finalmente las ejecuta
Cabriacutea pensar que esta metodologiacutea puede conducir a situaciones en lasque un entorno podriacutea quedarse con tareas sin ejecutarse a la espera de unaoferta satisfactoria para ello Mesos implementa un sistema de filtros medianteel cual los entornos especifican los requisitos miacutenimos que debe cumplir unaoferta por ejemplo se puede especificar en queacute nodos debe desplegarse la tareaEste sistema estaacute disentildeado asiacute con el objetivo de mantener lo maacutes transparenteposible esta herramientas de forma que acepte entornos de trabajo de distintasnaturalezas
512 Ejemplos de uso
Grandes empresas estaacuten usando Apache Mesos con eficacia de acuerdo a susnecesidades e infraestructuras Caben destacar
Ebay En el modelo de implementacioacuten continua en esta empresa10 cadadesarrollador cuenta con su propia instancia que se ejecuta en una maacutequinavirtual dedicada lo que ha conllevado un uso de los recursos poco eficiente Enuna prueba de concepto consiguieron realizar una herramienta de integracioacutencontinua distribuida basada en un cluster con Apache mesos y con el entornoMarathon y Jenkins
Apple Anuncioacute que el motor de su famosa herramienta de asistencia per-sonal para iPhones Siri estaacute desplegada sobre Apache Mesos11 Para ello handesarrollado su propio entorno para facilitar a los ingenieros a desplegar los ser-vicios que la herramienta necesita para resolver las peticiones de los usuarios
Twitter Desarrolloacute su propio entorno denominado Aurora y actualmentegestionan sus recursos y miden el coste de las tareas que los empleados usancon el objetivo de que sean conscientes del gasto que puede suponer un usoinadecuado de la infraestructura12
10httpwwwebaytechblogcom20140404delivering-ebays-ci-solution-with-apache-mesos-part-i11httpwwwbusinessinsidercomapple-siri-uses-apache-mesos-2015-812httpswwwlinuxcomNEWS4-UNIQUE-WAYS-UBER-TWITTER-PAYPAL-AND-HUBSPOT-USE-APACHE-MESOS
18
52 Nomad
Herramienta de coacutedigo abierto de gestioacuten de clusters creada y desarrolladapor Hashicorp13 que permite el despliegue de aplicaciones y procesos de formadistribuida
Las principales diferencias con Apache Mesos a grandes rasgos son
Arquitectura maacutes ligera Nomad soacutelo requiere de un fichero para funcionarejecutaacutendolo con las correspondientes configuraciones en todos los nodosrealiza las funciones de gestioacuten del cluster eleccioacuten de liacuteder planificacioacutende recursos y ejecucioacuten de las tareas
Centro de datos y regiones muacuteltiples Su arquitectura estaacute orientada afacilitar la gestioacuten de diferentes centros de datos geograacuteficamente distri-buidos
Entorno de ejecucioacuten Las tareas se definen y son interpretadas mediantecontroladores integrados en Nomad que se valen de los recursos y herra-mientas de los nodos clientes para ejecutarlas Esta integracioacuten dificultael desarrollo de controladores por parte de terceros a diferencia de Mesosque delega dicha responsabilidad en los entornos de trabajo externos alproyecto
Usa un planificador de estado compartido con respecto a la planificacioacutenen dos niveles de Mesos
Antes de entrar en maacutes detalle en la arquitectura es importante definir lossiguientes teacuterminos
Controlador (Driver) Software que se encarga de interpretar las definicionesde las tareas y ejecutarlas semejante a los procesadores de los entornosde trabajo de Mesos A la hora de redactar este proyecto Nomad contabacon controladores para contenedores Docker virtualizacioacuten de maacutequinasmediante el emulador QEMU aplicaciones java y archivos binarios
Grupo de trabajo (Task Group) Conjunto de tareas que se ejecutan en elmismo nodo cliente
Trabajo (Job) Conjunto loacutegico de tareas y grupos de trabajo que se despliegana la vez
Asignacioacuten (Allocation) Relacioacuten entre un grupo de trabajo y el cliente don-de se ejecuta
Evaluacioacuten (Evaluation) Proceso mediante el cual Nomad planifica y ges-tiona el registro o actualizaciones de los trabajos
13httpswwwhashicorpcom
19
Nomad sigue una arquitectura maestro-esclavo similar a la de Apache Mesosmuacuteltiples servidores acuerdan entre siacute un liacuteder que gestiona la planificacioacuten detareas en los clientes que soacutelo conocen sus asignaciones y las ejecutan
Todos los servidores participan paralelamente en tareas de planificacioacuten derecursos y asignacioacuten de tareas y ademaacutes entre ellos eligen un liacuteder que seencarga de la coordinacioacuten de la suscripcioacuten de los clientes al cluster y de lagestioacuten de las peticiones
Los clientes estaacuten configurados para comunicarse con el servidor usando lla-madas a procedimiento remoto (RPC por sus siglas en ingleacutes) que permite unordenador ejecutar coacutedigo en otra maacutequina Mediante esta tecnologiacutea los nodosclientes avisan de su estado e informa de sus asignaciones recursos y controla-dores disponibles
Existe la posibilidad de gestionar varios centros de datos agrupados en regio-nes eacutestas son independientes pero permite definir tareas o comprobar el estadode todas ellas desde cualquier punto A continuacioacuten se muestra una figura dela arquitectura a alto nivel de esta configuracioacuten
Figura 10 Arquitectura multi-regioacuten en NomadFuente httpswwwnomadprojectio
La herramienta se sustenta sobre tres protocolos fundamentales un protocolode consenso entre los servidores para compartir informacioacuten sobre su estado yel liacuteder un protocolo Gossip para la gestioacuten entre regiones y el planificador detareas
521 Protocolo de consenso Raft
El objetivo es obtener consistencia en un conjunto de nodos que comparteninformacioacuten es decir si un cliente realiza un cambio que todos los nodos veanla misma informacioacuten a la vez y ademaacutes sea tolerante a fallos Para ello se basaen el algoritmo Raft[13] que se detalla brevemente a continuacioacuten
20
Los nodos participantes en el algoritmo pueden estar en tres estados
Liacuteder (Leader) Todos los cambios que realicen en el cluster pasan por eacutel pri-mero
Seguidor (Follower) Nodo pasivo cuya responsabilidad es responder a laspeticiones del nodo liacuteder
Candidato (Candidate) Maacutequina que no ha encontrado liacuteder y solicita sueleccioacuten
Supongamos que tenemos cinco equipos que acaban de arrancar el protocoloEn la figura 11 se observan los nodos y sus respectivos registros a la derecha
Figura 11 Equipos sin consenso ejecutando el protocolo RAFTFuente httpsgithubcomongardieraftscope
Al comenzar todos los nodos son seguidores esperando recibir comunicacioacutende un nodo que actuacutee como liacuteder Cada nodo tiene un tiempo de espera aleatoriodespueacutes del cual si no es informado por un liacuteder pasa a estado candidato y pideel ldquovotordquo al resto de los participantes El algoritmo divide el tiempo en plazos uncandidato pasa a liacuteder si recibe la mayoriacutea de los votos en un plazo determinadoSe define mayoriacutea o cuoacuterum (quorum) comolceil
N2rceil
+ 1 (1)
donde N representa el nuacutemero de nodos
Para el ejemplo propuesto de 5 equipos se requieren de 3 votos Soacutelo losnodos que se encuentren en estado seguidor pueden votar una uacutenica vez a laprimera solicitud que reciba dentro de un plazo
Supoacutengase que el nodo denotado con S1 ha cumplido su tiempo de espera yrealiza la peticioacuten de voto (figura 12) A partir de este momento se pueden dartres casos
La maacutequina gana la eleccioacuten y pasa a ser liacuteder informando al resto
Otro servidor se establece como liacuteder en el mismo momento
Varios nodos pasan a ser candidatos por lo que ninguno consigue los votos
21
Figura 12 Un equipo pasa a estado candidato (RAFT)
Si un candidato recibe un aviso de un liacuteder en el mismo plazo el primeropasa a ser seguidor y se acaba la eleccioacuten de liacuteder
Por otro lado si un equipo candidato no recibe los votos en el plazo y agotasu tiempo de espera avanza al siguiente plazo y repite el proceso de votacioacutenLa tercera posibilidad puede conllevar a un estado indefinido ya que varioscandidatos pueden agotar su tiempo de espera al mismo tiempo y repartir losvotos Para solventarlo el algoritmo establece tiempos de espera aleatorios paralos candidatos
Siguiendo con el ejemplo propuesto el servidor S1 pasa a ser el liacuteder Cadacierto tiempo eacuteste debe realizar avisos a los nodos seguidores para no agotar sutiempo de espera
En este momento el cluster de servidores estaacute en ldquoconsensordquo y la informacioacutenen todos los nodos estaacute actualizada Un cambio en la informacioacuten inicia unproceso de replicacioacuten el liacuteder registra el cambio lo pasa al resto de nodos yuna vez eacutestos responden el cambio se hace efectivo
Supoacutengase que se realiza un cambio en los datos en la figura 13 en la partederecha se observa el cambio en el registro del servidor S1 que informa a losnodos seguidores En consecuencia los nodos registran el cambio y responden aS1
Figura 13 Cambio en un registro (RAFT)
Una vez el cuoacuterum (en el ejemplo tres equipos) informa al liacuteder de que
22
ha registrado el cambio el liacuteder lo hace efectivo en su sistema y notifica a losnodos que hacen lo mismo En la figura 14 el enviacuteo todaviacutea no ha llegado ala maacutequina S3 y se observa que no ha hecho efectivo el cambio (en el registroaparece punteado)
Figura 14 Aprobacioacuten del resto de equipos (RAFT)
Este protocolo funcionaraacute correctamente mientras exista un nuacutemero de nodosen funcionamiento igual o superior al cuoacuterum en el ejemplo propuesto elcuoacuterum es tres por lo que el sistema puede tolerar la caiacuteda de dos de los equipos
522 Protocolo gossip SWIM
Nomad permite la gestioacuten simultaacutenea de varios centros de datos reparti-dos en regiones geograacuteficamente separadas requiriendo de un protocolo ligeroque mantenga a los miembros actualizados sobre los participantes del conjun-to Para ello usa una ligera variante del protocolo SWIM[3] (Scalable Weakly-consistent Infection-style Process Group Membership Protocol) desarrollada porHashiCorp Estaacute clasificado como un protocolo de tipo gossip que debe su nom-bre a la semejanza con coacutemo se distribuye un rumor en una red social
SWIM se sustenta en dos caracteriacutesticas fundamentales la deteccioacuten de fallosy la distribucioacuten de la informacioacuten relativa a los miembros A continuacioacuten sedetalla el funcionamiento de ambos componentes
Deteccioacuten de fallos
Este componente tiene dos paraacutemetros el periodo de protocolo T y el nuacutemerode subgrupos de deteccioacuten de fallos k en los que se dividen los nodos Paracomprobar la comunicacioacuten entre dos maacutequinas usa la utilidad ping basadaen el protocolo ICMP La deteccioacuten de caiacuteda de un servidor sigue el siguientealgoritmo
Durante el periodo T cada miembro Mi de un subgrupo elige otro al azar Mjdel mismo subgrupo y le enviacutea un mensaje ping para comprobar su estado Enel caso de que se cumpla un tiempo de espera determinado por una estimacioacuten
23
del tiempo de ida y vuelta (RTT por sus siglas en ingleacutes) de la red y no hayarespuesta Mi le vuelve a enviar un mensaje ping indirectamente a traveacutes deun nuacutemero k de miembros escogidos aleatoriamente De no recibir ninguna res-puesta Mi establece que Mj ha sufrido un fallo y lo etiqueta como ldquosospechosordquoinformando al componente de distribucioacuten
Figura 15 Diagrama de tiempo del protocolo SWIMFuente httpswwwcscornelledu
Componente de distribucioacuten
Se encarga de informar de cualquier cambio en los miembros a todo el con-junto Los eventos de nodo caiacutedo y la unioacuten o disociacioacuten de un miembro setransmiten a todos los servidores para que actualicen sus lista Para distribuirla informacioacuten a todos los nodos se podriacutea usar el meacutetodo de multicast perosuele estar deshabilitado Por ello se utiliza una teacutecnica de transmisioacuten denomi-nada Piggybacking mediante la cual se adjunta a los propios mensajes PINGy ACK del algoritmo la informacioacuten a distribuir reduciendo asiacute la congestioacutenen la red
523 Planificacioacuten
Proceso encargado de distribuir las tareas entre los nodos clientes de acuerdoa su estado
El planificador de Nomad estaacute basado en las publicaciones de Google sobresus herramientas de gestioacuten de clusters Borg y Omega14 y entiende los trabajosdescritos por el usuario como un estado deseado es decir su despliegue en unamaacutequina cliente de forma correcta y los clientes como el estado actual esto eslo que se encuentra en ejecucioacuten El registro actualizacioacuten o cancelacioacuten de un
14httpresearchgooglecompubspub43438html
24
trabajo asiacute como el fallo de un nodo cliente implican un cambio de estado atramitar por el sistema lo que se define como evaluacioacuten (evaluation) Esto uacutelti-mo supone comparar el estado actual (clientes) con el estado deseado (conjuntode trabajos registrados) y enviarlos a los planificadores correspondientes que seencargaraacuten de asignar las tareas a los nodos clientes
Figura 16 Procedimiento de asignacioacuten en NomadFuente httpswwwnomadprojectio
En la figura 16 se observa el flujo de trabajo en el que las distintas evalua-ciones se encolan en el evaluation broker que se ejecuta en el servidor liacuteder ygestiona las evaluaciones pendientes asignaacutendoles prioridades
A continuacioacuten los nodos servidores ejecutan los scheduling workers queprocesan las evaluaciones llamando a los distintos planificadores que generanun plan de asignacioacuten esto es un conjunto de relaciones entre las tareas y losnodos clientes donde se ejecutaraacuten Este proceso se divide en dos fases primerose descartan aquellos clientes que no cumplan los requisitos y posteriormentese asigna una calificacioacuten al resto Se selecciona el nodo con mayor puntuacioacuteny se encola el plan en el gestor que se ejecuta en el servidor liacuteder Existen tresplanificadores de acuerdo al tipo de trabajo
Service Incluye aquellos trabajos que estaacuten destinados a ejecutarse en un pe-riacuteodo largo de tiempo Para realizar las asignaciones el planificador evaluacuteala mayor parte de los nodos y usa una versioacuten del algoritmo Best fit in-fluenciada por el trabajo de Google en su herramienta Borg Se trata deun algoritmo de planificacioacuten que sacrifica tiempo a cambio de maximizarel rendimiento de los clientes asignando la tarea a la maacutequina que tengala mayor carga de trabajo con el objetivo de reducir equipos en funciona-
25
miento
Batch Tareas que incluyen listas de comandos en general de menor duracioacuteny que no requieren interaccioacuten con el usuario Se vale del algoritmo deSparrow desarrollado por la universidad de Berkeley15 para limitar losnodos clientes a evaluar
System Trabajos destinados a ejecutarse en todos los nodos incluso los que seunen al cluster posteriormente
Core Mantenimiento interno de Nomad
Una vez se ha realizado el proceso de planificacioacuten el nodo liacuteder lo registra enla cola de planes (plan queue) que se encarga de asignarles prioridad y manejarcondiciones de carrera es decir que no accedan a los recursos de los clientes sincontrol y evitar que eacutestos superen su capacidad
La maacutequina liacuteder del conjunto puede de este modo aceptar una asignacioacuteny ser ejecutada por los clientes o por el contrario rechazaacutersela al planificadorlo que implicariacutea realizar un plan parcial o totalmente nuevo
Finalmente el estado de las evaluaciones se actualizan y los clientes soninformados de las asignaciones ejecutaacutendose las tareas
15httppeopleeecsberkeleyedu~keopublicationssosp13-final17pdf
26
6 Casos de uso y despliegue
Con el objetivo de mostrar las posibles utilidades que este tipo de sistemaspueden tener en las infraestructuras TI actuales se han desplegado las dos he-rramientas en la nube Microsoft Azure usando su servicio cloud de instancias demaacutequinas virtuales Linux para simular un conjunto de ordenadores conectadosentre siacute por una red LAN Sobre ellas se ha implementado dos casos de usouna aplicacioacuten web con una arquitectura con cierta orientacioacuten a microserviciosy un sistema de integracioacuten continua
El coacutedigo y todos los ficheros de configuracioacuten se pueden encontrar en elrepositorio del proyecto en GitHub16
61 Aplicacioacuten Web
Se busca simular el proceso de adaptacioacuten de una solucioacuten web para su des-pliegue en un sistema distribuido con las herramientas anteriormente descritascon el objetivo de aumentar tanto su escalabilidad como disponibilidad medianteredundancia
Se ha partido de una aplicacioacuten ya existente17 un servicio de almacenamien-to y reproduccioacuten de canciones A grandes rasgos este servicio permite crearusuarios subir canciones con sus respectivas portadas tener playlists propias yescuchar las canciones a traveacutes de un navegador web
La solucioacuten estaacute dividida en 4 partes (figura 17)
Una vista web con la loacutegica
Un almacenamiento conectado en red (NAS por sus siglas en ingleacutes)
Una API REST para gestionar las peticiones al almacenamiento
Base de datos NoSQL basada en MongoDB
La nueva tendencia de los proyectos web es su implementacioacuten en contene-dores Docker ya que facilitan su portabilidad y ofrecen un procedimiento dedespliegue raacutepido sobre todo a la hora de desarrollar y realizar pruebas en en-tornos de produccioacuten simulados Por ello en este caso se va a hacer uso de los
16httpsgithubcomAntonioAlfrzCloud-Orchestrators17httpsgithubcomsonsoleslpCDPSfy
27
motores de orquestacioacuten de contenedores de ambas herramientas Marathon enDCOS y el controlador Docker en el caso de Nomad
Figura 17 Arquitectura aplicacioacuten web
A continuacioacuten vamos detallar el despliegue en ambas herramientas de es-ta solucioacuten y observar tanto queacute dificultades se encuentran como que ventajasofrecen El objetivo final es adaptar el proyecto modificaacutendolo lo menos posiblecon objeto de analizar la capacidad de estas herramientas para desplegar cual-quier aplicacioacuten sin que eso conlleve la modificacioacuten de la arquitectura de eacutestaes decir que no sea dependiente del entorno
611 DCOS
Se ha descrito DCOS como una herramienta que se despliega sobre un con-junto de ordenadores y que permite instalar gestionar el despliegue de sistemasdistribuidos
Microsoft Azure cuenta con una plantilla para desplegar en su servicio cloudun cluster de maacutequinas virtuales con DCOS ya instalado que cuenta con
Maacutequinas maestras (1 3 o 5 a seleccionar por el usuario) configuradascomo un conjunto de disponibilidad esto eso Azure da ciertas garantiacuteasde que al menos una maacutequina estaraacute en funcionamiento
Maacutequinas agentes Por motivos de seguridad se distinguen dos roles
bull Nodos privados solo accesibles desde la red interna y configuradoscomo un conjunto de escala un recurso de Azure para gestionar ydesplegar maacutequinas con configuraciones ideacutenticas para permitir unraacutepido escalado
bull Un equipo conectado accesible desde Internet a travntildees de un balan-ceador de carga puacuteblico y situado en una subred externa
28
Dos balanceadores de carga
bull La interfaz puacuteblica del cluster que se conecta con el cliente puacuteblicobull Acceso a los equipos maestros para el administrador que soacutelo permiteconexioacuten mediante SSH y credenciales
Almacenamiento para todas las maacutequinas
Configuraciones necesarias de red y seguridad
En la figura 18 se observa un diagrama de la infraestructura
Figura 18 Infraestructura en Azure
El primer obstaacuteculo es la persistencia de estado de la aplicacioacuten que seconsigue gracias a una base de datos no relacional basada en MongoDB asiacutecomo el almacenamiento de las canciones Para implementarla tenemos variasposibilidades
Montar un sistema externo de almacenamiento conectado en red en todoslos agentes donde se ejecuten las tareas de esta manera si una tarea pasade un nodo a otro por cualquier motivo puede tener acceso a los mismosficheros (opcioacuten del caso de uso original)
Implementar un sistema de ficheros distribuidos en los agentes
Usar los servicios de almacenamiento de las nubes puacuteblicas
Aprovechar el sistema de voluacutemenes persistentes de Apache Mesos Eacutestepermite reservar recursos de un agente de forma que al arrancar una tarease crea un volumen independiente del ciclo de vida de eacutesta con ello esosrecursos donde se ha almacenado la informacioacuten pueden volver a ofrecerseal mismo entorno de tal manera que otra tarea pueda acceder a ella
DCOS aprovecha este sistema de voluacutemenes persistentes y permite instalarbases de datos distribuidas como ArangoDB o Apache Cassandra sin embargoesto implicariacutea modificar todo el coacutedigo referente al modelo de la base de datos
29
Por motivos de eficiencia y latencia asiacute como de una mayor gobernabilidadde los datos la mejor opcioacuten es usar el recurso de voluacutemenes persistentes queofrece Apache Mesos ya que de esta manera se gestionariacutea la aplicacioacuten completamediante una uacutenica herramienta Sin embargo esto implica que la informacioacutense encuentra exclusivamente en el agente donde se haya ejecutado la tarea y porlo tanto se sigue requiriendo de software externo para distribuir la informacioacutenpara que se accesible para todos los agentes A la hora de realizar este proyectose encontraba en desarrollo Flocker una solucioacuten desarrollada por ClusterHQque permite compartir los voluacutemenes de Docker a traveacutes de un cluster quesi bien es compatible con el planificador de Mesos el proyecto se encontrabatodaviacutea en fases tempranas de desarrollo y los sistemas de almacenamiento quesoporta quedaban fuera del aacutembito de este trabajo
Por todo ello dado que las maacutequinas se han desplegado en la nube puacuteblicade Azure se decidioacute usar su servicio de almacenamiento de objetos para lascanciones y otra maacutequina para desplegar MongoDB y asiacute mantener el modelode datos original de la aplicacioacuten La diferencia del almacenamiento de obje-tos con respecto a nivel de fichero es que el primero no tiene jerarquiacutea paraorganizar los archivos eacutestos se guardan como objetos (con sus metadatos) enun mismo espacio soacutelo diferenciaacutendose por un identificador uacutenico esto implicaentre otras cosas que se puede acceder a un fichero dado uacutenicamente su IDindependientemente de la localizacioacuten fiacutesica de eacuteste facilitando pues la gestioacuteny el desarrollo
El coacutedigo del proyecto se ha modificado en los siguientes apartados
Las direcciones de la base de datos y los balanceadores de carga asiacute comosus puertos estaban originalmente fijos Se han configurado como variablesde entorno para facilitar el descubrimiento del servicio y hacer transpa-rente la aplicacioacuten al entorno de despliegue
La API REST se ha adaptado al almacenamiento en Azure en vez de enlocal
Estas modificaciones no suponen un cambio sustancial pero permiten separala persistencia de las tareas ejecutadas por DCOS lo que facilita en granmedida su ejecucioacuten al ser totalmente sin estado y ademaacutes implican tenerlos datos bajo un mayor control
Para la orquestacioacuten de contenedores se va a usar el entorno Marathondesarrollado tambieacuten por Mesosphere Eacuteste se puede usar a traveacutes de una interfazgraacutefica la interfaz de liacutenea de comandos (en lo que sigue CLI por sus siglas eningleacutes) de DCOS o con su API HTTP
Primero se han publicado la imaacutegenes de los contenedores que encapsulanla interfaz web y la api de la aplicacioacuten en el repositorio puacuteblico DockerHub
Los despliegues en este entorno se describen mediante ficheros JSON en losque se detalla entre otras opciones la imagen del contenedor los puertos a usar
30
los recursos que debe ocupar en un nodo o las instrucciones de monitorizacioacuten
Para el servicio de descubrimiento DCOS ofrece la posibilidad de asignardirecciones IP virtuales (VIP por sus siglas en ingleacutes) a tareas que se compartenen todos los nodos DCOS lleva integrado un balanceador de carga a nivel TCP(el componente denominado Minuteman) que balancea entre las direccionesvirtuales de las tareas y todas las instancias de eacutestas a lo largo del cluster Estoes necesario por dos motivos equilibrar la carga de los equipos con el fin deevitar un punto de uacutenico fallo mediante redundancia y evitar la contienda dedirecciones al ejecutar las tareas en puertos aleatorios
Este balanceador de carga estaacute basado en el trabajo de Michael Mitzenma-cher The Power of Two Choices in Randomized Load Balancing18 A grandesrasgos el algoritmo mantiene una media moacutevil exponencial de latencias paracada destino (backend) ademaacutes de las caiacutedas consecutivas Si un destino noresponde a una negociacioacuten en tres pasos (three way handshake) de forma con-secutiva en un periodo inferior a 5 ms se considera caiacutedo El algoritmo iterasobre los destinos disponibles en base a su histoacuterico de fallos y escoge dos deforma aleatoria de los cuales coge el de mejor meacutetrica
Las direcciones virtuales soacutelo se pueden resolver dentro del cluster porello para implementar la interfaz puacuteblica de la aplicacioacuten esto es el balancea-dor de carga de la interfaz web usaremos un paquete de DCOS denominadomarathon-lb un balanceador basado en HAProxy y adaptado por MesosphereEn este caso equilibra la carga de todas instancias de las tareas ejecutadas porel entorno Marathon por sus etiquetas y permite ademaacutes definir como puntode entrada muacuteltiples hosts virtuales definidos por sus nombres completos dedominio (FQDN por sus siglas en ingleacutes) en nuestro caso la interfaz puacuteblicadel balanceador de Azure para los agentes
Por motivos de seguridad todas las tareas se ejecutan en los agentes privadoses decir los que son exclusivamente accesibles desde la red interna Por su partemarathon-lb se ejecuta en el agente puacuteblico que cuenta con IP puacuteblica y lospuertos 80 (HTTP) y 8080 abiertos de forma que la aplicacioacuten sea accesibledesde Internet Esto es posible debido a que Apache Mesos permite reservarrecursos mediante roles asignados a nodos para un uso especiacutefico De esta formala arquitectura vista desde la aplicacioacuten quedariacutea como en la figura 19
18httpswwweecsharvardedu~michaelmpostscriptstpds2001pdf
31
Figura 19 Arquitectura de la aplicacioacuten web en DCOS
Ejecucioacuten
A la hora de desplegar la aplicacioacuten DCOS puede gestionarse medianteuna interfaz graacutefica o una interfaz de liacutenea de comandos La primera se accedea traveacutes de un navegador web en el puerto 80 (HTTP) y permite instalar losentornos disponibles observar el estado de los nodos y las tareas que se estaacutenejecutando y los ficheros de registros que eacutestas generan
La CLI permite el control desde un nodo o una maacutequina remota (suponiendoque los maestros tienen IP puacuteblica y el puerto 80 abierto) ya que DCOS tieneun sistema de autorizacioacuten que permite tener una interfaz puacuteblica con ciertasgarantiacuteas de seguridad
Por su parte cada entorno de trabajo puede ser controlado por la CLI peroademaacutes cuenta con sus propias interfaces Marathon expone una API HTTPen el puerto 8080 de la direccioacuten puacuteblica de los maestros del cluster asiacute comootra interfaz graacutefica Para desplegar un contenedor se podriacutea usar la CLI
$ dcos marathon app add lt f i l e j songt
O la API HTTP
$ cu r l minusX POST http lt ip_maestro gt8080v2apps minusd ltf i l e jsongt minusH Contentminustype app l i c a t i o n j son
32
612 Nomad
La arquitectura de Nomad es maacutes sencilla ya que solo requiere de un ficheroejecutable en todos los nodos para funcionar Si DCOS es la base de instala-cioacuten de entornos de terceros Nomad integra todas las funcionalidades baacutesicasesto es gestor de recursos planificador y ejecutor en los nodos cliente Estaherramienta cuenta con un menor tiempo de desarrollo y en el momento deescribir este documento cuenta exclusivamente con los siguientes controladoresen comparacioacuten con los entornos de DCOS
Motor Docker es decir funcioacuten de orquestacioacuten de contenedores
Ejecucioacuten de archivos binarios como comandos de Shell
Ejecucioacuten de aplicaciones Java
Virtualizacioacuten de maacutequinas mediante tecnologiacutea QEMU
Todos ellos necesitan que la tecnologiacutea subyacente esteacute instalada en las maacute-quinas clientes (Docker Java QEMU) Actualmente no permite el registro decontroladores por parte de terceros aunque estaacute planificado en un futuro ofreceruna interfaz para su desarrollo
Nomad no cuenta con el servicio de descubrimiento sin embargo puede inte-grarse con la herramienta Consul desarrollada por la misma empresa Por otrolado para el balanceo de carga usaremos un contenedor Docker con HAProxyuna herramienta de coacutedigo abierto que ofrece tanto servicios de proxy como debalanceador y cuyos ficheros de configuracioacuten completaremos con el proyectoConsul Template19
Consul
Consul sigue la misma arquitectura que Nomad es decir un nodo servidorque orquesta un conjunto de maacutequinas clientes y permite a los procesos que seejecutan en los equipos definirlos como servicios ofreciendo diversas caracteriacutes-ticas entorno a estos de los cuales vamos a usar dos
Descubrimiento de servicio Las maacutequinas clientes publican en el cataacutelogode servicios las tareas en ejecucioacuten y Consul les asigna nombres de dominioaccesibles por todos los miembros del cluster a traveacutes de la interfaz DNSincluida en esta herramientaConsul se integra con Nomad de forma que todas las tareas que se ejecu-ten en la segunda son automaacuteticamente publicados como servicios de laprimera de esta manera no hace falta conocer la direccioacuten de la maacutequinacliente donde se esteacute ejecutando el proceso ya que se puede acceder a eacutela traveacutes de su nombre de dominio de forma transparente Por ejemplo si
19[httpsgithubcomhashicorpconsul-template]
33
ejecutamos una tarea con ID web en el puerto 8080 se puede acceder aella en la direccioacuten webserviceconsul8080Para que las direcciones propias de Consul las resuelva su propio DNS y noel que esteacute asignado por defecto en la maacutequina usaremos la herramientadnsmasq20 que permite especificar la direccioacuten de un servidor DNS paraconsultas de direcciones especiacuteficas
Monitorizacioacuten Permite realizar comprobaciones del servicio y seguir su esta-do Aprovecharemos esta funcionalidad tanto para definir el propio procesode Nomad como servicio de Consul como las tareas desplegadas
HAProxy + Consul Template
HAProxy es una solucioacuten versaacutetil de coacutedigo abierto que ofrece solucionesde balanceo de carga y proxy Existen otras herramientas en el mercado comoNGINX o ldirectord sin embargo HAProxy suponiacutea una solucioacuten sencilla deconfigurar para mostrar el caso de uso
El uso de estas herramientas se debe a dos motivos para que no existacontienda con respecto a los puertos de los clientes usados por las tareas eacutestos sevan a asignar de forma dinaacutemica lo que en principio implicariacutea que la aplicacioacutendeberiacutea realizar consultas DNS de tipo SRV (que incluye puertos) a la interfazde Consul y balancear la carga entre tareas por redundancia y capacidad
Como la direccioacuten IP y puerto son variables cada vez que las tareas seactualicen o se reasignen es necesario volver a configurar HAProxy de formamanual Por ello HashiCorp ha desarrollado un programa denominado Con-sul Template que realiza peticiones sucesivas a la interfaz HTTP de Consul delas direcciones fiacutesicas de un servicio y reinicia automaacuteticamente el proceso deHAProxy Asiacute definiendo estas tareas como servicios Consul podremos tantomonitorizarlas como escalar las tareas dinaacutemicamente sin necesidad de cambiarel balanceador A partir del contenedor Docker oficial de HAProxy se ha desa-rrollado otro con la configuracioacuten baacutesica y con Consul Template para desplegarlocomo una tarea en Nomad
Despliegue
Se ha usado el mismo coacutedigo que en el apartado anterior con la persistenciaen el servicio de almacenamiento de Azure Desde la perspectiva del hardwarese implementaraacute la misma infraestructura que en el caso de DCOS (figura 18)estos es definiremos dos tipos de maacutequinas clientes un agente que se conectaraacutecon el balanceador de carga con nombre de dominio puacuteblico y donde se desple-garaacute el balanceador de carga de la vista web y agentes privados no accesiblesdesde fuera del cluster y donde se ejecutaraacuten el resto de tareas en la red inter-na La principal diferencia radica en las tareas que ejecutan HAproxy y ConsulTemplate que sustituye a las direcciones IP virtuales que ofrece DCOS
20httpwwwthekelleysorgukdnsmasqdochtml
34
Figura 20 Despliegue en Azure de Nomad+Consul
Cabe matizar que los balanceadores basados en HAProxy se implementanpor necesidad de la aplicacioacuten para el descubrimiento del servicio a diferenciade los de Azure que se implementan por motivos de seguridad y escalabilidaddel cluster en siacute
Configuracioacuten Nomad
Los ficheros de configuracioacuten de las maacutequinas maacutester y cliente son similaresy comparten la mayoriacutea de las opciones como por ejemplo el nombre del nodoo la interfaz de red donde escucha Nomad las peticiones Sus opciones son engeneral auto-explicativas sin embargo existen dos detalles que matizar
El proceso de Nomad escucha las peticiones tanto de los protocolos deconsenso como del usuario a traveacutes de una interfaz de red que se debeindicar en el fichero de configuracioacuten
En el caso de los clientes se deben indicar las direcciones de los servidoresdel cluster sin embargo se trata de un sistema dinaacutemico en el que losnodos pueden sufrir errores y cambiar de direccioacuten Por ello se ha definidoNomad como un servicio de Consul y asiacute poder definir la direccioacuten de losservidores como un nombre de dominio no por su direccioacuten fiacutesica que elservidor DNS de Consul se encargaraacute de resolver
Por defecto Nomad usa los siguientes puertos
API HTTP 4646 Peticiones HTTP y recepcioacuten de oacuterdenes mediante laliacutenea de comandos
RPC 4647 Protocolo de consenso entre los nodos del cluster
Serf 4648 Protocolo de gossip entre los servidores de los centros de datosgobernados por Nomad
35
Los dos uacuteltimos deben ser interfaces alcanzables por otros nodos sin embargo laAPI HTTP por motivos de seguridad deberiacutea ser local ya que en caso contrariocualquier persona con acceso a ella tiene el control sobre la herramienta Eacutestasolo deberiacutea estar accesible en un servidor o gestionarlo mediante una terminalSSH por ejemplo En este trabajo al ser una prueba de concepto se ha abiertoen todos los nodos
Trabajos de Nomad
Las tareas se detallan en ficheros con formato HashiCorp Configuration Lan-guage un derivado del formato JSON creado por la empresa que le da nombrecompatible con eacuteste y que permite comentarios
En estos ficheros se puede definir
La regioacuten y el centro de datos donde se ejecutaraacute (Nomad permite lagestioacuten de centros de datos geograacuteficamente distribuidos en regiones)
La poliacutetica de actualizacioacuten de la tarea
Grupo de tareas esto es que se ejecutaraacuten en el mismo nodo
El nuacutemero de grupos a ejecutarescalar asiacute como los liacutemite que debencumplir los nodos asignados
La poliacutetica de reinicio ante fallo o error
Tareas El controlador su configuracioacuten los paraacutemetros del servicio aso-ciado a registrar en Consul asiacute como los recursos que consume (puertosmemoria)
En nuestro caso usamos sobre todo el controlador Docker esto eso orques-tacioacuten de contenedores en los nodos clientes y tres de sus opciones
Imagen del contenedor Se han subido todas las imaacutegenes del proyecto a Doc-ker Hub donde por defecto se busca la imagen
Puertos Los puertos a usar por el contenedor que pueden ser estaacuteticos asigna-dos por el usuario o dinaacutemicos siendo Nomad el que se encarga de mapearun puerto libre del nodo cliente al expuesto por el contenedor
Servidores DNS Como usamos la interfaz DNS de Consul como descubri-miento de servicio se debe configurar el contenedor para que use cualquiernodo del cluster como servidor DNS
Configuracioacuten Consul
Al ser desarrolladas por la misma empresa los ficheros de configuracioacuten deConsul y Nomad comparten muchas opciones Consul tambieacuten acepta peticionesa traveacutes de una interfaz de red siendo los puertos usados por defecto
36
RPC 8300 8400 Maneja la peticiones del resto de nodos y usuarios
Serf 8301 8302 Protocolo gossip
HTTP API 8500
HTTPS API Desactivada por defecto
Interfaz DNS 8600
Se debe asignar a los protocolos internos del cluster esto es RPC y Serf unainterfaz alcanzable por los nodos y por el contrarioasignar a los dos uacuteltimos ala interfaz de loopback por motivos de seguridad
Cabe destacar que Consul tambieacuten cuenta con una interfaz graacutefica que per-mite ver el estado de los equipos y los servicios registrados y que se encuentra enel mismo puerto que la API HTTP en la direccioacuten httpIP_EQUIPO8500ui
Ejecucioacuten
Tanto Nomad como Consul requieren de la ejecucioacuten de un fichero en todoslos nodos integrantes del cluster Como prueba de concepto se ha decidido usardos servidores para ambos aunque cabe matizar que es un nuacutemero ineficienteya que la caiacuteda de uno de ellos supondriacutea la peacuterdida del cuoacuterum y por tantodel consenso del cluster
En primer lugar se arrancan los servidores que son los encargados de ejecu-tar el protocolo de consenso y gestionar el cluster y a continuacioacuten los clientesque no tienen praacutecticamente estado y dependen de los servidores
En el caso de Consul se debe indicar el directorio donde se guardan losficheros que describen los servicios asiacute como el archivo que especifica el resto delas opciones
1 Se inicia el primer servidor en uno de los equipos
$ consu l agent minuscon f i gminusd i r e t c consu l d s e r v i c e s minuscon f i gminus f i l e consu l_server j son
2 Los siguientes equipos deben unirse al anterior por lo que antildeadimos elargumento join con la direccioacuten del primer servidor Para el caso de otrosservidores
$ consu l agent minuscon f i gminusd i r e t c consu l d s e r v i c e s minuscon f i gminus f i l e consu l_server j son minus j o i n ltIP_servidor1gt
37
Una vez los servidores han alcanzado el consenso y elegido un liacuteder en losclientes
$ consu l agent minuscon f i gminusd i r e t c consu l d s e r v i c e s minuscon f i gminus f i l e c on su l_c l i en t j son minus j o i n ltIP_cualquierServ idorgt
El proceso para iniciar Nomad es igual y los comandos similares sin embargoya no es necesario indicar una direccioacuten IP fija en los equipos sino el nombre dedominio del servicio de Nomad registrado por Consul En el primer servidor
$ nomad agent minusc on f i g nomad_server j son
Y el resto de equipos (con su fichero de configuracioacuten correspondiente)$ nomad agent minusc on f i g nomad_server j son minus j o i n nomad s e r v i c e consu l
Por uacuteltimo para desplegar la aplicacioacuten web se han escrito tres ficherosque detallan las tareas de la interfaz web API y los balanceadores de cargaMediante la CLI
$ nomad run minusaddress=http lt ip_c lus te r gt4646 lt f i l e hclgt
O mediante la API HTTP de Nomad$ cu r l minusX POST minusd ltf i l e hclgthttp lt ip_c lus te r gt4646 jobltjob_namegt
Ansible
Como se puede comprobar con el aumento del nuacutemero de equipos pasa aser inviable manejar todos los nodos a traveacutes de terminal Ademaacutes como seha comentado con anterioridad Nomad requiere que en los nodos clientes es-teacuten instalados las herramientas que soporten las tareas por ejemplo el motorde Docker Por ello para facilitar tanto el arranque como la instalacioacuten de lasdependencias vamos a usar Ansible una herramienta de coacutedigo abierto desarro-llada en Python que permite gestionar configuraciones aprovisionar recursosdespliegue de aplicaciones de forma automaacutetica
A grandes rasgos esta herramienta funciona mediante ficheros en formatoYAML denominados play-books que describen un conjunto de pasos a ejecutaren una lista de equipos remotos Estos pasos son ejecutados por moacutedulos inde-pendientes a traveacutes de SSH es decir en cualquier ordenador con conexioacuten a los
38
hosts dado su contrasentildea o clave puacuteblica puede arrancar el script y realizariacutealos pasos de forma remota gestionando el cluster desde un solo equipo
Se han desarrollado guiones para lo siguiente
Descarga de los binarios de Nomad y Consul en todos los nodos copiade los ficheros de configuracioacuten baacutesicos y modificarlos de acuerdo a cadanodo (nombre del equipo direccioacuten IP)
Instalacioacuten de las dependencias
Arranque de Nomad y Consul
Ansible extiende su funcionalidad a traveacutes de moacutedulos independientes que per-miten por ejemplo instalar paquetes mediante herramientas de gestioacuten de pa-quetes (APT yum) aprovisionar automaacuteticamente maacutequinas virtuales de Ama-zon EC2
Algunas opciones de los ficheros de configuracioacuten de Nomad y Consul sondependientes del nodo particular por ejemplo la interfaz de red Para estetrabajo se ha realizado un moacutedulo para modificar los ficheros de configuracioacutende forma automaacutetica En el repositorio del proyecto se encuentra una carpetadonde se encuentran todos los ficheros necesarios para desplegar un clustertotalmente funcional solo requiere de una liacutenea de terminal con Ansible
$ ans ib l eminusplaybook minus i hos t s minusk ltssh_passgt minusu ltnode_usergt s i t e yml
39
62 Servicio de integracioacuten continua
Se ha implementado un sistema de integracioacuten continua que permite ejecu-tar tareas de compilacioacuten y pruebas de forma distribuida aumentando asiacute elrendimiento de los equipos En primer lugar se detallaraacute los motivos por los quepuede resultar beneficioso para las empresas una implementacioacuten de este tipo alo que seguiraacute los detalles del despliegue
621 DevOps
Metodologiacutea que defiende la comunicacioacuten y colaboracioacuten entre desarrolla-dores de software y los profesionales de operaciones a lo largo de todo el ciclo devida de una aplicacioacuten Estaacute muy relacionado con el desarrollo aacutegil de softwareesto es un enfoque para los proyectos que defiende el desarrollo iterativo e in-cremental donde los requisitos y soluciones evolucionan con el tiempo seguacuten lanecesidad del proyecto DevOps extiende esta filosofiacutea a todas los componentesde un servicio incluyendo sistemas y operaciones
Se trata de un concepto que cada organizacioacuten o empresa adapta a suspropias necesidades y procesos de negocio en este proyecto nos vamos a centraren la integracioacuten continua una praacutectica fundamental tanto del desarrollo aacutegilcomo de esta filosofiacutea
622 Integracioacuten Continua
Se define como una praacutectica de desarrollo software donde los miembros delequipo ponen en comuacuten su trabajo frecuentemente al menos una vez al diacutea21Cada integracioacuten se verifica con una compilacioacuten automaacutetica que incluye laejecucioacuten de pruebas para detectar errores de integracioacuten tan pronto como seaposible
Desde el punto de vista operativo esto supone automatizar la configuracioacutende equipos o el despliegue de maacutequinas virtuales donde compilar el proyecto yejecutar las pruebas y posteriormente eliminarlas Este flujo de trabajo se vebeneficiado en entornos distribuidos ya que el objetivo del desarrollador es com-probar el resultado de las pruebas raacutepidamente sin preocuparse del despliegueo los propios equipos
Para esta prueba de concepto vamos a usar Jenkins un servidor de integra-cioacuten continua escrito en Java que nos permite definir trabajos que contendraacutenla descripcioacuten tanto del entorno como su ejecucioacuten
Este sigue una estructura maestro-esclavo muy similar al de los gestores declusters usados en este proyecto el maestro contiene toda la loacutegica del servicio
21httpmartinfowlercomarticlescontinuousIntegrationhtml
40
trabajos autenticacioacuten y los esclavos son los encargados de la ejecucioacuten ensiacute Jenkins tiene varias viacuteas para aprovisionar los uacuteltimos
Mediante SSH
Interfaz graacutefica
Desarrollar un script propio
Ejecucioacuten de un fichero java
La ventaja de usar planificadores es que el despliegue de esclavos es dinaacutemicoes decir no tener una maacutequina especiacuteficamente configurada para ello DCOS yNomad se encargaraacuten de configurar estos despliegues en sus maacutequinas y poste-riormente eliminarlos Para ello se ha usado la uacuteltima opcioacuten definiendo tareasque descarguen el fichero java Con todo ello se consigue un entorno de inte-gracioacuten continua eficiente que ademaacutes permite la ejecucioacuten de otros servicios deforma independiente
Jenkins permite la creacioacuten de plugins que extienden sus funcionalidadesTanto Nomad22 como Apache Mesos cuentan con uno que permite su integra-cioacuten
Para esta prueba se va a usar el mismo proyecto que para el caso de usode orquestacioacuten de contenedores la aplicacioacuten web al que se le ha antildeadido untest para comprobar que se conecta correctamente a la base de datos medianteMocha un framework de Nodejs Por otro lado se antildeade el plugin de git ya queel coacutedigo se obtiene de GitHub el repositorio remoto de control de versiones delproyecto
El proceso general de ejecucioacuten seriacutea como sigue
1 Se ejecuta el maestro de Jenkins como tarea Docker partiendo de la imagenoficial
2 Al arrancar un trabajo se manda una tarea a los planificadores que laasignaraacuten a un nodo cliente Esta tarea consiste en la descarga del ficherode configuracioacuten Java y arrancarlo configurando el equipo como un clientede Jenkins temporalmente
3 Jenkins ejecuta el trabajo en el nuevo cliente en este caso iniciar la apli-cacioacuten web iniciar las pruebas y generar un informe
4 Se elimina el cliente
A continuacioacuten se detallan los matices de cada herramienta a la hora de imple-mentar este servicio
22Desarrollado por Ivo Verberk httpwwwivoverberknl
41
623 Jenkins con Nomad
El plugin permite la ejecucioacuten del fichero Java mediante dos controladorescontenedores Docker y Java En este proyecto nos hemos decantado por el pri-mero ya que nos ahorra instalar la maacutequina virtual de java en todos los nodoscliente Por ello se ha construido un contenedor base con Java para la ejecucioacutendel fichero de configuracioacuten y Nodejs para lanzar la aplicacioacuten web
El plugin se configura con la direccioacuten IP del cluster y el contenedor queejecuta el esclavo Jenkins Por su parte el trabajo en Jenkins se define conel repositorio en GitHub donde se aloja el coacutedigo del proyecto a probar y loscomandos a ejecutar en este caso npm update y npm test
624 Jenkins con DCOS
En el caso de DCOS su sistema de paquetes incluye Jenkins por lo queal instalarlo ya se tiene la configuracioacuten de Mesos totalmente funcional Sinembargo para ejecutar la aplicacioacuten en particular y las pruebas se requiere deNodejs en los equipos esclavos por ello debemos antildeadir un plugin de Jenkinsque permite instalar este entorno antes de ejecutar el trabajo Una vez hechoesto soacutelo queda definir la tarea igual que en el caso anterior
Cabe destacar que Mesosphere tambieacuten ha desarrollado un plugin que per-mite hacer despliegues en Marathon de tal manera que permitiriacutea con cadacommit del coacutedigo compilar la imagen del contenedor Docker y desplegarlaautomaacuteticamente aunque en este proyecto no se ha hecho pruebas de esta fun-cionalidad
42
7 Escalando la infraestructura
Uno de los factores clave que se busca a la hora de implementar sistemasdistribuidos es el poder escalar la infraestructura de forma maacutes sencilla estoes detectar que las maacutequinas estaacuten alcanzando el liacutemite de su capacidad yaumentar eacutesta ya sea mejorando sus caracteriacutesticas teacutecnicas o antildeadiendo maacutesnodos al cluster
El coacutedigo y todos los ficheros de configuracioacuten de esta seccioacuten tambieacuten sepueden encontrar en el repositorio del proyecto en GitHub23
71 Disentildeo
Microsoft Azure permite organizar los servicios cloud de forma loacutegica a traveacutesde grupos de recursos y asiacute poder crear o eliminar eacutestos en conjunto parauna aplicacioacuten determinada (por ejemplo una aplicacioacuten web suele requerir demaacutequinas virtuales bases de datos almacenamiento) Ademaacutes dispone dela opcioacuten de crear plantillas en formato JSON que permite al desarrolladordefinir los recursos y su interrelacioacuten para desplegar de forma automaacutetica unainfraestructura TI en la nube
Azure tambieacuten ofrece la posibilidad de monitorizar el estado de las maacutequinasvirtuales a traveacutes de extensiones lo que permite configurar el escalado automaacute-tico al alcanzar cierto liacutemite definido por el operador Eacutesta es a priori la formaen que deberiacutea implementarse hablando en teacuterminos de eficiencia sin embargoesta aproximacioacuten es totalmente dependiente de la plataforma es decir no sepuede extrapolar a otro proveedor o sobre recursos propios sin realizar un nue-vo disentildeo En este proyecto las tareas que son ejecutadas por estos equipos notienen estado ya que todo lo relativo a la persistencia lo hemos asignado fueradel cluster esto permite escalar la plataforma a traveacutes de otra aproximaciones
Las plantillas aceptan una serie de variables a indicar por el usuario entreotras los conjuntos de escala para definir los nodos aceptan una variable quedefine el nuacutemero de maacutequinas que los componen Por otro lado Azure ofreceuna API REST y kits de desarrollo software (SDK por sus siglas en ingleacutes) quepermiten su despliegue de forma programaacutetica Aprovechando estas facilidadesen este proyecto se va a aproximar la escalabilidad con el sucesivo desplieguede la infraestructura de forma automaacutetica se monitorizan los equipos y si sedetecta una maacutequina excesivamente cargada se aumenta el nuacutemero de equiposen la plantilla y se vuelve a desplegar
23httpsgithubcomAntonioAlfrzCloud-Orchestrators
43
En este proyecto se han disentildeado las plantillas para desplegar la arquitec-tura necesaria tanto de Nomad como de DCOS En el caso de la primera eldespliegue es maacutes descriptivo ya que incluye maacutequinas virtuales grupos de se-guridad redes En el caso de DCOS Azure cuenta con un servicio especiacuteficopara clusters gobernados por DCOS denominado Azure Container Service queincluye los componentes necesarios y la instalacioacuten ya realizada
72 Implementacioacuten
En primer lugar para monitorizar el estado de los equipos se va a usar laherramienta Nagios un sistema que permite controlar el estado del hardwarey los servicios de un equipo Se trata de una herramienta muy completa de laque se va a usar su capacidad para ejecutar comandos (plugins) en los nodospara detectar picos de carga generar alertas y ejecutar programas para estoseventos
Se ha desplegado una maacutequina virtual con esta herramienta en ambos siste-mas y se ha instalado una extensioacuten de Nagios (Nagios Remote Plugin Executor)en todos los nodos que permite ejecutar comprobaciones remotamente en con-creto para esta prueba de concepto medir el nivel de saturacioacuten de la unidadcentral de procesamiento (CPU por sus siglas del ingleacutes) Cuando sucede uncambio de estado de una maacutequina esto es cuando este paraacutemetro supera el liacutemi-te definido por el operador Nagios permite actuar en consecuencia ejecutandoprogramas por ello se ha desarrollado un script que ejecuta lo siguiente
Un programa desarrollado en Python con el SDK de Azure que modificalas plantillas y despliega los recursos
Un guioacuten de Ansible para instalar todos los componentes necesarios en lasnuevas maacutequinas y arrancar de nuevo el cluster y las aplicaciones
44
8 Resultados y conclusiones
En este uacuteltimo apartado se da una visioacuten global del proyecto asiacute como a lasconclusiones maacutes importantes a las que se ha llegado y posibles temas futurosde desarrollo
81 Comparacioacuten
Ambas herramientas ofrecen las funcionalidades para gestionar los recursoseficientemente ofreciendo a los desarrolladores una plataforma donde desplegarsus aplicaciones de forma distribuida independientemente de los equipos fiacutesicosy el hardware que las soporten
DCOS es una herramienta que en un comienzo fue privativa pero cuyos res-ponsables la empresa Mesosphere decidieron publicar una versioacuten de coacutedigoEacutesta nos permite gestionar un cluster de una forma sencilla y usable ademaacutes decomplementarlo con otras herramientas como el balanceador de carga integradoo la autenticacioacuten de usuarios ademaacutes estaacute basada en Apache Mesos un pro-yecto de relativa madurez y con el soporte de la Apache Software FoundationDe forma resumida DCOS ofrece muchas posibilidades y servicios a cambiode una arquitectura e instalacioacuten maacutes compleja
Por su parte HashiCorp con menor tiempo de desarrollo ha conseguidouna herramienta muy sencilla de desplegar que ademaacutes cumple con todas lasfuncionalidades baacutesicas ejecutando un simple binario en cada nodo se puededesplegar un gestor de clusters totalmente funcional Sin embargo no cuentacon todas las posibilidades de Mesos (Nomad cuenta con menos controladoresque entornos posibles de Mesos) ni con los antildeadidos de DCOS lo que implicael uso de otras herramientas para complementar el servicio (Consul HAProxy)
De entre las dificultades encontradas al usar estas herramientas y desplegaraplicaciones sobre ellas se puede destacar la depuracioacuten en ocasiones se desco-noce si un error viene de la propia herramienta de la aplicacioacuten desplegada o delequipo fiacutesico si no se cuenta con un sistema de procesamiento de registro unose puede encontrar con muacuteltiples terminales abiertas inspeccionando numerososficheros de registro buscando posibles errores Ademaacutes no dejan de ser solucio-nes que para usar eficientemente se debe conocer parte de su funcionamientoy sintaxis a la hora de describir la tareas lo que supone un esfuerzo antildeadido yaque cada una tiene sus particularidades y liacutemites
45
82 Conclusiones
En una sociedad cada vez maacutes digital las empresas deben adaptarse a unmercado cuya demanda de contenido no deja de crecer Las nuevas arquitecturascomo microservicios asiacute como la gran cantidad de datos generada implica queuna mejor gestioacuten de los recursos y la rapidez para desplegar o escalar solucionesdando valor al cliente lo maacutes raacutepido posible es uno de los objetivos de todas lasempresas de base tecnoloacutegica
Las ventajas que ofrecen los planificadores con aplicaciones distribuidas sonnumerosas sin ir maacutes lejos empresas tan punteras como Google llevan maacutesde 10 antildeos orquestando contenedores24 Por un lado permiten aumentar elrendimiento de los equipos propios y por otro implementar un servicio comoplataforma para despliegues distribuidos sobre cualquier conjunto hardware deesta forma se provee un servicio similar al de la nube puacuteblica pero con laprincipal diferencia de que se elimina la independencia con el proveedor (vendorlock-in) esto es las aplicaciones no tienen limitaciones impuestas por eacuteste talescomo lenguaje de programacioacuten o herramientas y permite despliegues hiacutebridosentre recursos propios y la nube
83 Objetivos conseguidos
Implementacioacuten de los planificadores propuestos en la nube Se ha en-tendido y detallado el funcionamiento de estas herramientas y se hanimplementado en el servicio de infraestructura de Microsoft Azure
Despliegue de aplicaciones y servicios distribuidos Servicios que se usanactualmente en la industria del desarrollo software asiacute como una aplica-cioacuten web con una arquitectura moderna han sido desplegados de formadistribuida en los equipos cumpliendo con la funcionalidad esperada ade-maacutes de consiguiendo una alta disponibilidad
Aproximacioacuten de arquitectura escalable Se ha hecho una aproximacioacutende infraestructura escalable de forma que sea parcialmente extrapolable aotros proveedores
24httpwwwnextplatformcom20160322decade-container-control-google
46
84 Liacuteneas de investigacioacuten
Siguiendo con la materia de este proyecto se presentan posibles liacuteneas deinvestigacioacuten
Analizar el despliegue con estas herramientas de aplicaciones de Big Datay comparar la eficiencia con respecto a soluciones especializadas
Analizar el rendimiento de los algoritmos de planificacioacuten antes pruebasde estreacutes y situaciones de alta contienda
Comparar el uso de estas herramientas con las praacutecticas actuales de laindustria o implementacioacuten en un sistema de produccioacuten real
47
Referencias
[1] LA Barroso y U Houmllzle laquoThe Datacenter as a Computer An Introduc-tion to the Design of Warehouse-Scale Machinesraquo En Morgan amp ClaypoolPublishers ()
[2] Systems Research Group ndash NetOS (University of Cambridge) The evolu-tion of cluster scheduler architectures 2016 url httpswwwclcamacukresearchsrgnetoscamsasblog2016-03-09-scheduler-architectureshtml
[3] A Das I Gupta y A Motivala SWIM Scalable Weakly-consistent Infection-style Process Group Membership Protocol Inf teacutec Dept of ComputerScience Cornell University url https www cs cornell edu ~asdasresearchdsn02-swimpdf
[4] D Dubhashi y A Das Mastering Mesos PACKT Publishing mayo de2016
[5] The Apache Software Foundation Apache Mesos documentation urlhttpsmesosapacheorg
[6] David Greenberg Building Applications on Mesos OrsquoReilly Media 2016[7] Armand Grillet Comparison of Container Schedulers Inf teacutec Technische
Universitaumlt Berlin[8] HashiCorp Consul documentation url httpswwwconsulio[9] HashiCorp Nomad documentation url httpsdcosio[10] Dan C Marinescu Cloud computing theory and practice Morgan Kauf-
mann 2013[11] Mesosphere DCOS documentation url httpswwwnomadproject
io[12] Microsoft Azure documentation url httpsazuremicrosoftcom
es-esdocumentation[13] D Ongaro y J Ousterhout In Search of an Understandable Consensus
Algorithm Inf teacutec Stanford University url httpsraftgithubioraftpdf
[14] Fei Teng laquoRessource allocation and schelduling models for cloud compu-tingraquo Tesis de mtriacutea Ecole Centrale Paris 2011
[15] A Williams y col Automation and Orchestration with Docker and Contai-ners A Comprehensive Overview of the Docker and Container Ecosystem3 The New Stack 2016
48
- Resumen
- Summary
- Iacutendice de figuras
- Introduccioacuten y objetivos
-
- Contexto
- Objetivos
- Estructura del documento
-
- Cloud Computing
- Nuevas cargas de trabajo
- Gestioacuten de recursos Planificadores
-
- Sistemas distribuidos
-
- Clasificacioacuten
-
- Herramientas
-
- DCOS
-
- Apache Mesos
- Ejemplos de uso
-
- Nomad
-
- Protocolo de consenso Raft
- Protocolo gossip SWIM
- Planificacioacuten
-
- Casos de uso y despliegue
-
- Aplicacioacuten Web
-
- DCOS
- Nomad
-
- Servicio de integracioacuten continua
-
- DevOps
- Integracioacuten Continua
- Jenkins con Nomad
- Jenkins con DCOS
-
- Escalando la infraestructura
-
- Disentildeo
- Implementacioacuten
-
- Resultados y conclusiones
-
- Comparacioacuten
- Conclusiones
- Objetivos conseguidos
- Liacuteneas de investigacioacuten
-
Servicios de infraestructura (Infrastructure as a Service IaaS) Se ofertanrecursos de computacioacuten puros como procesamiento o almacenamientomediante una plataforma de virtualizacioacuten El cliente puede controlar elsistema operativo componentes de red y aplicaciones
Figura 1 Comparacioacuten Centro de datos - Computacioacuten en la nubeFuente httpsad-hocnet
De entre las numerosas ventajas que ofrece la computacioacuten en la nube se puededestacar su flexibilidad ya que permite aprovisionar recursos y adaptarlos deacuerdo a la demanda reduce el capital inmovilizado y su amortizacioacuten laubicuidad que permite su consumo desde cualquier parte con conexioacuten a la redy la seguridad y fiabilidad que ofrece el proveedor que normalmente cuenta conrecursos geograacuteficamente distribuidos frente a la gestioacuten y mantenimiento derecursos propios
4
3 Nuevas cargas de trabajo
Las organizaciones que cuentan con sus propios infraestructuras TI han co-menzado a adoptar un enfoque de nube privada para gestionar las tareas ofunciones informaacuteticas sobre las que se sustentan el negocio ya que una es-tructura virtualizada puede ofrecer ventajas con respecto a las adaptaciones decentros de datos tradicionales en los aacutembitos de rendimiento escalabilidad eincluso seguridad4
A su vez se han desarrollado nuevas tecnologiacuteas que suponen cargas detrabajo dinaacutemicas y con gran intensidad de consumo de datos para las empresasque se ven beneficiadas al desplegarlas en recursos virtualizados
Big data
Con la creciente aceptacioacuten de las tecnologiacuteas TIC por parte de la sociedadla cantidad de datos generados en la red es ingente Las profesionales de TI tienecomo objetivo extraer valor de eacutestos para por ejemplo prever las tendencias delmercado Sin embargo este incremento exponencial hace que su procesamientoy almacenamiento requiera de un sistema con gran escalabilidad dado el hechode que una sola maacutequina no puede proveer de la capacidad necesaria
Integracioacuten continua
Modelo informaacutetico que consiste en hacer integraciones automaacuteticas de unproyecto con cualquier cambio en el coacutedigo con el objetivo de detectar fallosde forma temprana Esto implica la compilacioacuten del coacutedigo y su ejecucioacuten enun entorno de pruebas automaacuteticamente un proceso que mediante tecnologiacuteasde virtualizacioacuten permiten simular entornos con eficiencia y rapidez Su imple-mentacioacuten en sistemas distribuidos permite tanto una mejor planificacioacuten comoun mejor rendimiento de los recursos
Arquitectura de microservicios
Enfoque para desarrollar aplicaciones software como un conjunto de serviciosautoacutenomos que se comunican entre siacute a diferencia de aproximaciones monoliacuteti-cas donde la loacutegica del servicio estaacute desarrollada como una unidad Un sistemadistribuido permite el despliegue de los componentes en distintas maacutequinas loque mejora tanto su escalabilidad como la tolerancia a fallos
4httpswwwakamaicomesesresourcespublic-private-cloudjsp
5
Docker
Proyecto de coacutedigo abierto que facilita y automatiza el despliegue de aplica-ciones al encapsular el entorno de trabajo en contenedores Linux una tecnologiacuteaque permite a un sistema fiacutesico ejecutar muacuteltiples instancias de sistemas opera-tivos aislados mediante entornos virtuales con sus propios espacios de procesosy redes pero compartiendo el nuacutecleo (kernel) con el equipo anfitrioacuten
En la figura 2 se compara la pila de una virtualizacioacuten tradicional con res-pecto a los contenedores no se simula el sistema operativo por lo que el procesoes mucho maacutes ligero
Docker se caracteriza por
Autosuficiencia Los contenedores cuentan con las libreriacuteas y configuracio-nes necesarias para ejecutarse de manera autoacutenoma al compartir el nuacutecleo
Portabilidad El hecho de que sean autosuficientes implica que es inde-pendiente del host es decir se puede desplegar en cualquier equipo quesoporte esta tecnologiacutea
Tamantildeo El peso de un contenedor es sustancialmente inferior a otrastecnologiacuteas de virtualizacioacuten
Figura 2 Arquitectura DockerFuente httpsdockercom
6
Los componentes fundamentales de esta herramienta son
Imaacutegenes Describen el entorno de base sobre el que ejecutar el contene-dor por ejemplo la imagen del sistema operativo Ubuntu Sobre eacutesta seconstruyen las aplicaciones particulares del usuario dando lugar a otraimagen
Contenedores Se crean a partir de las imaacutegenes y comprenden todo aquellonecesario para arrancar la aplicacioacuten decir su entorno de ejecucioacuten
bull Voluacutemenes Encargados de gestionar la persistencia de datos e inde-pendientes del ciclo de vida del contenedor
Registros Pueden ser puacuteblicos o privados y almacenan las imaacutegenes elregistro puacuteblico oficial de Docker es Docker Hub
Dadas estas caracteriacutesticas los profesionales TI estaacuten comenzando a adoptarDocker ya que facilita tanto los despliegues como el trabajo compartido en dis-tintos entornos Sin embargo esto requiere de un software que permita desplegarlos distintos contenedores de forma que puedan trabajar en conjunto procesoque se ha denominado orquestacioacuten de contenedores
7
4 Gestioacuten de recursos Planificadores
Para sacar el maacuteximo provecho a las tecnologiacuteas anteriormente descritaslo ideal es desplegarlas en sistemas distribuidos sin embargo esto aumenta lacomplejidad del propio despliegue asiacute como la necesidad de software especiali-zado para ello Se necesitan algoritmos de planificacioacuten que permitan obtener elmaacuteximo rendimiento de los recursos por un lado y dar ciertas garantiacuteas de quetodas las tareas y procesos se van a ejecuta por otro
41 Sistemas distribuidos
En primer lugar se definen los sistemas distribuidos o clusters como unconjunto de ordenadores conectados entre siacute cuyo objetivo es trabajar como unauacutenica instancia de gran capacidad5
Su clasificacioacuten variacutea de acuerdo a cada autor pero en general se puedendividir seguacuten su objetivo en alto rendimiento aquellos cuyo objetivos es proveerde gran capacidad de coacutemputo gracias al conjunto de los nodos y alta disponi-bilidad con los cuales se busca la fiabilidad del sistema mediante redundanciayo balanceo de carga
El intereacutes de este proyecto recae en los uacuteltimos ya que el objetivo es porun lado ofrecer al desarrollador un entorno donde desplegar sus aplicaciones deforma distribuida y por otro maximizar el rendimiento de los recursos
De forma general las caracteriacutesticas que se buscan son las siguientes
Elasticidad Adaptacioacuten a cargas dinaacutemicas de trabajo aumentando (o dis-minuyendo) recursos de manera automaacutetica de tal forma que la utilizacioacutensea lo maacutes cercana a la demanda
Disponibilidad Capacidad de un sistema para mantener el servicio fun-cional
Tolerancia a fallos Recuperacioacuten del servicio ante el fallo de un compo-nente
Balanceo de carga Compartir las tareas entre las diferentes maacutequinasredundadas evitando asiacute puntos de uacutenico fallo
5httpsenwikipediaorgwikiComputer_cluster
8
Los programas que se implementan en entornos distribuidos se caracterizanpor ejecutarse de forma concurrente en equipos independientes estar conectadospor una red que introduce fallos aleatorios y no compartir memoria ni reloj Estoimplica entre otras cosas que
Los nodos soacutelo tienen un acceso raacutepido a su memoria local por lo quecualquier informacioacuten relativa al estado global puede ser potencialmenteerroacutenea
Las maacutequinas pueden sufrir caiacutedas de forma aleatoria
El intercambio de informacioacuten puede fallar ya sea por error en transmisioacuteno por caiacuteda de los nodos
Estas dificultades se ponen de manifiesto en el teorema de CAP en cienciasde la computacioacuten el teorema de CAP que lanzado inicialmente como conjetu-ra en el antildeo 2000 por Eric Brewer (motivo por el cual al teorema se le conoceformalmente como teorema de Brewer) y posteriormente demostrado en el antildeo20026 establece que es imposible para un sistema de coacutemputo distribuido ga-rantizar simultaacuteneamente dos de las tres propiedades siguientes
Consistencia (Consistency) es decir que todos los nodos vean la mismainformacioacuten al mismo tiempo Se busca que un cambio en el sistema soacutelose ejecute satisfactoriamente si y soacutelo si se efectuacutea a todos las maacutequinasde tal forma que los datos entre ellos nunca difieren y la respuesta a unapeticioacuten sea la misma independientemente del nodo que la atienda
Disponibilidad (Availability) esto es la garantiacutea de que toda peticioacuten debeobtener una respuesta (servicio funcional) aunque exista inconsistenciaentre nodos
Tolerancia al particionado (Partition Tolerance) es decir que el sistemasiga funcionado a pesar de un fallo en la comunicacioacuten entre los equipos
Por todo lo expresado anteriormente conseguir un sistema distribuido capazde ofrecer procesamiento de forma transparente implica una arquitectura TIcompleja Se requieren de subsistemas y herramientas que permitan la cohesioacutenentre todos los nodos
Gestor de los recursos de las diferentes maacutequinas
Monitorizacioacuten tanto de los servicios activos como de la funcionalidad delsistema ademaacutes de poliacuteticas para recuperacioacuten de fallo
Protocolos de consenso que permitan a los nodos ser consistentes con elestado global del cluster
6urlhttpsgroupscsailmitedutdspapersGilbertBrewer2pdf
9
Herramientas de descubrimiento de servicios que permita la comunicacioacutenentre tareas distribuidas
Planificadores Encargados de distribuir las tareas y procesos en las dife-rentes maacutequinas asignaacutendole parte de su capacidad
Los planificadores del ingleacutes cluster schedulers son un componente funda-mental por lo que vamos a entrar un poco maacutes en detalle en ellos
Planificadores (Cluster Schedulers)
Es el software encargado de monitorizar los recursos usados por cada maacute-quina perteneciente a un cluster y distribuir la carga de trabajo entre ellas deacuerdo a un poliacutetica o reglas
Este tipo de herramientas comparten cierta terminologiacutea que es relevantedefinir
Tarea Unidad de trabajo computacional comprendida por una secuenciade instrucciones datos de entrada y recursos asociados Por ejemplo laejecucioacuten de un comando o el arranque de una base de datos
Nodo Cualquier maacutequina integrante de un cluster En una arquitecturamaestro-esclavo se definen dos roles
bull Cliente Agente Esclavo Aquellos ordenadores que se encargan deejecutar las tareas
bull Maestro Servidor Su objetivo es mantener el estado del cluster ygestionar sus recursos
411 Clasificacioacuten
A lo largo de los uacuteltimos antildeos se han desarrollado diferentes tipos de plani-ficadores[2]
Monoliacutetico
Un solo planificador que se encarga de distribuir todas las tareas entran-tes La mayoriacutea de los planificadores en computacioacuten de alto rendimiento asiacutecomo Borg desarrollado por Google son de este tipo En la figura 3 se pue-de observar de forma graacutefica el procedimiento siendo las cajas grises maacutequinaspertenecientes al cluster y los ciacuterculos las tareas a asignar
10
Figura 3 Planificador monoliacuteticoFuente httpswwwclcamacuk
Planificacioacuten de dos niveles
La mayoriacutea de los clusters ejecutan aplicaciones con distintas necesidadesdesde procesos casi instantaacuteneos hasta servicios persistenteslo que implica dis-tintas necesidades de recursos
Por ello la planificacioacuten a dos niveles distingue dos funciones la gestioacutende recursos (gestor) y la disposicioacuten de las tareas (planificador) Cada serviciotiene su propio planificador de tal manera que el gestor les ldquoofertardquo recursosde acuerdo a una poliacutetica y los planificadores se encargan de escoger la maacutesadecuada Esto permite que el proceso de distribucioacuten sea maacutes acorde con lasnecesidades de los diferentes servicios Apache Mesos que detallaremos maacutesadelante sigue este esquema
Como desventaja cabriacutea sentildealar que esta programacioacuten implica que los pla-nificadores pierden la vista general de la infraestructura y las tareas soacutelo puedenejecutarse con los recursos que les son ofrecidos lo que dificulta la implementa-cioacuten de prioridades de ejecucioacuten de tareas entre otras
Figura 4 Planificador de dos niveles
11
Planificacioacuten de estado compartido
Muacuteltiples reacuteplicas del estado del cluster se actualizan independientementepara cada planificador como se observa en la figura 5 cuando sucede un cambiode forma local el planificador se encarga de informar al resto
Ejemplo de este tipo son Omega la evolucioacuten de Borg por parte de GoogleMicrosoft Apollo y Nomad que usaremos para los casos de uso
De entre las desventajas se puede destacar el hecho de que en general losnodos trabajan con informacioacuten desactualizada lo que conlleva una degradacioacutendel rendimiento en situaciones de alta contienda
Figura 5 Planificador de estado compartido
Planificacioacuten distribuida
En este caso no existe coordinacioacuten entre los distintos planificadores Cadauno de ellos funciona con su propia vista del cluster Las tareas pueden serorganizadas por cualquiera de ellos y desplegadas en cualquier parte del clusteren base a la aleatoriedad y multiplexacioacuten estadiacutestica de los flujos de trabajosin ninguacuten control central
Figura 6 Planificador distribuido
12
5 Herramientas
En la industria comienzan a aparecer soluciones software de coacutedigo abiertoque aglutinan los servicios necesarios para gestionar la infraestructura TI de ma-nera maacutes eficaz El objetivo es doble se busca facilitar la gestioacuten de los recursosde computacioacuten para organizaciones con instalaciones propias mediante su usocon un enfoque cloud esto es desplegar aplicaciones a traveacutes de un conjuntode ordenadores de forma transparente y sin tener en cuenta la infraestructurasubyacente o aprovechar el maacuteximo rendimiento de la infraestructura de losproveedores cloud puacuteblicos de forma que se tiene el maacuteximo control sobre eacutestapero no se depende de las soluciones propietarias permitiendo asiacute despliegueshiacutebridos
Entre estas herramientas se pueden destacar
OpenStack Proyecto desarrollado por la fundacioacuten del mismo nombre paraproporcionar servicios de infraestructuras (IaaS) basado en componentesque se comunican a traveacutes de APIs El componente Magnum incluye mo-tores de orquestacioacuten de contenedores
Kubernetes Sistema de orquestacioacuten de contenedores Docker creado por Goo-gle
CoreOs Sistema operativo basado en Linux disentildeado para despliegues distri-buidos sobre contenedores incluyendo mecanismos de descubrimiento deservicio y comparticioacuten de configuracioacuten
Docker Swarm Herramienta nativa de orquestacioacuten de contenedores Docker
YARN Entorno de gestioacuten de recursos y aplicaciones distribuidas de Hadoopuna libreriacutea software de procesamiento de grandes conjuntos de datos
Como podemos observar existe un gran rango de opciones para gestionar lainfraestructura desde un bajo nivel como puede ser OpenStack hasta Kuberne-tes o Docker Swarm que ofrecen exclusivamente orquestacioacuten de contenedores
En este trabajo se ha optado por Mesosphere DCOS y HashiCorp Nomadque se encuentran en el teacutermino medio su objetivo es proporcionar serviciosde plataforma que permitan la coexistencia dediferentes cargas de trabajo en elcluster
13
51 DCOS
DCOS es un proyecto de coacutedigo abierto7 creado y desarrollado por la empre-sa Mesosphere Se describe como un sistema operativo distribuido que abstraelos recursos de un cluster (capacidad de procesamiento memoria) permite lagestioacuten de muacuteltiples ordenadores de forma transparente y simplifica la instala-cioacuten de aplicaciones distribuidas
Su arquitectura se puede comparar a la de Linux en teacuterminos de nuacutecleo(kernel) y espacio de usuario El primero consta de recursos protegidos a losque no puede acceder el usuario e involucra operaciones de bajo nivel comoasignacioacuten de recursos o aislamiento de procesos En el espacio de usuario seejecutan las aplicaciones y servicios de maacutes alto nivel
Siguiendo con este siacutemil el nuacutecleo de DCOS estaacute basado en Apache Mesosque se explicaraacute en un apartado posterior y el espacio de usuario que estaacute com-prendido por los componentes del sistema esto es las diferentes herramientasque en conjunto conforman DCOS y los servicios encargados de planificar yejecutar las aplicaciones y tareas del usuario
Figura 7 Arquitectura DCOSFuente httpsdcosio
De entre los componentes que conforman DCOS destacan
Admin Router Balanceador de carga central basado en NGINX que dis-pone un proxy entre todos los servicios en el puerto 80 permitiendo sugestioacuten mediante la interfaz graacutefica Ademaacutes se encarga de la autenticacioacutenpara acceder al panel de administracioacuten
Cosmos Gestor de paquetes de las aplicaciones
Diagnostics Se ejecuta en todos los nodos y se encarga de monitorizar elestado de los daemons que sustentan DCOS
7Desde abril de 2016 httpsmesospherecomblog20160419open-source-dcos
14
Exhibitor Gestiona y automatiza el despliegue de ZooKeper la herra-mienta que provee de configuracioacuten centralizada y registro de nombres
Marathon Equivale al proceso init de los sistemas tipo Unix esto es elprimer proceso en ejecucioacuten tras la carga del kernel y que genera los demaacutesprocesos Se encarga de arrancar y monitorizar las aplicaciones y servicios
Mesos-DNS Servicio de DNS interno que define el dominio mesos pa-ra nodos y tareas en el cluster es decir permite resolver nombres conindependencia de la direccioacuten fiacutesica
Minuteman Balanceador de carga integrado a nivel TCPUDP disponiblepara las propias aplicaciones
Por otra parte se definen como servicios a las diferentes aplicaciones dis-tribuidas que DCOS permite instalar en el cluster y que pueden haber sidodesarrollados por la misma empresa Mesosphere o por terceros por ejemploApache Spark Jenkins o Apache Hadoop En la figura 8 se muestra un diagramade los servicios disponibles incluyendo algunos de las aplicaciones distribuidasque soporta DCOS
Figura 8 Servicios DCOSFuente httpsdcosio
511 Apache Mesos
El nuacutecleo de DCOS estaacute basado en Apache Mesos un proyecto de coacutedigoabierto creado por la Universidad de California Berkeley y desarrollado actual-mente por la fundacioacuten Apache Se trata de un administrador de clusters queabstrae los recursos y los dispone para diferentes aplicaciones y entornos de tra-bajo distribuidos (frameworks) mediante una interfaz comuacuten En el momento deredaccioacuten de este proyecto Apache Mesos soportaba una variedad de entornosque abarcaba desde Big Data (Apache Spark Hadoop) hasta bases de datos(Cassandra Hypertable)
15
Arquitectura
Mesos se basa en la asignacioacuten de dos roles diferentes a los nodos
Maestros (Masters) Se encargan de la gestioacuten y reparticioacuten de los recursospara los diferentes entornos de trabajo mediante ldquoofertas de recursosrdquo deacuerdo a los disponibles y a la poliacutetica de asignacioacuten (planificacioacuten en dosniveles)
Esclavos (Slaves) Ordenadores donde se ejecutaraacuten las aplicaciones y cu-yos recursos son ofertados por los maestros
En el caso de fallo del maestro las tareas pueden seguir ejecutaacutendose perono se podraacute asignar nuevos recursos ni tareas por ello pueden existir varios enel cluster para configuraciones de alta disponibilidad pero soacutelo uno orquesta alos esclavos
Para la eleccioacuten del master liacuteder Mesos usa Apache ZooKeeper un proyectode software desarrollado por la misma fundacioacuten cuyo objetivo es proveer deun servicio de configuracioacuten centralizado y registro de nombres8
Por otra parte los entornos de trabajo son los programas que deciden final-mente queacute recursos se van a usar y se encargan de que los esclavos ejecuten lastareas Eacutestos se ejecutan sobre Mesos y constan de dos componentes
Planificador (Scheduler) Optimiza y decide los recursos a utilizar de losofertados informando a los Masters
Procesador (Executor) Ejecuta las aplicaciones o servicios en los esclavos
El objetivo final es conseguir una interfaz liviana tolerante a fallos paracualquier tipo de entorno de trabajo de tal manera que en los esclavos del clusterpuedan ejecutarse simultaacuteneamente tareas con necesidades y duracioacuten diferentesPara ello se basa en dos conceptos asignacioacuten y aislamiento de recursos
Asignacioacuten de recursos
En el cluster pueden coexistir entornos de trabajo con tareas de larga dura-cioacuten y con gran consumo de recursos con tareas cortas que los ocupan y liberancon rapidez El maestro integra un moacutedulo de asignacioacuten de recursos (allocationmodule) que se encarga del algoritmo de distribucioacuten
En el momento de escribir este proyecto estaban desarrollados dos moacutedulosuno mediante el cual el usuario puede asignar prioridades y otro que implementa
8httpszookeeperapacheorg
16
el algoritmo Dominant Resource Fairness9 a grandes rasgos se determina entodos los esclavos la tarea en ejecucioacuten que necesita maacutes recursos y se calcula laproporcioacuten del recurso de mayor peso con respecto al total por ejemplo si unatarea ocupa 2 GB de memoria con respecto a 10 GB totales que tiene el clusterse le asigna un dominant share del 20 la tarea se asignaraacute al nodo con menordominant share
Aislamiento de recursos
Para conseguir que tareas de diferentes entornos de trabajo y con distin-ta naturaleza se ejecuten simultaacuteneamente en un mismo nodo Mesos usa loscontenedores Linux (descritos en la seccioacuten 3)
Funcionamiento
La figura 9 muestra el esquema de la arquitectura de Apache Mesos conalta disponibilidad (tres maestros) y con dos entornos de trabajo ejecutaacutendo-se Hadoop que permite el almacenamiento y procesamiento de gran cantidadde datos para proyectos de big data y un sistema que implementa la interfazsistema de paso de mensajes MPI
Como se puede observar el sistema ZooKeeper elige a un solo maestro comoliacuteder y eacuteste orquesta el cluster comunicando los esclavos con los planificadoresde los diferentes entornos de trabajo Tambieacuten se puede observar como las tareasde los distintos entornos estaacuten distribuidas entre los tres esclavos disponibles
Figura 9 Arquitectura de Apache MesosFuente httpsmesosapacheorg
El proceso de asignacioacuten se realiza como sigue en primer lugar un usuariosolicita la ejecucioacuten de una tarea mediante la interfaz de cada entorno de traba-jo (interfaz graacutefica API HTTP ) De forma paralela un esclavo informa almaestro de los recursos que tiene libres En consecuencia eacuteste se lo notifica almoacutedulo de asignacioacuten que en funcioacuten de su configuracioacuten decide cuaacutento ofertar
9httpspeopleeecsberkeleyedu~aligpapersdrfpdf
17
y a queacute entorno de trabajo y enviacutea la oferta a los planificadores Eacutestos respondenal maestro con queacute recursos ha decidido usar para cada tarea Finalmente lastareas son enviadas al esclavo seleccionado el cual asigna los recursos indicadosal procesador (executor) quien finalmente las ejecuta
Cabriacutea pensar que esta metodologiacutea puede conducir a situaciones en lasque un entorno podriacutea quedarse con tareas sin ejecutarse a la espera de unaoferta satisfactoria para ello Mesos implementa un sistema de filtros medianteel cual los entornos especifican los requisitos miacutenimos que debe cumplir unaoferta por ejemplo se puede especificar en queacute nodos debe desplegarse la tareaEste sistema estaacute disentildeado asiacute con el objetivo de mantener lo maacutes transparenteposible esta herramientas de forma que acepte entornos de trabajo de distintasnaturalezas
512 Ejemplos de uso
Grandes empresas estaacuten usando Apache Mesos con eficacia de acuerdo a susnecesidades e infraestructuras Caben destacar
Ebay En el modelo de implementacioacuten continua en esta empresa10 cadadesarrollador cuenta con su propia instancia que se ejecuta en una maacutequinavirtual dedicada lo que ha conllevado un uso de los recursos poco eficiente Enuna prueba de concepto consiguieron realizar una herramienta de integracioacutencontinua distribuida basada en un cluster con Apache mesos y con el entornoMarathon y Jenkins
Apple Anuncioacute que el motor de su famosa herramienta de asistencia per-sonal para iPhones Siri estaacute desplegada sobre Apache Mesos11 Para ello handesarrollado su propio entorno para facilitar a los ingenieros a desplegar los ser-vicios que la herramienta necesita para resolver las peticiones de los usuarios
Twitter Desarrolloacute su propio entorno denominado Aurora y actualmentegestionan sus recursos y miden el coste de las tareas que los empleados usancon el objetivo de que sean conscientes del gasto que puede suponer un usoinadecuado de la infraestructura12
10httpwwwebaytechblogcom20140404delivering-ebays-ci-solution-with-apache-mesos-part-i11httpwwwbusinessinsidercomapple-siri-uses-apache-mesos-2015-812httpswwwlinuxcomNEWS4-UNIQUE-WAYS-UBER-TWITTER-PAYPAL-AND-HUBSPOT-USE-APACHE-MESOS
18
52 Nomad
Herramienta de coacutedigo abierto de gestioacuten de clusters creada y desarrolladapor Hashicorp13 que permite el despliegue de aplicaciones y procesos de formadistribuida
Las principales diferencias con Apache Mesos a grandes rasgos son
Arquitectura maacutes ligera Nomad soacutelo requiere de un fichero para funcionarejecutaacutendolo con las correspondientes configuraciones en todos los nodosrealiza las funciones de gestioacuten del cluster eleccioacuten de liacuteder planificacioacutende recursos y ejecucioacuten de las tareas
Centro de datos y regiones muacuteltiples Su arquitectura estaacute orientada afacilitar la gestioacuten de diferentes centros de datos geograacuteficamente distri-buidos
Entorno de ejecucioacuten Las tareas se definen y son interpretadas mediantecontroladores integrados en Nomad que se valen de los recursos y herra-mientas de los nodos clientes para ejecutarlas Esta integracioacuten dificultael desarrollo de controladores por parte de terceros a diferencia de Mesosque delega dicha responsabilidad en los entornos de trabajo externos alproyecto
Usa un planificador de estado compartido con respecto a la planificacioacutenen dos niveles de Mesos
Antes de entrar en maacutes detalle en la arquitectura es importante definir lossiguientes teacuterminos
Controlador (Driver) Software que se encarga de interpretar las definicionesde las tareas y ejecutarlas semejante a los procesadores de los entornosde trabajo de Mesos A la hora de redactar este proyecto Nomad contabacon controladores para contenedores Docker virtualizacioacuten de maacutequinasmediante el emulador QEMU aplicaciones java y archivos binarios
Grupo de trabajo (Task Group) Conjunto de tareas que se ejecutan en elmismo nodo cliente
Trabajo (Job) Conjunto loacutegico de tareas y grupos de trabajo que se despliegana la vez
Asignacioacuten (Allocation) Relacioacuten entre un grupo de trabajo y el cliente don-de se ejecuta
Evaluacioacuten (Evaluation) Proceso mediante el cual Nomad planifica y ges-tiona el registro o actualizaciones de los trabajos
13httpswwwhashicorpcom
19
Nomad sigue una arquitectura maestro-esclavo similar a la de Apache Mesosmuacuteltiples servidores acuerdan entre siacute un liacuteder que gestiona la planificacioacuten detareas en los clientes que soacutelo conocen sus asignaciones y las ejecutan
Todos los servidores participan paralelamente en tareas de planificacioacuten derecursos y asignacioacuten de tareas y ademaacutes entre ellos eligen un liacuteder que seencarga de la coordinacioacuten de la suscripcioacuten de los clientes al cluster y de lagestioacuten de las peticiones
Los clientes estaacuten configurados para comunicarse con el servidor usando lla-madas a procedimiento remoto (RPC por sus siglas en ingleacutes) que permite unordenador ejecutar coacutedigo en otra maacutequina Mediante esta tecnologiacutea los nodosclientes avisan de su estado e informa de sus asignaciones recursos y controla-dores disponibles
Existe la posibilidad de gestionar varios centros de datos agrupados en regio-nes eacutestas son independientes pero permite definir tareas o comprobar el estadode todas ellas desde cualquier punto A continuacioacuten se muestra una figura dela arquitectura a alto nivel de esta configuracioacuten
Figura 10 Arquitectura multi-regioacuten en NomadFuente httpswwwnomadprojectio
La herramienta se sustenta sobre tres protocolos fundamentales un protocolode consenso entre los servidores para compartir informacioacuten sobre su estado yel liacuteder un protocolo Gossip para la gestioacuten entre regiones y el planificador detareas
521 Protocolo de consenso Raft
El objetivo es obtener consistencia en un conjunto de nodos que comparteninformacioacuten es decir si un cliente realiza un cambio que todos los nodos veanla misma informacioacuten a la vez y ademaacutes sea tolerante a fallos Para ello se basaen el algoritmo Raft[13] que se detalla brevemente a continuacioacuten
20
Los nodos participantes en el algoritmo pueden estar en tres estados
Liacuteder (Leader) Todos los cambios que realicen en el cluster pasan por eacutel pri-mero
Seguidor (Follower) Nodo pasivo cuya responsabilidad es responder a laspeticiones del nodo liacuteder
Candidato (Candidate) Maacutequina que no ha encontrado liacuteder y solicita sueleccioacuten
Supongamos que tenemos cinco equipos que acaban de arrancar el protocoloEn la figura 11 se observan los nodos y sus respectivos registros a la derecha
Figura 11 Equipos sin consenso ejecutando el protocolo RAFTFuente httpsgithubcomongardieraftscope
Al comenzar todos los nodos son seguidores esperando recibir comunicacioacutende un nodo que actuacutee como liacuteder Cada nodo tiene un tiempo de espera aleatoriodespueacutes del cual si no es informado por un liacuteder pasa a estado candidato y pideel ldquovotordquo al resto de los participantes El algoritmo divide el tiempo en plazos uncandidato pasa a liacuteder si recibe la mayoriacutea de los votos en un plazo determinadoSe define mayoriacutea o cuoacuterum (quorum) comolceil
N2rceil
+ 1 (1)
donde N representa el nuacutemero de nodos
Para el ejemplo propuesto de 5 equipos se requieren de 3 votos Soacutelo losnodos que se encuentren en estado seguidor pueden votar una uacutenica vez a laprimera solicitud que reciba dentro de un plazo
Supoacutengase que el nodo denotado con S1 ha cumplido su tiempo de espera yrealiza la peticioacuten de voto (figura 12) A partir de este momento se pueden dartres casos
La maacutequina gana la eleccioacuten y pasa a ser liacuteder informando al resto
Otro servidor se establece como liacuteder en el mismo momento
Varios nodos pasan a ser candidatos por lo que ninguno consigue los votos
21
Figura 12 Un equipo pasa a estado candidato (RAFT)
Si un candidato recibe un aviso de un liacuteder en el mismo plazo el primeropasa a ser seguidor y se acaba la eleccioacuten de liacuteder
Por otro lado si un equipo candidato no recibe los votos en el plazo y agotasu tiempo de espera avanza al siguiente plazo y repite el proceso de votacioacutenLa tercera posibilidad puede conllevar a un estado indefinido ya que varioscandidatos pueden agotar su tiempo de espera al mismo tiempo y repartir losvotos Para solventarlo el algoritmo establece tiempos de espera aleatorios paralos candidatos
Siguiendo con el ejemplo propuesto el servidor S1 pasa a ser el liacuteder Cadacierto tiempo eacuteste debe realizar avisos a los nodos seguidores para no agotar sutiempo de espera
En este momento el cluster de servidores estaacute en ldquoconsensordquo y la informacioacutenen todos los nodos estaacute actualizada Un cambio en la informacioacuten inicia unproceso de replicacioacuten el liacuteder registra el cambio lo pasa al resto de nodos yuna vez eacutestos responden el cambio se hace efectivo
Supoacutengase que se realiza un cambio en los datos en la figura 13 en la partederecha se observa el cambio en el registro del servidor S1 que informa a losnodos seguidores En consecuencia los nodos registran el cambio y responden aS1
Figura 13 Cambio en un registro (RAFT)
Una vez el cuoacuterum (en el ejemplo tres equipos) informa al liacuteder de que
22
ha registrado el cambio el liacuteder lo hace efectivo en su sistema y notifica a losnodos que hacen lo mismo En la figura 14 el enviacuteo todaviacutea no ha llegado ala maacutequina S3 y se observa que no ha hecho efectivo el cambio (en el registroaparece punteado)
Figura 14 Aprobacioacuten del resto de equipos (RAFT)
Este protocolo funcionaraacute correctamente mientras exista un nuacutemero de nodosen funcionamiento igual o superior al cuoacuterum en el ejemplo propuesto elcuoacuterum es tres por lo que el sistema puede tolerar la caiacuteda de dos de los equipos
522 Protocolo gossip SWIM
Nomad permite la gestioacuten simultaacutenea de varios centros de datos reparti-dos en regiones geograacuteficamente separadas requiriendo de un protocolo ligeroque mantenga a los miembros actualizados sobre los participantes del conjun-to Para ello usa una ligera variante del protocolo SWIM[3] (Scalable Weakly-consistent Infection-style Process Group Membership Protocol) desarrollada porHashiCorp Estaacute clasificado como un protocolo de tipo gossip que debe su nom-bre a la semejanza con coacutemo se distribuye un rumor en una red social
SWIM se sustenta en dos caracteriacutesticas fundamentales la deteccioacuten de fallosy la distribucioacuten de la informacioacuten relativa a los miembros A continuacioacuten sedetalla el funcionamiento de ambos componentes
Deteccioacuten de fallos
Este componente tiene dos paraacutemetros el periodo de protocolo T y el nuacutemerode subgrupos de deteccioacuten de fallos k en los que se dividen los nodos Paracomprobar la comunicacioacuten entre dos maacutequinas usa la utilidad ping basadaen el protocolo ICMP La deteccioacuten de caiacuteda de un servidor sigue el siguientealgoritmo
Durante el periodo T cada miembro Mi de un subgrupo elige otro al azar Mjdel mismo subgrupo y le enviacutea un mensaje ping para comprobar su estado Enel caso de que se cumpla un tiempo de espera determinado por una estimacioacuten
23
del tiempo de ida y vuelta (RTT por sus siglas en ingleacutes) de la red y no hayarespuesta Mi le vuelve a enviar un mensaje ping indirectamente a traveacutes deun nuacutemero k de miembros escogidos aleatoriamente De no recibir ninguna res-puesta Mi establece que Mj ha sufrido un fallo y lo etiqueta como ldquosospechosordquoinformando al componente de distribucioacuten
Figura 15 Diagrama de tiempo del protocolo SWIMFuente httpswwwcscornelledu
Componente de distribucioacuten
Se encarga de informar de cualquier cambio en los miembros a todo el con-junto Los eventos de nodo caiacutedo y la unioacuten o disociacioacuten de un miembro setransmiten a todos los servidores para que actualicen sus lista Para distribuirla informacioacuten a todos los nodos se podriacutea usar el meacutetodo de multicast perosuele estar deshabilitado Por ello se utiliza una teacutecnica de transmisioacuten denomi-nada Piggybacking mediante la cual se adjunta a los propios mensajes PINGy ACK del algoritmo la informacioacuten a distribuir reduciendo asiacute la congestioacutenen la red
523 Planificacioacuten
Proceso encargado de distribuir las tareas entre los nodos clientes de acuerdoa su estado
El planificador de Nomad estaacute basado en las publicaciones de Google sobresus herramientas de gestioacuten de clusters Borg y Omega14 y entiende los trabajosdescritos por el usuario como un estado deseado es decir su despliegue en unamaacutequina cliente de forma correcta y los clientes como el estado actual esto eslo que se encuentra en ejecucioacuten El registro actualizacioacuten o cancelacioacuten de un
14httpresearchgooglecompubspub43438html
24
trabajo asiacute como el fallo de un nodo cliente implican un cambio de estado atramitar por el sistema lo que se define como evaluacioacuten (evaluation) Esto uacutelti-mo supone comparar el estado actual (clientes) con el estado deseado (conjuntode trabajos registrados) y enviarlos a los planificadores correspondientes que seencargaraacuten de asignar las tareas a los nodos clientes
Figura 16 Procedimiento de asignacioacuten en NomadFuente httpswwwnomadprojectio
En la figura 16 se observa el flujo de trabajo en el que las distintas evalua-ciones se encolan en el evaluation broker que se ejecuta en el servidor liacuteder ygestiona las evaluaciones pendientes asignaacutendoles prioridades
A continuacioacuten los nodos servidores ejecutan los scheduling workers queprocesan las evaluaciones llamando a los distintos planificadores que generanun plan de asignacioacuten esto es un conjunto de relaciones entre las tareas y losnodos clientes donde se ejecutaraacuten Este proceso se divide en dos fases primerose descartan aquellos clientes que no cumplan los requisitos y posteriormentese asigna una calificacioacuten al resto Se selecciona el nodo con mayor puntuacioacuteny se encola el plan en el gestor que se ejecuta en el servidor liacuteder Existen tresplanificadores de acuerdo al tipo de trabajo
Service Incluye aquellos trabajos que estaacuten destinados a ejecutarse en un pe-riacuteodo largo de tiempo Para realizar las asignaciones el planificador evaluacuteala mayor parte de los nodos y usa una versioacuten del algoritmo Best fit in-fluenciada por el trabajo de Google en su herramienta Borg Se trata deun algoritmo de planificacioacuten que sacrifica tiempo a cambio de maximizarel rendimiento de los clientes asignando la tarea a la maacutequina que tengala mayor carga de trabajo con el objetivo de reducir equipos en funciona-
25
miento
Batch Tareas que incluyen listas de comandos en general de menor duracioacuteny que no requieren interaccioacuten con el usuario Se vale del algoritmo deSparrow desarrollado por la universidad de Berkeley15 para limitar losnodos clientes a evaluar
System Trabajos destinados a ejecutarse en todos los nodos incluso los que seunen al cluster posteriormente
Core Mantenimiento interno de Nomad
Una vez se ha realizado el proceso de planificacioacuten el nodo liacuteder lo registra enla cola de planes (plan queue) que se encarga de asignarles prioridad y manejarcondiciones de carrera es decir que no accedan a los recursos de los clientes sincontrol y evitar que eacutestos superen su capacidad
La maacutequina liacuteder del conjunto puede de este modo aceptar una asignacioacuteny ser ejecutada por los clientes o por el contrario rechazaacutersela al planificadorlo que implicariacutea realizar un plan parcial o totalmente nuevo
Finalmente el estado de las evaluaciones se actualizan y los clientes soninformados de las asignaciones ejecutaacutendose las tareas
15httppeopleeecsberkeleyedu~keopublicationssosp13-final17pdf
26
6 Casos de uso y despliegue
Con el objetivo de mostrar las posibles utilidades que este tipo de sistemaspueden tener en las infraestructuras TI actuales se han desplegado las dos he-rramientas en la nube Microsoft Azure usando su servicio cloud de instancias demaacutequinas virtuales Linux para simular un conjunto de ordenadores conectadosentre siacute por una red LAN Sobre ellas se ha implementado dos casos de usouna aplicacioacuten web con una arquitectura con cierta orientacioacuten a microserviciosy un sistema de integracioacuten continua
El coacutedigo y todos los ficheros de configuracioacuten se pueden encontrar en elrepositorio del proyecto en GitHub16
61 Aplicacioacuten Web
Se busca simular el proceso de adaptacioacuten de una solucioacuten web para su des-pliegue en un sistema distribuido con las herramientas anteriormente descritascon el objetivo de aumentar tanto su escalabilidad como disponibilidad medianteredundancia
Se ha partido de una aplicacioacuten ya existente17 un servicio de almacenamien-to y reproduccioacuten de canciones A grandes rasgos este servicio permite crearusuarios subir canciones con sus respectivas portadas tener playlists propias yescuchar las canciones a traveacutes de un navegador web
La solucioacuten estaacute dividida en 4 partes (figura 17)
Una vista web con la loacutegica
Un almacenamiento conectado en red (NAS por sus siglas en ingleacutes)
Una API REST para gestionar las peticiones al almacenamiento
Base de datos NoSQL basada en MongoDB
La nueva tendencia de los proyectos web es su implementacioacuten en contene-dores Docker ya que facilitan su portabilidad y ofrecen un procedimiento dedespliegue raacutepido sobre todo a la hora de desarrollar y realizar pruebas en en-tornos de produccioacuten simulados Por ello en este caso se va a hacer uso de los
16httpsgithubcomAntonioAlfrzCloud-Orchestrators17httpsgithubcomsonsoleslpCDPSfy
27
motores de orquestacioacuten de contenedores de ambas herramientas Marathon enDCOS y el controlador Docker en el caso de Nomad
Figura 17 Arquitectura aplicacioacuten web
A continuacioacuten vamos detallar el despliegue en ambas herramientas de es-ta solucioacuten y observar tanto queacute dificultades se encuentran como que ventajasofrecen El objetivo final es adaptar el proyecto modificaacutendolo lo menos posiblecon objeto de analizar la capacidad de estas herramientas para desplegar cual-quier aplicacioacuten sin que eso conlleve la modificacioacuten de la arquitectura de eacutestaes decir que no sea dependiente del entorno
611 DCOS
Se ha descrito DCOS como una herramienta que se despliega sobre un con-junto de ordenadores y que permite instalar gestionar el despliegue de sistemasdistribuidos
Microsoft Azure cuenta con una plantilla para desplegar en su servicio cloudun cluster de maacutequinas virtuales con DCOS ya instalado que cuenta con
Maacutequinas maestras (1 3 o 5 a seleccionar por el usuario) configuradascomo un conjunto de disponibilidad esto eso Azure da ciertas garantiacuteasde que al menos una maacutequina estaraacute en funcionamiento
Maacutequinas agentes Por motivos de seguridad se distinguen dos roles
bull Nodos privados solo accesibles desde la red interna y configuradoscomo un conjunto de escala un recurso de Azure para gestionar ydesplegar maacutequinas con configuraciones ideacutenticas para permitir unraacutepido escalado
bull Un equipo conectado accesible desde Internet a travntildees de un balan-ceador de carga puacuteblico y situado en una subred externa
28
Dos balanceadores de carga
bull La interfaz puacuteblica del cluster que se conecta con el cliente puacuteblicobull Acceso a los equipos maestros para el administrador que soacutelo permiteconexioacuten mediante SSH y credenciales
Almacenamiento para todas las maacutequinas
Configuraciones necesarias de red y seguridad
En la figura 18 se observa un diagrama de la infraestructura
Figura 18 Infraestructura en Azure
El primer obstaacuteculo es la persistencia de estado de la aplicacioacuten que seconsigue gracias a una base de datos no relacional basada en MongoDB asiacutecomo el almacenamiento de las canciones Para implementarla tenemos variasposibilidades
Montar un sistema externo de almacenamiento conectado en red en todoslos agentes donde se ejecuten las tareas de esta manera si una tarea pasade un nodo a otro por cualquier motivo puede tener acceso a los mismosficheros (opcioacuten del caso de uso original)
Implementar un sistema de ficheros distribuidos en los agentes
Usar los servicios de almacenamiento de las nubes puacuteblicas
Aprovechar el sistema de voluacutemenes persistentes de Apache Mesos Eacutestepermite reservar recursos de un agente de forma que al arrancar una tarease crea un volumen independiente del ciclo de vida de eacutesta con ello esosrecursos donde se ha almacenado la informacioacuten pueden volver a ofrecerseal mismo entorno de tal manera que otra tarea pueda acceder a ella
DCOS aprovecha este sistema de voluacutemenes persistentes y permite instalarbases de datos distribuidas como ArangoDB o Apache Cassandra sin embargoesto implicariacutea modificar todo el coacutedigo referente al modelo de la base de datos
29
Por motivos de eficiencia y latencia asiacute como de una mayor gobernabilidadde los datos la mejor opcioacuten es usar el recurso de voluacutemenes persistentes queofrece Apache Mesos ya que de esta manera se gestionariacutea la aplicacioacuten completamediante una uacutenica herramienta Sin embargo esto implica que la informacioacutense encuentra exclusivamente en el agente donde se haya ejecutado la tarea y porlo tanto se sigue requiriendo de software externo para distribuir la informacioacutenpara que se accesible para todos los agentes A la hora de realizar este proyectose encontraba en desarrollo Flocker una solucioacuten desarrollada por ClusterHQque permite compartir los voluacutemenes de Docker a traveacutes de un cluster quesi bien es compatible con el planificador de Mesos el proyecto se encontrabatodaviacutea en fases tempranas de desarrollo y los sistemas de almacenamiento quesoporta quedaban fuera del aacutembito de este trabajo
Por todo ello dado que las maacutequinas se han desplegado en la nube puacuteblicade Azure se decidioacute usar su servicio de almacenamiento de objetos para lascanciones y otra maacutequina para desplegar MongoDB y asiacute mantener el modelode datos original de la aplicacioacuten La diferencia del almacenamiento de obje-tos con respecto a nivel de fichero es que el primero no tiene jerarquiacutea paraorganizar los archivos eacutestos se guardan como objetos (con sus metadatos) enun mismo espacio soacutelo diferenciaacutendose por un identificador uacutenico esto implicaentre otras cosas que se puede acceder a un fichero dado uacutenicamente su IDindependientemente de la localizacioacuten fiacutesica de eacuteste facilitando pues la gestioacuteny el desarrollo
El coacutedigo del proyecto se ha modificado en los siguientes apartados
Las direcciones de la base de datos y los balanceadores de carga asiacute comosus puertos estaban originalmente fijos Se han configurado como variablesde entorno para facilitar el descubrimiento del servicio y hacer transpa-rente la aplicacioacuten al entorno de despliegue
La API REST se ha adaptado al almacenamiento en Azure en vez de enlocal
Estas modificaciones no suponen un cambio sustancial pero permiten separala persistencia de las tareas ejecutadas por DCOS lo que facilita en granmedida su ejecucioacuten al ser totalmente sin estado y ademaacutes implican tenerlos datos bajo un mayor control
Para la orquestacioacuten de contenedores se va a usar el entorno Marathondesarrollado tambieacuten por Mesosphere Eacuteste se puede usar a traveacutes de una interfazgraacutefica la interfaz de liacutenea de comandos (en lo que sigue CLI por sus siglas eningleacutes) de DCOS o con su API HTTP
Primero se han publicado la imaacutegenes de los contenedores que encapsulanla interfaz web y la api de la aplicacioacuten en el repositorio puacuteblico DockerHub
Los despliegues en este entorno se describen mediante ficheros JSON en losque se detalla entre otras opciones la imagen del contenedor los puertos a usar
30
los recursos que debe ocupar en un nodo o las instrucciones de monitorizacioacuten
Para el servicio de descubrimiento DCOS ofrece la posibilidad de asignardirecciones IP virtuales (VIP por sus siglas en ingleacutes) a tareas que se compartenen todos los nodos DCOS lleva integrado un balanceador de carga a nivel TCP(el componente denominado Minuteman) que balancea entre las direccionesvirtuales de las tareas y todas las instancias de eacutestas a lo largo del cluster Estoes necesario por dos motivos equilibrar la carga de los equipos con el fin deevitar un punto de uacutenico fallo mediante redundancia y evitar la contienda dedirecciones al ejecutar las tareas en puertos aleatorios
Este balanceador de carga estaacute basado en el trabajo de Michael Mitzenma-cher The Power of Two Choices in Randomized Load Balancing18 A grandesrasgos el algoritmo mantiene una media moacutevil exponencial de latencias paracada destino (backend) ademaacutes de las caiacutedas consecutivas Si un destino noresponde a una negociacioacuten en tres pasos (three way handshake) de forma con-secutiva en un periodo inferior a 5 ms se considera caiacutedo El algoritmo iterasobre los destinos disponibles en base a su histoacuterico de fallos y escoge dos deforma aleatoria de los cuales coge el de mejor meacutetrica
Las direcciones virtuales soacutelo se pueden resolver dentro del cluster porello para implementar la interfaz puacuteblica de la aplicacioacuten esto es el balancea-dor de carga de la interfaz web usaremos un paquete de DCOS denominadomarathon-lb un balanceador basado en HAProxy y adaptado por MesosphereEn este caso equilibra la carga de todas instancias de las tareas ejecutadas porel entorno Marathon por sus etiquetas y permite ademaacutes definir como puntode entrada muacuteltiples hosts virtuales definidos por sus nombres completos dedominio (FQDN por sus siglas en ingleacutes) en nuestro caso la interfaz puacuteblicadel balanceador de Azure para los agentes
Por motivos de seguridad todas las tareas se ejecutan en los agentes privadoses decir los que son exclusivamente accesibles desde la red interna Por su partemarathon-lb se ejecuta en el agente puacuteblico que cuenta con IP puacuteblica y lospuertos 80 (HTTP) y 8080 abiertos de forma que la aplicacioacuten sea accesibledesde Internet Esto es posible debido a que Apache Mesos permite reservarrecursos mediante roles asignados a nodos para un uso especiacutefico De esta formala arquitectura vista desde la aplicacioacuten quedariacutea como en la figura 19
18httpswwweecsharvardedu~michaelmpostscriptstpds2001pdf
31
Figura 19 Arquitectura de la aplicacioacuten web en DCOS
Ejecucioacuten
A la hora de desplegar la aplicacioacuten DCOS puede gestionarse medianteuna interfaz graacutefica o una interfaz de liacutenea de comandos La primera se accedea traveacutes de un navegador web en el puerto 80 (HTTP) y permite instalar losentornos disponibles observar el estado de los nodos y las tareas que se estaacutenejecutando y los ficheros de registros que eacutestas generan
La CLI permite el control desde un nodo o una maacutequina remota (suponiendoque los maestros tienen IP puacuteblica y el puerto 80 abierto) ya que DCOS tieneun sistema de autorizacioacuten que permite tener una interfaz puacuteblica con ciertasgarantiacuteas de seguridad
Por su parte cada entorno de trabajo puede ser controlado por la CLI peroademaacutes cuenta con sus propias interfaces Marathon expone una API HTTPen el puerto 8080 de la direccioacuten puacuteblica de los maestros del cluster asiacute comootra interfaz graacutefica Para desplegar un contenedor se podriacutea usar la CLI
$ dcos marathon app add lt f i l e j songt
O la API HTTP
$ cu r l minusX POST http lt ip_maestro gt8080v2apps minusd ltf i l e jsongt minusH Contentminustype app l i c a t i o n j son
32
612 Nomad
La arquitectura de Nomad es maacutes sencilla ya que solo requiere de un ficheroejecutable en todos los nodos para funcionar Si DCOS es la base de instala-cioacuten de entornos de terceros Nomad integra todas las funcionalidades baacutesicasesto es gestor de recursos planificador y ejecutor en los nodos cliente Estaherramienta cuenta con un menor tiempo de desarrollo y en el momento deescribir este documento cuenta exclusivamente con los siguientes controladoresen comparacioacuten con los entornos de DCOS
Motor Docker es decir funcioacuten de orquestacioacuten de contenedores
Ejecucioacuten de archivos binarios como comandos de Shell
Ejecucioacuten de aplicaciones Java
Virtualizacioacuten de maacutequinas mediante tecnologiacutea QEMU
Todos ellos necesitan que la tecnologiacutea subyacente esteacute instalada en las maacute-quinas clientes (Docker Java QEMU) Actualmente no permite el registro decontroladores por parte de terceros aunque estaacute planificado en un futuro ofreceruna interfaz para su desarrollo
Nomad no cuenta con el servicio de descubrimiento sin embargo puede inte-grarse con la herramienta Consul desarrollada por la misma empresa Por otrolado para el balanceo de carga usaremos un contenedor Docker con HAProxyuna herramienta de coacutedigo abierto que ofrece tanto servicios de proxy como debalanceador y cuyos ficheros de configuracioacuten completaremos con el proyectoConsul Template19
Consul
Consul sigue la misma arquitectura que Nomad es decir un nodo servidorque orquesta un conjunto de maacutequinas clientes y permite a los procesos que seejecutan en los equipos definirlos como servicios ofreciendo diversas caracteriacutes-ticas entorno a estos de los cuales vamos a usar dos
Descubrimiento de servicio Las maacutequinas clientes publican en el cataacutelogode servicios las tareas en ejecucioacuten y Consul les asigna nombres de dominioaccesibles por todos los miembros del cluster a traveacutes de la interfaz DNSincluida en esta herramientaConsul se integra con Nomad de forma que todas las tareas que se ejecu-ten en la segunda son automaacuteticamente publicados como servicios de laprimera de esta manera no hace falta conocer la direccioacuten de la maacutequinacliente donde se esteacute ejecutando el proceso ya que se puede acceder a eacutela traveacutes de su nombre de dominio de forma transparente Por ejemplo si
19[httpsgithubcomhashicorpconsul-template]
33
ejecutamos una tarea con ID web en el puerto 8080 se puede acceder aella en la direccioacuten webserviceconsul8080Para que las direcciones propias de Consul las resuelva su propio DNS y noel que esteacute asignado por defecto en la maacutequina usaremos la herramientadnsmasq20 que permite especificar la direccioacuten de un servidor DNS paraconsultas de direcciones especiacuteficas
Monitorizacioacuten Permite realizar comprobaciones del servicio y seguir su esta-do Aprovecharemos esta funcionalidad tanto para definir el propio procesode Nomad como servicio de Consul como las tareas desplegadas
HAProxy + Consul Template
HAProxy es una solucioacuten versaacutetil de coacutedigo abierto que ofrece solucionesde balanceo de carga y proxy Existen otras herramientas en el mercado comoNGINX o ldirectord sin embargo HAProxy suponiacutea una solucioacuten sencilla deconfigurar para mostrar el caso de uso
El uso de estas herramientas se debe a dos motivos para que no existacontienda con respecto a los puertos de los clientes usados por las tareas eacutestos sevan a asignar de forma dinaacutemica lo que en principio implicariacutea que la aplicacioacutendeberiacutea realizar consultas DNS de tipo SRV (que incluye puertos) a la interfazde Consul y balancear la carga entre tareas por redundancia y capacidad
Como la direccioacuten IP y puerto son variables cada vez que las tareas seactualicen o se reasignen es necesario volver a configurar HAProxy de formamanual Por ello HashiCorp ha desarrollado un programa denominado Con-sul Template que realiza peticiones sucesivas a la interfaz HTTP de Consul delas direcciones fiacutesicas de un servicio y reinicia automaacuteticamente el proceso deHAProxy Asiacute definiendo estas tareas como servicios Consul podremos tantomonitorizarlas como escalar las tareas dinaacutemicamente sin necesidad de cambiarel balanceador A partir del contenedor Docker oficial de HAProxy se ha desa-rrollado otro con la configuracioacuten baacutesica y con Consul Template para desplegarlocomo una tarea en Nomad
Despliegue
Se ha usado el mismo coacutedigo que en el apartado anterior con la persistenciaen el servicio de almacenamiento de Azure Desde la perspectiva del hardwarese implementaraacute la misma infraestructura que en el caso de DCOS (figura 18)estos es definiremos dos tipos de maacutequinas clientes un agente que se conectaraacutecon el balanceador de carga con nombre de dominio puacuteblico y donde se desple-garaacute el balanceador de carga de la vista web y agentes privados no accesiblesdesde fuera del cluster y donde se ejecutaraacuten el resto de tareas en la red inter-na La principal diferencia radica en las tareas que ejecutan HAproxy y ConsulTemplate que sustituye a las direcciones IP virtuales que ofrece DCOS
20httpwwwthekelleysorgukdnsmasqdochtml
34
Figura 20 Despliegue en Azure de Nomad+Consul
Cabe matizar que los balanceadores basados en HAProxy se implementanpor necesidad de la aplicacioacuten para el descubrimiento del servicio a diferenciade los de Azure que se implementan por motivos de seguridad y escalabilidaddel cluster en siacute
Configuracioacuten Nomad
Los ficheros de configuracioacuten de las maacutequinas maacutester y cliente son similaresy comparten la mayoriacutea de las opciones como por ejemplo el nombre del nodoo la interfaz de red donde escucha Nomad las peticiones Sus opciones son engeneral auto-explicativas sin embargo existen dos detalles que matizar
El proceso de Nomad escucha las peticiones tanto de los protocolos deconsenso como del usuario a traveacutes de una interfaz de red que se debeindicar en el fichero de configuracioacuten
En el caso de los clientes se deben indicar las direcciones de los servidoresdel cluster sin embargo se trata de un sistema dinaacutemico en el que losnodos pueden sufrir errores y cambiar de direccioacuten Por ello se ha definidoNomad como un servicio de Consul y asiacute poder definir la direccioacuten de losservidores como un nombre de dominio no por su direccioacuten fiacutesica que elservidor DNS de Consul se encargaraacute de resolver
Por defecto Nomad usa los siguientes puertos
API HTTP 4646 Peticiones HTTP y recepcioacuten de oacuterdenes mediante laliacutenea de comandos
RPC 4647 Protocolo de consenso entre los nodos del cluster
Serf 4648 Protocolo de gossip entre los servidores de los centros de datosgobernados por Nomad
35
Los dos uacuteltimos deben ser interfaces alcanzables por otros nodos sin embargo laAPI HTTP por motivos de seguridad deberiacutea ser local ya que en caso contrariocualquier persona con acceso a ella tiene el control sobre la herramienta Eacutestasolo deberiacutea estar accesible en un servidor o gestionarlo mediante una terminalSSH por ejemplo En este trabajo al ser una prueba de concepto se ha abiertoen todos los nodos
Trabajos de Nomad
Las tareas se detallan en ficheros con formato HashiCorp Configuration Lan-guage un derivado del formato JSON creado por la empresa que le da nombrecompatible con eacuteste y que permite comentarios
En estos ficheros se puede definir
La regioacuten y el centro de datos donde se ejecutaraacute (Nomad permite lagestioacuten de centros de datos geograacuteficamente distribuidos en regiones)
La poliacutetica de actualizacioacuten de la tarea
Grupo de tareas esto es que se ejecutaraacuten en el mismo nodo
El nuacutemero de grupos a ejecutarescalar asiacute como los liacutemite que debencumplir los nodos asignados
La poliacutetica de reinicio ante fallo o error
Tareas El controlador su configuracioacuten los paraacutemetros del servicio aso-ciado a registrar en Consul asiacute como los recursos que consume (puertosmemoria)
En nuestro caso usamos sobre todo el controlador Docker esto eso orques-tacioacuten de contenedores en los nodos clientes y tres de sus opciones
Imagen del contenedor Se han subido todas las imaacutegenes del proyecto a Doc-ker Hub donde por defecto se busca la imagen
Puertos Los puertos a usar por el contenedor que pueden ser estaacuteticos asigna-dos por el usuario o dinaacutemicos siendo Nomad el que se encarga de mapearun puerto libre del nodo cliente al expuesto por el contenedor
Servidores DNS Como usamos la interfaz DNS de Consul como descubri-miento de servicio se debe configurar el contenedor para que use cualquiernodo del cluster como servidor DNS
Configuracioacuten Consul
Al ser desarrolladas por la misma empresa los ficheros de configuracioacuten deConsul y Nomad comparten muchas opciones Consul tambieacuten acepta peticionesa traveacutes de una interfaz de red siendo los puertos usados por defecto
36
RPC 8300 8400 Maneja la peticiones del resto de nodos y usuarios
Serf 8301 8302 Protocolo gossip
HTTP API 8500
HTTPS API Desactivada por defecto
Interfaz DNS 8600
Se debe asignar a los protocolos internos del cluster esto es RPC y Serf unainterfaz alcanzable por los nodos y por el contrarioasignar a los dos uacuteltimos ala interfaz de loopback por motivos de seguridad
Cabe destacar que Consul tambieacuten cuenta con una interfaz graacutefica que per-mite ver el estado de los equipos y los servicios registrados y que se encuentra enel mismo puerto que la API HTTP en la direccioacuten httpIP_EQUIPO8500ui
Ejecucioacuten
Tanto Nomad como Consul requieren de la ejecucioacuten de un fichero en todoslos nodos integrantes del cluster Como prueba de concepto se ha decidido usardos servidores para ambos aunque cabe matizar que es un nuacutemero ineficienteya que la caiacuteda de uno de ellos supondriacutea la peacuterdida del cuoacuterum y por tantodel consenso del cluster
En primer lugar se arrancan los servidores que son los encargados de ejecu-tar el protocolo de consenso y gestionar el cluster y a continuacioacuten los clientesque no tienen praacutecticamente estado y dependen de los servidores
En el caso de Consul se debe indicar el directorio donde se guardan losficheros que describen los servicios asiacute como el archivo que especifica el resto delas opciones
1 Se inicia el primer servidor en uno de los equipos
$ consu l agent minuscon f i gminusd i r e t c consu l d s e r v i c e s minuscon f i gminus f i l e consu l_server j son
2 Los siguientes equipos deben unirse al anterior por lo que antildeadimos elargumento join con la direccioacuten del primer servidor Para el caso de otrosservidores
$ consu l agent minuscon f i gminusd i r e t c consu l d s e r v i c e s minuscon f i gminus f i l e consu l_server j son minus j o i n ltIP_servidor1gt
37
Una vez los servidores han alcanzado el consenso y elegido un liacuteder en losclientes
$ consu l agent minuscon f i gminusd i r e t c consu l d s e r v i c e s minuscon f i gminus f i l e c on su l_c l i en t j son minus j o i n ltIP_cualquierServ idorgt
El proceso para iniciar Nomad es igual y los comandos similares sin embargoya no es necesario indicar una direccioacuten IP fija en los equipos sino el nombre dedominio del servicio de Nomad registrado por Consul En el primer servidor
$ nomad agent minusc on f i g nomad_server j son
Y el resto de equipos (con su fichero de configuracioacuten correspondiente)$ nomad agent minusc on f i g nomad_server j son minus j o i n nomad s e r v i c e consu l
Por uacuteltimo para desplegar la aplicacioacuten web se han escrito tres ficherosque detallan las tareas de la interfaz web API y los balanceadores de cargaMediante la CLI
$ nomad run minusaddress=http lt ip_c lus te r gt4646 lt f i l e hclgt
O mediante la API HTTP de Nomad$ cu r l minusX POST minusd ltf i l e hclgthttp lt ip_c lus te r gt4646 jobltjob_namegt
Ansible
Como se puede comprobar con el aumento del nuacutemero de equipos pasa aser inviable manejar todos los nodos a traveacutes de terminal Ademaacutes como seha comentado con anterioridad Nomad requiere que en los nodos clientes es-teacuten instalados las herramientas que soporten las tareas por ejemplo el motorde Docker Por ello para facilitar tanto el arranque como la instalacioacuten de lasdependencias vamos a usar Ansible una herramienta de coacutedigo abierto desarro-llada en Python que permite gestionar configuraciones aprovisionar recursosdespliegue de aplicaciones de forma automaacutetica
A grandes rasgos esta herramienta funciona mediante ficheros en formatoYAML denominados play-books que describen un conjunto de pasos a ejecutaren una lista de equipos remotos Estos pasos son ejecutados por moacutedulos inde-pendientes a traveacutes de SSH es decir en cualquier ordenador con conexioacuten a los
38
hosts dado su contrasentildea o clave puacuteblica puede arrancar el script y realizariacutealos pasos de forma remota gestionando el cluster desde un solo equipo
Se han desarrollado guiones para lo siguiente
Descarga de los binarios de Nomad y Consul en todos los nodos copiade los ficheros de configuracioacuten baacutesicos y modificarlos de acuerdo a cadanodo (nombre del equipo direccioacuten IP)
Instalacioacuten de las dependencias
Arranque de Nomad y Consul
Ansible extiende su funcionalidad a traveacutes de moacutedulos independientes que per-miten por ejemplo instalar paquetes mediante herramientas de gestioacuten de pa-quetes (APT yum) aprovisionar automaacuteticamente maacutequinas virtuales de Ama-zon EC2
Algunas opciones de los ficheros de configuracioacuten de Nomad y Consul sondependientes del nodo particular por ejemplo la interfaz de red Para estetrabajo se ha realizado un moacutedulo para modificar los ficheros de configuracioacutende forma automaacutetica En el repositorio del proyecto se encuentra una carpetadonde se encuentran todos los ficheros necesarios para desplegar un clustertotalmente funcional solo requiere de una liacutenea de terminal con Ansible
$ ans ib l eminusplaybook minus i hos t s minusk ltssh_passgt minusu ltnode_usergt s i t e yml
39
62 Servicio de integracioacuten continua
Se ha implementado un sistema de integracioacuten continua que permite ejecu-tar tareas de compilacioacuten y pruebas de forma distribuida aumentando asiacute elrendimiento de los equipos En primer lugar se detallaraacute los motivos por los quepuede resultar beneficioso para las empresas una implementacioacuten de este tipo alo que seguiraacute los detalles del despliegue
621 DevOps
Metodologiacutea que defiende la comunicacioacuten y colaboracioacuten entre desarrolla-dores de software y los profesionales de operaciones a lo largo de todo el ciclo devida de una aplicacioacuten Estaacute muy relacionado con el desarrollo aacutegil de softwareesto es un enfoque para los proyectos que defiende el desarrollo iterativo e in-cremental donde los requisitos y soluciones evolucionan con el tiempo seguacuten lanecesidad del proyecto DevOps extiende esta filosofiacutea a todas los componentesde un servicio incluyendo sistemas y operaciones
Se trata de un concepto que cada organizacioacuten o empresa adapta a suspropias necesidades y procesos de negocio en este proyecto nos vamos a centraren la integracioacuten continua una praacutectica fundamental tanto del desarrollo aacutegilcomo de esta filosofiacutea
622 Integracioacuten Continua
Se define como una praacutectica de desarrollo software donde los miembros delequipo ponen en comuacuten su trabajo frecuentemente al menos una vez al diacutea21Cada integracioacuten se verifica con una compilacioacuten automaacutetica que incluye laejecucioacuten de pruebas para detectar errores de integracioacuten tan pronto como seaposible
Desde el punto de vista operativo esto supone automatizar la configuracioacutende equipos o el despliegue de maacutequinas virtuales donde compilar el proyecto yejecutar las pruebas y posteriormente eliminarlas Este flujo de trabajo se vebeneficiado en entornos distribuidos ya que el objetivo del desarrollador es com-probar el resultado de las pruebas raacutepidamente sin preocuparse del despliegueo los propios equipos
Para esta prueba de concepto vamos a usar Jenkins un servidor de integra-cioacuten continua escrito en Java que nos permite definir trabajos que contendraacutenla descripcioacuten tanto del entorno como su ejecucioacuten
Este sigue una estructura maestro-esclavo muy similar al de los gestores declusters usados en este proyecto el maestro contiene toda la loacutegica del servicio
21httpmartinfowlercomarticlescontinuousIntegrationhtml
40
trabajos autenticacioacuten y los esclavos son los encargados de la ejecucioacuten ensiacute Jenkins tiene varias viacuteas para aprovisionar los uacuteltimos
Mediante SSH
Interfaz graacutefica
Desarrollar un script propio
Ejecucioacuten de un fichero java
La ventaja de usar planificadores es que el despliegue de esclavos es dinaacutemicoes decir no tener una maacutequina especiacuteficamente configurada para ello DCOS yNomad se encargaraacuten de configurar estos despliegues en sus maacutequinas y poste-riormente eliminarlos Para ello se ha usado la uacuteltima opcioacuten definiendo tareasque descarguen el fichero java Con todo ello se consigue un entorno de inte-gracioacuten continua eficiente que ademaacutes permite la ejecucioacuten de otros servicios deforma independiente
Jenkins permite la creacioacuten de plugins que extienden sus funcionalidadesTanto Nomad22 como Apache Mesos cuentan con uno que permite su integra-cioacuten
Para esta prueba se va a usar el mismo proyecto que para el caso de usode orquestacioacuten de contenedores la aplicacioacuten web al que se le ha antildeadido untest para comprobar que se conecta correctamente a la base de datos medianteMocha un framework de Nodejs Por otro lado se antildeade el plugin de git ya queel coacutedigo se obtiene de GitHub el repositorio remoto de control de versiones delproyecto
El proceso general de ejecucioacuten seriacutea como sigue
1 Se ejecuta el maestro de Jenkins como tarea Docker partiendo de la imagenoficial
2 Al arrancar un trabajo se manda una tarea a los planificadores que laasignaraacuten a un nodo cliente Esta tarea consiste en la descarga del ficherode configuracioacuten Java y arrancarlo configurando el equipo como un clientede Jenkins temporalmente
3 Jenkins ejecuta el trabajo en el nuevo cliente en este caso iniciar la apli-cacioacuten web iniciar las pruebas y generar un informe
4 Se elimina el cliente
A continuacioacuten se detallan los matices de cada herramienta a la hora de imple-mentar este servicio
22Desarrollado por Ivo Verberk httpwwwivoverberknl
41
623 Jenkins con Nomad
El plugin permite la ejecucioacuten del fichero Java mediante dos controladorescontenedores Docker y Java En este proyecto nos hemos decantado por el pri-mero ya que nos ahorra instalar la maacutequina virtual de java en todos los nodoscliente Por ello se ha construido un contenedor base con Java para la ejecucioacutendel fichero de configuracioacuten y Nodejs para lanzar la aplicacioacuten web
El plugin se configura con la direccioacuten IP del cluster y el contenedor queejecuta el esclavo Jenkins Por su parte el trabajo en Jenkins se define conel repositorio en GitHub donde se aloja el coacutedigo del proyecto a probar y loscomandos a ejecutar en este caso npm update y npm test
624 Jenkins con DCOS
En el caso de DCOS su sistema de paquetes incluye Jenkins por lo queal instalarlo ya se tiene la configuracioacuten de Mesos totalmente funcional Sinembargo para ejecutar la aplicacioacuten en particular y las pruebas se requiere deNodejs en los equipos esclavos por ello debemos antildeadir un plugin de Jenkinsque permite instalar este entorno antes de ejecutar el trabajo Una vez hechoesto soacutelo queda definir la tarea igual que en el caso anterior
Cabe destacar que Mesosphere tambieacuten ha desarrollado un plugin que per-mite hacer despliegues en Marathon de tal manera que permitiriacutea con cadacommit del coacutedigo compilar la imagen del contenedor Docker y desplegarlaautomaacuteticamente aunque en este proyecto no se ha hecho pruebas de esta fun-cionalidad
42
7 Escalando la infraestructura
Uno de los factores clave que se busca a la hora de implementar sistemasdistribuidos es el poder escalar la infraestructura de forma maacutes sencilla estoes detectar que las maacutequinas estaacuten alcanzando el liacutemite de su capacidad yaumentar eacutesta ya sea mejorando sus caracteriacutesticas teacutecnicas o antildeadiendo maacutesnodos al cluster
El coacutedigo y todos los ficheros de configuracioacuten de esta seccioacuten tambieacuten sepueden encontrar en el repositorio del proyecto en GitHub23
71 Disentildeo
Microsoft Azure permite organizar los servicios cloud de forma loacutegica a traveacutesde grupos de recursos y asiacute poder crear o eliminar eacutestos en conjunto parauna aplicacioacuten determinada (por ejemplo una aplicacioacuten web suele requerir demaacutequinas virtuales bases de datos almacenamiento) Ademaacutes dispone dela opcioacuten de crear plantillas en formato JSON que permite al desarrolladordefinir los recursos y su interrelacioacuten para desplegar de forma automaacutetica unainfraestructura TI en la nube
Azure tambieacuten ofrece la posibilidad de monitorizar el estado de las maacutequinasvirtuales a traveacutes de extensiones lo que permite configurar el escalado automaacute-tico al alcanzar cierto liacutemite definido por el operador Eacutesta es a priori la formaen que deberiacutea implementarse hablando en teacuterminos de eficiencia sin embargoesta aproximacioacuten es totalmente dependiente de la plataforma es decir no sepuede extrapolar a otro proveedor o sobre recursos propios sin realizar un nue-vo disentildeo En este proyecto las tareas que son ejecutadas por estos equipos notienen estado ya que todo lo relativo a la persistencia lo hemos asignado fueradel cluster esto permite escalar la plataforma a traveacutes de otra aproximaciones
Las plantillas aceptan una serie de variables a indicar por el usuario entreotras los conjuntos de escala para definir los nodos aceptan una variable quedefine el nuacutemero de maacutequinas que los componen Por otro lado Azure ofreceuna API REST y kits de desarrollo software (SDK por sus siglas en ingleacutes) quepermiten su despliegue de forma programaacutetica Aprovechando estas facilidadesen este proyecto se va a aproximar la escalabilidad con el sucesivo desplieguede la infraestructura de forma automaacutetica se monitorizan los equipos y si sedetecta una maacutequina excesivamente cargada se aumenta el nuacutemero de equiposen la plantilla y se vuelve a desplegar
23httpsgithubcomAntonioAlfrzCloud-Orchestrators
43
En este proyecto se han disentildeado las plantillas para desplegar la arquitec-tura necesaria tanto de Nomad como de DCOS En el caso de la primera eldespliegue es maacutes descriptivo ya que incluye maacutequinas virtuales grupos de se-guridad redes En el caso de DCOS Azure cuenta con un servicio especiacuteficopara clusters gobernados por DCOS denominado Azure Container Service queincluye los componentes necesarios y la instalacioacuten ya realizada
72 Implementacioacuten
En primer lugar para monitorizar el estado de los equipos se va a usar laherramienta Nagios un sistema que permite controlar el estado del hardwarey los servicios de un equipo Se trata de una herramienta muy completa de laque se va a usar su capacidad para ejecutar comandos (plugins) en los nodospara detectar picos de carga generar alertas y ejecutar programas para estoseventos
Se ha desplegado una maacutequina virtual con esta herramienta en ambos siste-mas y se ha instalado una extensioacuten de Nagios (Nagios Remote Plugin Executor)en todos los nodos que permite ejecutar comprobaciones remotamente en con-creto para esta prueba de concepto medir el nivel de saturacioacuten de la unidadcentral de procesamiento (CPU por sus siglas del ingleacutes) Cuando sucede uncambio de estado de una maacutequina esto es cuando este paraacutemetro supera el liacutemi-te definido por el operador Nagios permite actuar en consecuencia ejecutandoprogramas por ello se ha desarrollado un script que ejecuta lo siguiente
Un programa desarrollado en Python con el SDK de Azure que modificalas plantillas y despliega los recursos
Un guioacuten de Ansible para instalar todos los componentes necesarios en lasnuevas maacutequinas y arrancar de nuevo el cluster y las aplicaciones
44
8 Resultados y conclusiones
En este uacuteltimo apartado se da una visioacuten global del proyecto asiacute como a lasconclusiones maacutes importantes a las que se ha llegado y posibles temas futurosde desarrollo
81 Comparacioacuten
Ambas herramientas ofrecen las funcionalidades para gestionar los recursoseficientemente ofreciendo a los desarrolladores una plataforma donde desplegarsus aplicaciones de forma distribuida independientemente de los equipos fiacutesicosy el hardware que las soporten
DCOS es una herramienta que en un comienzo fue privativa pero cuyos res-ponsables la empresa Mesosphere decidieron publicar una versioacuten de coacutedigoEacutesta nos permite gestionar un cluster de una forma sencilla y usable ademaacutes decomplementarlo con otras herramientas como el balanceador de carga integradoo la autenticacioacuten de usuarios ademaacutes estaacute basada en Apache Mesos un pro-yecto de relativa madurez y con el soporte de la Apache Software FoundationDe forma resumida DCOS ofrece muchas posibilidades y servicios a cambiode una arquitectura e instalacioacuten maacutes compleja
Por su parte HashiCorp con menor tiempo de desarrollo ha conseguidouna herramienta muy sencilla de desplegar que ademaacutes cumple con todas lasfuncionalidades baacutesicas ejecutando un simple binario en cada nodo se puededesplegar un gestor de clusters totalmente funcional Sin embargo no cuentacon todas las posibilidades de Mesos (Nomad cuenta con menos controladoresque entornos posibles de Mesos) ni con los antildeadidos de DCOS lo que implicael uso de otras herramientas para complementar el servicio (Consul HAProxy)
De entre las dificultades encontradas al usar estas herramientas y desplegaraplicaciones sobre ellas se puede destacar la depuracioacuten en ocasiones se desco-noce si un error viene de la propia herramienta de la aplicacioacuten desplegada o delequipo fiacutesico si no se cuenta con un sistema de procesamiento de registro unose puede encontrar con muacuteltiples terminales abiertas inspeccionando numerososficheros de registro buscando posibles errores Ademaacutes no dejan de ser solucio-nes que para usar eficientemente se debe conocer parte de su funcionamientoy sintaxis a la hora de describir la tareas lo que supone un esfuerzo antildeadido yaque cada una tiene sus particularidades y liacutemites
45
82 Conclusiones
En una sociedad cada vez maacutes digital las empresas deben adaptarse a unmercado cuya demanda de contenido no deja de crecer Las nuevas arquitecturascomo microservicios asiacute como la gran cantidad de datos generada implica queuna mejor gestioacuten de los recursos y la rapidez para desplegar o escalar solucionesdando valor al cliente lo maacutes raacutepido posible es uno de los objetivos de todas lasempresas de base tecnoloacutegica
Las ventajas que ofrecen los planificadores con aplicaciones distribuidas sonnumerosas sin ir maacutes lejos empresas tan punteras como Google llevan maacutesde 10 antildeos orquestando contenedores24 Por un lado permiten aumentar elrendimiento de los equipos propios y por otro implementar un servicio comoplataforma para despliegues distribuidos sobre cualquier conjunto hardware deesta forma se provee un servicio similar al de la nube puacuteblica pero con laprincipal diferencia de que se elimina la independencia con el proveedor (vendorlock-in) esto es las aplicaciones no tienen limitaciones impuestas por eacuteste talescomo lenguaje de programacioacuten o herramientas y permite despliegues hiacutebridosentre recursos propios y la nube
83 Objetivos conseguidos
Implementacioacuten de los planificadores propuestos en la nube Se ha en-tendido y detallado el funcionamiento de estas herramientas y se hanimplementado en el servicio de infraestructura de Microsoft Azure
Despliegue de aplicaciones y servicios distribuidos Servicios que se usanactualmente en la industria del desarrollo software asiacute como una aplica-cioacuten web con una arquitectura moderna han sido desplegados de formadistribuida en los equipos cumpliendo con la funcionalidad esperada ade-maacutes de consiguiendo una alta disponibilidad
Aproximacioacuten de arquitectura escalable Se ha hecho una aproximacioacutende infraestructura escalable de forma que sea parcialmente extrapolable aotros proveedores
24httpwwwnextplatformcom20160322decade-container-control-google
46
84 Liacuteneas de investigacioacuten
Siguiendo con la materia de este proyecto se presentan posibles liacuteneas deinvestigacioacuten
Analizar el despliegue con estas herramientas de aplicaciones de Big Datay comparar la eficiencia con respecto a soluciones especializadas
Analizar el rendimiento de los algoritmos de planificacioacuten antes pruebasde estreacutes y situaciones de alta contienda
Comparar el uso de estas herramientas con las praacutecticas actuales de laindustria o implementacioacuten en un sistema de produccioacuten real
47
Referencias
[1] LA Barroso y U Houmllzle laquoThe Datacenter as a Computer An Introduc-tion to the Design of Warehouse-Scale Machinesraquo En Morgan amp ClaypoolPublishers ()
[2] Systems Research Group ndash NetOS (University of Cambridge) The evolu-tion of cluster scheduler architectures 2016 url httpswwwclcamacukresearchsrgnetoscamsasblog2016-03-09-scheduler-architectureshtml
[3] A Das I Gupta y A Motivala SWIM Scalable Weakly-consistent Infection-style Process Group Membership Protocol Inf teacutec Dept of ComputerScience Cornell University url https www cs cornell edu ~asdasresearchdsn02-swimpdf
[4] D Dubhashi y A Das Mastering Mesos PACKT Publishing mayo de2016
[5] The Apache Software Foundation Apache Mesos documentation urlhttpsmesosapacheorg
[6] David Greenberg Building Applications on Mesos OrsquoReilly Media 2016[7] Armand Grillet Comparison of Container Schedulers Inf teacutec Technische
Universitaumlt Berlin[8] HashiCorp Consul documentation url httpswwwconsulio[9] HashiCorp Nomad documentation url httpsdcosio[10] Dan C Marinescu Cloud computing theory and practice Morgan Kauf-
mann 2013[11] Mesosphere DCOS documentation url httpswwwnomadproject
io[12] Microsoft Azure documentation url httpsazuremicrosoftcom
es-esdocumentation[13] D Ongaro y J Ousterhout In Search of an Understandable Consensus
Algorithm Inf teacutec Stanford University url httpsraftgithubioraftpdf
[14] Fei Teng laquoRessource allocation and schelduling models for cloud compu-tingraquo Tesis de mtriacutea Ecole Centrale Paris 2011
[15] A Williams y col Automation and Orchestration with Docker and Contai-ners A Comprehensive Overview of the Docker and Container Ecosystem3 The New Stack 2016
48
- Resumen
- Summary
- Iacutendice de figuras
- Introduccioacuten y objetivos
-
- Contexto
- Objetivos
- Estructura del documento
-
- Cloud Computing
- Nuevas cargas de trabajo
- Gestioacuten de recursos Planificadores
-
- Sistemas distribuidos
-
- Clasificacioacuten
-
- Herramientas
-
- DCOS
-
- Apache Mesos
- Ejemplos de uso
-
- Nomad
-
- Protocolo de consenso Raft
- Protocolo gossip SWIM
- Planificacioacuten
-
- Casos de uso y despliegue
-
- Aplicacioacuten Web
-
- DCOS
- Nomad
-
- Servicio de integracioacuten continua
-
- DevOps
- Integracioacuten Continua
- Jenkins con Nomad
- Jenkins con DCOS
-
- Escalando la infraestructura
-
- Disentildeo
- Implementacioacuten
-
- Resultados y conclusiones
-
- Comparacioacuten
- Conclusiones
- Objetivos conseguidos
- Liacuteneas de investigacioacuten
-
3 Nuevas cargas de trabajo
Las organizaciones que cuentan con sus propios infraestructuras TI han co-menzado a adoptar un enfoque de nube privada para gestionar las tareas ofunciones informaacuteticas sobre las que se sustentan el negocio ya que una es-tructura virtualizada puede ofrecer ventajas con respecto a las adaptaciones decentros de datos tradicionales en los aacutembitos de rendimiento escalabilidad eincluso seguridad4
A su vez se han desarrollado nuevas tecnologiacuteas que suponen cargas detrabajo dinaacutemicas y con gran intensidad de consumo de datos para las empresasque se ven beneficiadas al desplegarlas en recursos virtualizados
Big data
Con la creciente aceptacioacuten de las tecnologiacuteas TIC por parte de la sociedadla cantidad de datos generados en la red es ingente Las profesionales de TI tienecomo objetivo extraer valor de eacutestos para por ejemplo prever las tendencias delmercado Sin embargo este incremento exponencial hace que su procesamientoy almacenamiento requiera de un sistema con gran escalabilidad dado el hechode que una sola maacutequina no puede proveer de la capacidad necesaria
Integracioacuten continua
Modelo informaacutetico que consiste en hacer integraciones automaacuteticas de unproyecto con cualquier cambio en el coacutedigo con el objetivo de detectar fallosde forma temprana Esto implica la compilacioacuten del coacutedigo y su ejecucioacuten enun entorno de pruebas automaacuteticamente un proceso que mediante tecnologiacuteasde virtualizacioacuten permiten simular entornos con eficiencia y rapidez Su imple-mentacioacuten en sistemas distribuidos permite tanto una mejor planificacioacuten comoun mejor rendimiento de los recursos
Arquitectura de microservicios
Enfoque para desarrollar aplicaciones software como un conjunto de serviciosautoacutenomos que se comunican entre siacute a diferencia de aproximaciones monoliacuteti-cas donde la loacutegica del servicio estaacute desarrollada como una unidad Un sistemadistribuido permite el despliegue de los componentes en distintas maacutequinas loque mejora tanto su escalabilidad como la tolerancia a fallos
4httpswwwakamaicomesesresourcespublic-private-cloudjsp
5
Docker
Proyecto de coacutedigo abierto que facilita y automatiza el despliegue de aplica-ciones al encapsular el entorno de trabajo en contenedores Linux una tecnologiacuteaque permite a un sistema fiacutesico ejecutar muacuteltiples instancias de sistemas opera-tivos aislados mediante entornos virtuales con sus propios espacios de procesosy redes pero compartiendo el nuacutecleo (kernel) con el equipo anfitrioacuten
En la figura 2 se compara la pila de una virtualizacioacuten tradicional con res-pecto a los contenedores no se simula el sistema operativo por lo que el procesoes mucho maacutes ligero
Docker se caracteriza por
Autosuficiencia Los contenedores cuentan con las libreriacuteas y configuracio-nes necesarias para ejecutarse de manera autoacutenoma al compartir el nuacutecleo
Portabilidad El hecho de que sean autosuficientes implica que es inde-pendiente del host es decir se puede desplegar en cualquier equipo quesoporte esta tecnologiacutea
Tamantildeo El peso de un contenedor es sustancialmente inferior a otrastecnologiacuteas de virtualizacioacuten
Figura 2 Arquitectura DockerFuente httpsdockercom
6
Los componentes fundamentales de esta herramienta son
Imaacutegenes Describen el entorno de base sobre el que ejecutar el contene-dor por ejemplo la imagen del sistema operativo Ubuntu Sobre eacutesta seconstruyen las aplicaciones particulares del usuario dando lugar a otraimagen
Contenedores Se crean a partir de las imaacutegenes y comprenden todo aquellonecesario para arrancar la aplicacioacuten decir su entorno de ejecucioacuten
bull Voluacutemenes Encargados de gestionar la persistencia de datos e inde-pendientes del ciclo de vida del contenedor
Registros Pueden ser puacuteblicos o privados y almacenan las imaacutegenes elregistro puacuteblico oficial de Docker es Docker Hub
Dadas estas caracteriacutesticas los profesionales TI estaacuten comenzando a adoptarDocker ya que facilita tanto los despliegues como el trabajo compartido en dis-tintos entornos Sin embargo esto requiere de un software que permita desplegarlos distintos contenedores de forma que puedan trabajar en conjunto procesoque se ha denominado orquestacioacuten de contenedores
7
4 Gestioacuten de recursos Planificadores
Para sacar el maacuteximo provecho a las tecnologiacuteas anteriormente descritaslo ideal es desplegarlas en sistemas distribuidos sin embargo esto aumenta lacomplejidad del propio despliegue asiacute como la necesidad de software especiali-zado para ello Se necesitan algoritmos de planificacioacuten que permitan obtener elmaacuteximo rendimiento de los recursos por un lado y dar ciertas garantiacuteas de quetodas las tareas y procesos se van a ejecuta por otro
41 Sistemas distribuidos
En primer lugar se definen los sistemas distribuidos o clusters como unconjunto de ordenadores conectados entre siacute cuyo objetivo es trabajar como unauacutenica instancia de gran capacidad5
Su clasificacioacuten variacutea de acuerdo a cada autor pero en general se puedendividir seguacuten su objetivo en alto rendimiento aquellos cuyo objetivos es proveerde gran capacidad de coacutemputo gracias al conjunto de los nodos y alta disponi-bilidad con los cuales se busca la fiabilidad del sistema mediante redundanciayo balanceo de carga
El intereacutes de este proyecto recae en los uacuteltimos ya que el objetivo es porun lado ofrecer al desarrollador un entorno donde desplegar sus aplicaciones deforma distribuida y por otro maximizar el rendimiento de los recursos
De forma general las caracteriacutesticas que se buscan son las siguientes
Elasticidad Adaptacioacuten a cargas dinaacutemicas de trabajo aumentando (o dis-minuyendo) recursos de manera automaacutetica de tal forma que la utilizacioacutensea lo maacutes cercana a la demanda
Disponibilidad Capacidad de un sistema para mantener el servicio fun-cional
Tolerancia a fallos Recuperacioacuten del servicio ante el fallo de un compo-nente
Balanceo de carga Compartir las tareas entre las diferentes maacutequinasredundadas evitando asiacute puntos de uacutenico fallo
5httpsenwikipediaorgwikiComputer_cluster
8
Los programas que se implementan en entornos distribuidos se caracterizanpor ejecutarse de forma concurrente en equipos independientes estar conectadospor una red que introduce fallos aleatorios y no compartir memoria ni reloj Estoimplica entre otras cosas que
Los nodos soacutelo tienen un acceso raacutepido a su memoria local por lo quecualquier informacioacuten relativa al estado global puede ser potencialmenteerroacutenea
Las maacutequinas pueden sufrir caiacutedas de forma aleatoria
El intercambio de informacioacuten puede fallar ya sea por error en transmisioacuteno por caiacuteda de los nodos
Estas dificultades se ponen de manifiesto en el teorema de CAP en cienciasde la computacioacuten el teorema de CAP que lanzado inicialmente como conjetu-ra en el antildeo 2000 por Eric Brewer (motivo por el cual al teorema se le conoceformalmente como teorema de Brewer) y posteriormente demostrado en el antildeo20026 establece que es imposible para un sistema de coacutemputo distribuido ga-rantizar simultaacuteneamente dos de las tres propiedades siguientes
Consistencia (Consistency) es decir que todos los nodos vean la mismainformacioacuten al mismo tiempo Se busca que un cambio en el sistema soacutelose ejecute satisfactoriamente si y soacutelo si se efectuacutea a todos las maacutequinasde tal forma que los datos entre ellos nunca difieren y la respuesta a unapeticioacuten sea la misma independientemente del nodo que la atienda
Disponibilidad (Availability) esto es la garantiacutea de que toda peticioacuten debeobtener una respuesta (servicio funcional) aunque exista inconsistenciaentre nodos
Tolerancia al particionado (Partition Tolerance) es decir que el sistemasiga funcionado a pesar de un fallo en la comunicacioacuten entre los equipos
Por todo lo expresado anteriormente conseguir un sistema distribuido capazde ofrecer procesamiento de forma transparente implica una arquitectura TIcompleja Se requieren de subsistemas y herramientas que permitan la cohesioacutenentre todos los nodos
Gestor de los recursos de las diferentes maacutequinas
Monitorizacioacuten tanto de los servicios activos como de la funcionalidad delsistema ademaacutes de poliacuteticas para recuperacioacuten de fallo
Protocolos de consenso que permitan a los nodos ser consistentes con elestado global del cluster
6urlhttpsgroupscsailmitedutdspapersGilbertBrewer2pdf
9
Herramientas de descubrimiento de servicios que permita la comunicacioacutenentre tareas distribuidas
Planificadores Encargados de distribuir las tareas y procesos en las dife-rentes maacutequinas asignaacutendole parte de su capacidad
Los planificadores del ingleacutes cluster schedulers son un componente funda-mental por lo que vamos a entrar un poco maacutes en detalle en ellos
Planificadores (Cluster Schedulers)
Es el software encargado de monitorizar los recursos usados por cada maacute-quina perteneciente a un cluster y distribuir la carga de trabajo entre ellas deacuerdo a un poliacutetica o reglas
Este tipo de herramientas comparten cierta terminologiacutea que es relevantedefinir
Tarea Unidad de trabajo computacional comprendida por una secuenciade instrucciones datos de entrada y recursos asociados Por ejemplo laejecucioacuten de un comando o el arranque de una base de datos
Nodo Cualquier maacutequina integrante de un cluster En una arquitecturamaestro-esclavo se definen dos roles
bull Cliente Agente Esclavo Aquellos ordenadores que se encargan deejecutar las tareas
bull Maestro Servidor Su objetivo es mantener el estado del cluster ygestionar sus recursos
411 Clasificacioacuten
A lo largo de los uacuteltimos antildeos se han desarrollado diferentes tipos de plani-ficadores[2]
Monoliacutetico
Un solo planificador que se encarga de distribuir todas las tareas entran-tes La mayoriacutea de los planificadores en computacioacuten de alto rendimiento asiacutecomo Borg desarrollado por Google son de este tipo En la figura 3 se pue-de observar de forma graacutefica el procedimiento siendo las cajas grises maacutequinaspertenecientes al cluster y los ciacuterculos las tareas a asignar
10
Figura 3 Planificador monoliacuteticoFuente httpswwwclcamacuk
Planificacioacuten de dos niveles
La mayoriacutea de los clusters ejecutan aplicaciones con distintas necesidadesdesde procesos casi instantaacuteneos hasta servicios persistenteslo que implica dis-tintas necesidades de recursos
Por ello la planificacioacuten a dos niveles distingue dos funciones la gestioacutende recursos (gestor) y la disposicioacuten de las tareas (planificador) Cada serviciotiene su propio planificador de tal manera que el gestor les ldquoofertardquo recursosde acuerdo a una poliacutetica y los planificadores se encargan de escoger la maacutesadecuada Esto permite que el proceso de distribucioacuten sea maacutes acorde con lasnecesidades de los diferentes servicios Apache Mesos que detallaremos maacutesadelante sigue este esquema
Como desventaja cabriacutea sentildealar que esta programacioacuten implica que los pla-nificadores pierden la vista general de la infraestructura y las tareas soacutelo puedenejecutarse con los recursos que les son ofrecidos lo que dificulta la implementa-cioacuten de prioridades de ejecucioacuten de tareas entre otras
Figura 4 Planificador de dos niveles
11
Planificacioacuten de estado compartido
Muacuteltiples reacuteplicas del estado del cluster se actualizan independientementepara cada planificador como se observa en la figura 5 cuando sucede un cambiode forma local el planificador se encarga de informar al resto
Ejemplo de este tipo son Omega la evolucioacuten de Borg por parte de GoogleMicrosoft Apollo y Nomad que usaremos para los casos de uso
De entre las desventajas se puede destacar el hecho de que en general losnodos trabajan con informacioacuten desactualizada lo que conlleva una degradacioacutendel rendimiento en situaciones de alta contienda
Figura 5 Planificador de estado compartido
Planificacioacuten distribuida
En este caso no existe coordinacioacuten entre los distintos planificadores Cadauno de ellos funciona con su propia vista del cluster Las tareas pueden serorganizadas por cualquiera de ellos y desplegadas en cualquier parte del clusteren base a la aleatoriedad y multiplexacioacuten estadiacutestica de los flujos de trabajosin ninguacuten control central
Figura 6 Planificador distribuido
12
5 Herramientas
En la industria comienzan a aparecer soluciones software de coacutedigo abiertoque aglutinan los servicios necesarios para gestionar la infraestructura TI de ma-nera maacutes eficaz El objetivo es doble se busca facilitar la gestioacuten de los recursosde computacioacuten para organizaciones con instalaciones propias mediante su usocon un enfoque cloud esto es desplegar aplicaciones a traveacutes de un conjuntode ordenadores de forma transparente y sin tener en cuenta la infraestructurasubyacente o aprovechar el maacuteximo rendimiento de la infraestructura de losproveedores cloud puacuteblicos de forma que se tiene el maacuteximo control sobre eacutestapero no se depende de las soluciones propietarias permitiendo asiacute despliegueshiacutebridos
Entre estas herramientas se pueden destacar
OpenStack Proyecto desarrollado por la fundacioacuten del mismo nombre paraproporcionar servicios de infraestructuras (IaaS) basado en componentesque se comunican a traveacutes de APIs El componente Magnum incluye mo-tores de orquestacioacuten de contenedores
Kubernetes Sistema de orquestacioacuten de contenedores Docker creado por Goo-gle
CoreOs Sistema operativo basado en Linux disentildeado para despliegues distri-buidos sobre contenedores incluyendo mecanismos de descubrimiento deservicio y comparticioacuten de configuracioacuten
Docker Swarm Herramienta nativa de orquestacioacuten de contenedores Docker
YARN Entorno de gestioacuten de recursos y aplicaciones distribuidas de Hadoopuna libreriacutea software de procesamiento de grandes conjuntos de datos
Como podemos observar existe un gran rango de opciones para gestionar lainfraestructura desde un bajo nivel como puede ser OpenStack hasta Kuberne-tes o Docker Swarm que ofrecen exclusivamente orquestacioacuten de contenedores
En este trabajo se ha optado por Mesosphere DCOS y HashiCorp Nomadque se encuentran en el teacutermino medio su objetivo es proporcionar serviciosde plataforma que permitan la coexistencia dediferentes cargas de trabajo en elcluster
13
51 DCOS
DCOS es un proyecto de coacutedigo abierto7 creado y desarrollado por la empre-sa Mesosphere Se describe como un sistema operativo distribuido que abstraelos recursos de un cluster (capacidad de procesamiento memoria) permite lagestioacuten de muacuteltiples ordenadores de forma transparente y simplifica la instala-cioacuten de aplicaciones distribuidas
Su arquitectura se puede comparar a la de Linux en teacuterminos de nuacutecleo(kernel) y espacio de usuario El primero consta de recursos protegidos a losque no puede acceder el usuario e involucra operaciones de bajo nivel comoasignacioacuten de recursos o aislamiento de procesos En el espacio de usuario seejecutan las aplicaciones y servicios de maacutes alto nivel
Siguiendo con este siacutemil el nuacutecleo de DCOS estaacute basado en Apache Mesosque se explicaraacute en un apartado posterior y el espacio de usuario que estaacute com-prendido por los componentes del sistema esto es las diferentes herramientasque en conjunto conforman DCOS y los servicios encargados de planificar yejecutar las aplicaciones y tareas del usuario
Figura 7 Arquitectura DCOSFuente httpsdcosio
De entre los componentes que conforman DCOS destacan
Admin Router Balanceador de carga central basado en NGINX que dis-pone un proxy entre todos los servicios en el puerto 80 permitiendo sugestioacuten mediante la interfaz graacutefica Ademaacutes se encarga de la autenticacioacutenpara acceder al panel de administracioacuten
Cosmos Gestor de paquetes de las aplicaciones
Diagnostics Se ejecuta en todos los nodos y se encarga de monitorizar elestado de los daemons que sustentan DCOS
7Desde abril de 2016 httpsmesospherecomblog20160419open-source-dcos
14
Exhibitor Gestiona y automatiza el despliegue de ZooKeper la herra-mienta que provee de configuracioacuten centralizada y registro de nombres
Marathon Equivale al proceso init de los sistemas tipo Unix esto es elprimer proceso en ejecucioacuten tras la carga del kernel y que genera los demaacutesprocesos Se encarga de arrancar y monitorizar las aplicaciones y servicios
Mesos-DNS Servicio de DNS interno que define el dominio mesos pa-ra nodos y tareas en el cluster es decir permite resolver nombres conindependencia de la direccioacuten fiacutesica
Minuteman Balanceador de carga integrado a nivel TCPUDP disponiblepara las propias aplicaciones
Por otra parte se definen como servicios a las diferentes aplicaciones dis-tribuidas que DCOS permite instalar en el cluster y que pueden haber sidodesarrollados por la misma empresa Mesosphere o por terceros por ejemploApache Spark Jenkins o Apache Hadoop En la figura 8 se muestra un diagramade los servicios disponibles incluyendo algunos de las aplicaciones distribuidasque soporta DCOS
Figura 8 Servicios DCOSFuente httpsdcosio
511 Apache Mesos
El nuacutecleo de DCOS estaacute basado en Apache Mesos un proyecto de coacutedigoabierto creado por la Universidad de California Berkeley y desarrollado actual-mente por la fundacioacuten Apache Se trata de un administrador de clusters queabstrae los recursos y los dispone para diferentes aplicaciones y entornos de tra-bajo distribuidos (frameworks) mediante una interfaz comuacuten En el momento deredaccioacuten de este proyecto Apache Mesos soportaba una variedad de entornosque abarcaba desde Big Data (Apache Spark Hadoop) hasta bases de datos(Cassandra Hypertable)
15
Arquitectura
Mesos se basa en la asignacioacuten de dos roles diferentes a los nodos
Maestros (Masters) Se encargan de la gestioacuten y reparticioacuten de los recursospara los diferentes entornos de trabajo mediante ldquoofertas de recursosrdquo deacuerdo a los disponibles y a la poliacutetica de asignacioacuten (planificacioacuten en dosniveles)
Esclavos (Slaves) Ordenadores donde se ejecutaraacuten las aplicaciones y cu-yos recursos son ofertados por los maestros
En el caso de fallo del maestro las tareas pueden seguir ejecutaacutendose perono se podraacute asignar nuevos recursos ni tareas por ello pueden existir varios enel cluster para configuraciones de alta disponibilidad pero soacutelo uno orquesta alos esclavos
Para la eleccioacuten del master liacuteder Mesos usa Apache ZooKeeper un proyectode software desarrollado por la misma fundacioacuten cuyo objetivo es proveer deun servicio de configuracioacuten centralizado y registro de nombres8
Por otra parte los entornos de trabajo son los programas que deciden final-mente queacute recursos se van a usar y se encargan de que los esclavos ejecuten lastareas Eacutestos se ejecutan sobre Mesos y constan de dos componentes
Planificador (Scheduler) Optimiza y decide los recursos a utilizar de losofertados informando a los Masters
Procesador (Executor) Ejecuta las aplicaciones o servicios en los esclavos
El objetivo final es conseguir una interfaz liviana tolerante a fallos paracualquier tipo de entorno de trabajo de tal manera que en los esclavos del clusterpuedan ejecutarse simultaacuteneamente tareas con necesidades y duracioacuten diferentesPara ello se basa en dos conceptos asignacioacuten y aislamiento de recursos
Asignacioacuten de recursos
En el cluster pueden coexistir entornos de trabajo con tareas de larga dura-cioacuten y con gran consumo de recursos con tareas cortas que los ocupan y liberancon rapidez El maestro integra un moacutedulo de asignacioacuten de recursos (allocationmodule) que se encarga del algoritmo de distribucioacuten
En el momento de escribir este proyecto estaban desarrollados dos moacutedulosuno mediante el cual el usuario puede asignar prioridades y otro que implementa
8httpszookeeperapacheorg
16
el algoritmo Dominant Resource Fairness9 a grandes rasgos se determina entodos los esclavos la tarea en ejecucioacuten que necesita maacutes recursos y se calcula laproporcioacuten del recurso de mayor peso con respecto al total por ejemplo si unatarea ocupa 2 GB de memoria con respecto a 10 GB totales que tiene el clusterse le asigna un dominant share del 20 la tarea se asignaraacute al nodo con menordominant share
Aislamiento de recursos
Para conseguir que tareas de diferentes entornos de trabajo y con distin-ta naturaleza se ejecuten simultaacuteneamente en un mismo nodo Mesos usa loscontenedores Linux (descritos en la seccioacuten 3)
Funcionamiento
La figura 9 muestra el esquema de la arquitectura de Apache Mesos conalta disponibilidad (tres maestros) y con dos entornos de trabajo ejecutaacutendo-se Hadoop que permite el almacenamiento y procesamiento de gran cantidadde datos para proyectos de big data y un sistema que implementa la interfazsistema de paso de mensajes MPI
Como se puede observar el sistema ZooKeeper elige a un solo maestro comoliacuteder y eacuteste orquesta el cluster comunicando los esclavos con los planificadoresde los diferentes entornos de trabajo Tambieacuten se puede observar como las tareasde los distintos entornos estaacuten distribuidas entre los tres esclavos disponibles
Figura 9 Arquitectura de Apache MesosFuente httpsmesosapacheorg
El proceso de asignacioacuten se realiza como sigue en primer lugar un usuariosolicita la ejecucioacuten de una tarea mediante la interfaz de cada entorno de traba-jo (interfaz graacutefica API HTTP ) De forma paralela un esclavo informa almaestro de los recursos que tiene libres En consecuencia eacuteste se lo notifica almoacutedulo de asignacioacuten que en funcioacuten de su configuracioacuten decide cuaacutento ofertar
9httpspeopleeecsberkeleyedu~aligpapersdrfpdf
17
y a queacute entorno de trabajo y enviacutea la oferta a los planificadores Eacutestos respondenal maestro con queacute recursos ha decidido usar para cada tarea Finalmente lastareas son enviadas al esclavo seleccionado el cual asigna los recursos indicadosal procesador (executor) quien finalmente las ejecuta
Cabriacutea pensar que esta metodologiacutea puede conducir a situaciones en lasque un entorno podriacutea quedarse con tareas sin ejecutarse a la espera de unaoferta satisfactoria para ello Mesos implementa un sistema de filtros medianteel cual los entornos especifican los requisitos miacutenimos que debe cumplir unaoferta por ejemplo se puede especificar en queacute nodos debe desplegarse la tareaEste sistema estaacute disentildeado asiacute con el objetivo de mantener lo maacutes transparenteposible esta herramientas de forma que acepte entornos de trabajo de distintasnaturalezas
512 Ejemplos de uso
Grandes empresas estaacuten usando Apache Mesos con eficacia de acuerdo a susnecesidades e infraestructuras Caben destacar
Ebay En el modelo de implementacioacuten continua en esta empresa10 cadadesarrollador cuenta con su propia instancia que se ejecuta en una maacutequinavirtual dedicada lo que ha conllevado un uso de los recursos poco eficiente Enuna prueba de concepto consiguieron realizar una herramienta de integracioacutencontinua distribuida basada en un cluster con Apache mesos y con el entornoMarathon y Jenkins
Apple Anuncioacute que el motor de su famosa herramienta de asistencia per-sonal para iPhones Siri estaacute desplegada sobre Apache Mesos11 Para ello handesarrollado su propio entorno para facilitar a los ingenieros a desplegar los ser-vicios que la herramienta necesita para resolver las peticiones de los usuarios
Twitter Desarrolloacute su propio entorno denominado Aurora y actualmentegestionan sus recursos y miden el coste de las tareas que los empleados usancon el objetivo de que sean conscientes del gasto que puede suponer un usoinadecuado de la infraestructura12
10httpwwwebaytechblogcom20140404delivering-ebays-ci-solution-with-apache-mesos-part-i11httpwwwbusinessinsidercomapple-siri-uses-apache-mesos-2015-812httpswwwlinuxcomNEWS4-UNIQUE-WAYS-UBER-TWITTER-PAYPAL-AND-HUBSPOT-USE-APACHE-MESOS
18
52 Nomad
Herramienta de coacutedigo abierto de gestioacuten de clusters creada y desarrolladapor Hashicorp13 que permite el despliegue de aplicaciones y procesos de formadistribuida
Las principales diferencias con Apache Mesos a grandes rasgos son
Arquitectura maacutes ligera Nomad soacutelo requiere de un fichero para funcionarejecutaacutendolo con las correspondientes configuraciones en todos los nodosrealiza las funciones de gestioacuten del cluster eleccioacuten de liacuteder planificacioacutende recursos y ejecucioacuten de las tareas
Centro de datos y regiones muacuteltiples Su arquitectura estaacute orientada afacilitar la gestioacuten de diferentes centros de datos geograacuteficamente distri-buidos
Entorno de ejecucioacuten Las tareas se definen y son interpretadas mediantecontroladores integrados en Nomad que se valen de los recursos y herra-mientas de los nodos clientes para ejecutarlas Esta integracioacuten dificultael desarrollo de controladores por parte de terceros a diferencia de Mesosque delega dicha responsabilidad en los entornos de trabajo externos alproyecto
Usa un planificador de estado compartido con respecto a la planificacioacutenen dos niveles de Mesos
Antes de entrar en maacutes detalle en la arquitectura es importante definir lossiguientes teacuterminos
Controlador (Driver) Software que se encarga de interpretar las definicionesde las tareas y ejecutarlas semejante a los procesadores de los entornosde trabajo de Mesos A la hora de redactar este proyecto Nomad contabacon controladores para contenedores Docker virtualizacioacuten de maacutequinasmediante el emulador QEMU aplicaciones java y archivos binarios
Grupo de trabajo (Task Group) Conjunto de tareas que se ejecutan en elmismo nodo cliente
Trabajo (Job) Conjunto loacutegico de tareas y grupos de trabajo que se despliegana la vez
Asignacioacuten (Allocation) Relacioacuten entre un grupo de trabajo y el cliente don-de se ejecuta
Evaluacioacuten (Evaluation) Proceso mediante el cual Nomad planifica y ges-tiona el registro o actualizaciones de los trabajos
13httpswwwhashicorpcom
19
Nomad sigue una arquitectura maestro-esclavo similar a la de Apache Mesosmuacuteltiples servidores acuerdan entre siacute un liacuteder que gestiona la planificacioacuten detareas en los clientes que soacutelo conocen sus asignaciones y las ejecutan
Todos los servidores participan paralelamente en tareas de planificacioacuten derecursos y asignacioacuten de tareas y ademaacutes entre ellos eligen un liacuteder que seencarga de la coordinacioacuten de la suscripcioacuten de los clientes al cluster y de lagestioacuten de las peticiones
Los clientes estaacuten configurados para comunicarse con el servidor usando lla-madas a procedimiento remoto (RPC por sus siglas en ingleacutes) que permite unordenador ejecutar coacutedigo en otra maacutequina Mediante esta tecnologiacutea los nodosclientes avisan de su estado e informa de sus asignaciones recursos y controla-dores disponibles
Existe la posibilidad de gestionar varios centros de datos agrupados en regio-nes eacutestas son independientes pero permite definir tareas o comprobar el estadode todas ellas desde cualquier punto A continuacioacuten se muestra una figura dela arquitectura a alto nivel de esta configuracioacuten
Figura 10 Arquitectura multi-regioacuten en NomadFuente httpswwwnomadprojectio
La herramienta se sustenta sobre tres protocolos fundamentales un protocolode consenso entre los servidores para compartir informacioacuten sobre su estado yel liacuteder un protocolo Gossip para la gestioacuten entre regiones y el planificador detareas
521 Protocolo de consenso Raft
El objetivo es obtener consistencia en un conjunto de nodos que comparteninformacioacuten es decir si un cliente realiza un cambio que todos los nodos veanla misma informacioacuten a la vez y ademaacutes sea tolerante a fallos Para ello se basaen el algoritmo Raft[13] que se detalla brevemente a continuacioacuten
20
Los nodos participantes en el algoritmo pueden estar en tres estados
Liacuteder (Leader) Todos los cambios que realicen en el cluster pasan por eacutel pri-mero
Seguidor (Follower) Nodo pasivo cuya responsabilidad es responder a laspeticiones del nodo liacuteder
Candidato (Candidate) Maacutequina que no ha encontrado liacuteder y solicita sueleccioacuten
Supongamos que tenemos cinco equipos que acaban de arrancar el protocoloEn la figura 11 se observan los nodos y sus respectivos registros a la derecha
Figura 11 Equipos sin consenso ejecutando el protocolo RAFTFuente httpsgithubcomongardieraftscope
Al comenzar todos los nodos son seguidores esperando recibir comunicacioacutende un nodo que actuacutee como liacuteder Cada nodo tiene un tiempo de espera aleatoriodespueacutes del cual si no es informado por un liacuteder pasa a estado candidato y pideel ldquovotordquo al resto de los participantes El algoritmo divide el tiempo en plazos uncandidato pasa a liacuteder si recibe la mayoriacutea de los votos en un plazo determinadoSe define mayoriacutea o cuoacuterum (quorum) comolceil
N2rceil
+ 1 (1)
donde N representa el nuacutemero de nodos
Para el ejemplo propuesto de 5 equipos se requieren de 3 votos Soacutelo losnodos que se encuentren en estado seguidor pueden votar una uacutenica vez a laprimera solicitud que reciba dentro de un plazo
Supoacutengase que el nodo denotado con S1 ha cumplido su tiempo de espera yrealiza la peticioacuten de voto (figura 12) A partir de este momento se pueden dartres casos
La maacutequina gana la eleccioacuten y pasa a ser liacuteder informando al resto
Otro servidor se establece como liacuteder en el mismo momento
Varios nodos pasan a ser candidatos por lo que ninguno consigue los votos
21
Figura 12 Un equipo pasa a estado candidato (RAFT)
Si un candidato recibe un aviso de un liacuteder en el mismo plazo el primeropasa a ser seguidor y se acaba la eleccioacuten de liacuteder
Por otro lado si un equipo candidato no recibe los votos en el plazo y agotasu tiempo de espera avanza al siguiente plazo y repite el proceso de votacioacutenLa tercera posibilidad puede conllevar a un estado indefinido ya que varioscandidatos pueden agotar su tiempo de espera al mismo tiempo y repartir losvotos Para solventarlo el algoritmo establece tiempos de espera aleatorios paralos candidatos
Siguiendo con el ejemplo propuesto el servidor S1 pasa a ser el liacuteder Cadacierto tiempo eacuteste debe realizar avisos a los nodos seguidores para no agotar sutiempo de espera
En este momento el cluster de servidores estaacute en ldquoconsensordquo y la informacioacutenen todos los nodos estaacute actualizada Un cambio en la informacioacuten inicia unproceso de replicacioacuten el liacuteder registra el cambio lo pasa al resto de nodos yuna vez eacutestos responden el cambio se hace efectivo
Supoacutengase que se realiza un cambio en los datos en la figura 13 en la partederecha se observa el cambio en el registro del servidor S1 que informa a losnodos seguidores En consecuencia los nodos registran el cambio y responden aS1
Figura 13 Cambio en un registro (RAFT)
Una vez el cuoacuterum (en el ejemplo tres equipos) informa al liacuteder de que
22
ha registrado el cambio el liacuteder lo hace efectivo en su sistema y notifica a losnodos que hacen lo mismo En la figura 14 el enviacuteo todaviacutea no ha llegado ala maacutequina S3 y se observa que no ha hecho efectivo el cambio (en el registroaparece punteado)
Figura 14 Aprobacioacuten del resto de equipos (RAFT)
Este protocolo funcionaraacute correctamente mientras exista un nuacutemero de nodosen funcionamiento igual o superior al cuoacuterum en el ejemplo propuesto elcuoacuterum es tres por lo que el sistema puede tolerar la caiacuteda de dos de los equipos
522 Protocolo gossip SWIM
Nomad permite la gestioacuten simultaacutenea de varios centros de datos reparti-dos en regiones geograacuteficamente separadas requiriendo de un protocolo ligeroque mantenga a los miembros actualizados sobre los participantes del conjun-to Para ello usa una ligera variante del protocolo SWIM[3] (Scalable Weakly-consistent Infection-style Process Group Membership Protocol) desarrollada porHashiCorp Estaacute clasificado como un protocolo de tipo gossip que debe su nom-bre a la semejanza con coacutemo se distribuye un rumor en una red social
SWIM se sustenta en dos caracteriacutesticas fundamentales la deteccioacuten de fallosy la distribucioacuten de la informacioacuten relativa a los miembros A continuacioacuten sedetalla el funcionamiento de ambos componentes
Deteccioacuten de fallos
Este componente tiene dos paraacutemetros el periodo de protocolo T y el nuacutemerode subgrupos de deteccioacuten de fallos k en los que se dividen los nodos Paracomprobar la comunicacioacuten entre dos maacutequinas usa la utilidad ping basadaen el protocolo ICMP La deteccioacuten de caiacuteda de un servidor sigue el siguientealgoritmo
Durante el periodo T cada miembro Mi de un subgrupo elige otro al azar Mjdel mismo subgrupo y le enviacutea un mensaje ping para comprobar su estado Enel caso de que se cumpla un tiempo de espera determinado por una estimacioacuten
23
del tiempo de ida y vuelta (RTT por sus siglas en ingleacutes) de la red y no hayarespuesta Mi le vuelve a enviar un mensaje ping indirectamente a traveacutes deun nuacutemero k de miembros escogidos aleatoriamente De no recibir ninguna res-puesta Mi establece que Mj ha sufrido un fallo y lo etiqueta como ldquosospechosordquoinformando al componente de distribucioacuten
Figura 15 Diagrama de tiempo del protocolo SWIMFuente httpswwwcscornelledu
Componente de distribucioacuten
Se encarga de informar de cualquier cambio en los miembros a todo el con-junto Los eventos de nodo caiacutedo y la unioacuten o disociacioacuten de un miembro setransmiten a todos los servidores para que actualicen sus lista Para distribuirla informacioacuten a todos los nodos se podriacutea usar el meacutetodo de multicast perosuele estar deshabilitado Por ello se utiliza una teacutecnica de transmisioacuten denomi-nada Piggybacking mediante la cual se adjunta a los propios mensajes PINGy ACK del algoritmo la informacioacuten a distribuir reduciendo asiacute la congestioacutenen la red
523 Planificacioacuten
Proceso encargado de distribuir las tareas entre los nodos clientes de acuerdoa su estado
El planificador de Nomad estaacute basado en las publicaciones de Google sobresus herramientas de gestioacuten de clusters Borg y Omega14 y entiende los trabajosdescritos por el usuario como un estado deseado es decir su despliegue en unamaacutequina cliente de forma correcta y los clientes como el estado actual esto eslo que se encuentra en ejecucioacuten El registro actualizacioacuten o cancelacioacuten de un
14httpresearchgooglecompubspub43438html
24
trabajo asiacute como el fallo de un nodo cliente implican un cambio de estado atramitar por el sistema lo que se define como evaluacioacuten (evaluation) Esto uacutelti-mo supone comparar el estado actual (clientes) con el estado deseado (conjuntode trabajos registrados) y enviarlos a los planificadores correspondientes que seencargaraacuten de asignar las tareas a los nodos clientes
Figura 16 Procedimiento de asignacioacuten en NomadFuente httpswwwnomadprojectio
En la figura 16 se observa el flujo de trabajo en el que las distintas evalua-ciones se encolan en el evaluation broker que se ejecuta en el servidor liacuteder ygestiona las evaluaciones pendientes asignaacutendoles prioridades
A continuacioacuten los nodos servidores ejecutan los scheduling workers queprocesan las evaluaciones llamando a los distintos planificadores que generanun plan de asignacioacuten esto es un conjunto de relaciones entre las tareas y losnodos clientes donde se ejecutaraacuten Este proceso se divide en dos fases primerose descartan aquellos clientes que no cumplan los requisitos y posteriormentese asigna una calificacioacuten al resto Se selecciona el nodo con mayor puntuacioacuteny se encola el plan en el gestor que se ejecuta en el servidor liacuteder Existen tresplanificadores de acuerdo al tipo de trabajo
Service Incluye aquellos trabajos que estaacuten destinados a ejecutarse en un pe-riacuteodo largo de tiempo Para realizar las asignaciones el planificador evaluacuteala mayor parte de los nodos y usa una versioacuten del algoritmo Best fit in-fluenciada por el trabajo de Google en su herramienta Borg Se trata deun algoritmo de planificacioacuten que sacrifica tiempo a cambio de maximizarel rendimiento de los clientes asignando la tarea a la maacutequina que tengala mayor carga de trabajo con el objetivo de reducir equipos en funciona-
25
miento
Batch Tareas que incluyen listas de comandos en general de menor duracioacuteny que no requieren interaccioacuten con el usuario Se vale del algoritmo deSparrow desarrollado por la universidad de Berkeley15 para limitar losnodos clientes a evaluar
System Trabajos destinados a ejecutarse en todos los nodos incluso los que seunen al cluster posteriormente
Core Mantenimiento interno de Nomad
Una vez se ha realizado el proceso de planificacioacuten el nodo liacuteder lo registra enla cola de planes (plan queue) que se encarga de asignarles prioridad y manejarcondiciones de carrera es decir que no accedan a los recursos de los clientes sincontrol y evitar que eacutestos superen su capacidad
La maacutequina liacuteder del conjunto puede de este modo aceptar una asignacioacuteny ser ejecutada por los clientes o por el contrario rechazaacutersela al planificadorlo que implicariacutea realizar un plan parcial o totalmente nuevo
Finalmente el estado de las evaluaciones se actualizan y los clientes soninformados de las asignaciones ejecutaacutendose las tareas
15httppeopleeecsberkeleyedu~keopublicationssosp13-final17pdf
26
6 Casos de uso y despliegue
Con el objetivo de mostrar las posibles utilidades que este tipo de sistemaspueden tener en las infraestructuras TI actuales se han desplegado las dos he-rramientas en la nube Microsoft Azure usando su servicio cloud de instancias demaacutequinas virtuales Linux para simular un conjunto de ordenadores conectadosentre siacute por una red LAN Sobre ellas se ha implementado dos casos de usouna aplicacioacuten web con una arquitectura con cierta orientacioacuten a microserviciosy un sistema de integracioacuten continua
El coacutedigo y todos los ficheros de configuracioacuten se pueden encontrar en elrepositorio del proyecto en GitHub16
61 Aplicacioacuten Web
Se busca simular el proceso de adaptacioacuten de una solucioacuten web para su des-pliegue en un sistema distribuido con las herramientas anteriormente descritascon el objetivo de aumentar tanto su escalabilidad como disponibilidad medianteredundancia
Se ha partido de una aplicacioacuten ya existente17 un servicio de almacenamien-to y reproduccioacuten de canciones A grandes rasgos este servicio permite crearusuarios subir canciones con sus respectivas portadas tener playlists propias yescuchar las canciones a traveacutes de un navegador web
La solucioacuten estaacute dividida en 4 partes (figura 17)
Una vista web con la loacutegica
Un almacenamiento conectado en red (NAS por sus siglas en ingleacutes)
Una API REST para gestionar las peticiones al almacenamiento
Base de datos NoSQL basada en MongoDB
La nueva tendencia de los proyectos web es su implementacioacuten en contene-dores Docker ya que facilitan su portabilidad y ofrecen un procedimiento dedespliegue raacutepido sobre todo a la hora de desarrollar y realizar pruebas en en-tornos de produccioacuten simulados Por ello en este caso se va a hacer uso de los
16httpsgithubcomAntonioAlfrzCloud-Orchestrators17httpsgithubcomsonsoleslpCDPSfy
27
motores de orquestacioacuten de contenedores de ambas herramientas Marathon enDCOS y el controlador Docker en el caso de Nomad
Figura 17 Arquitectura aplicacioacuten web
A continuacioacuten vamos detallar el despliegue en ambas herramientas de es-ta solucioacuten y observar tanto queacute dificultades se encuentran como que ventajasofrecen El objetivo final es adaptar el proyecto modificaacutendolo lo menos posiblecon objeto de analizar la capacidad de estas herramientas para desplegar cual-quier aplicacioacuten sin que eso conlleve la modificacioacuten de la arquitectura de eacutestaes decir que no sea dependiente del entorno
611 DCOS
Se ha descrito DCOS como una herramienta que se despliega sobre un con-junto de ordenadores y que permite instalar gestionar el despliegue de sistemasdistribuidos
Microsoft Azure cuenta con una plantilla para desplegar en su servicio cloudun cluster de maacutequinas virtuales con DCOS ya instalado que cuenta con
Maacutequinas maestras (1 3 o 5 a seleccionar por el usuario) configuradascomo un conjunto de disponibilidad esto eso Azure da ciertas garantiacuteasde que al menos una maacutequina estaraacute en funcionamiento
Maacutequinas agentes Por motivos de seguridad se distinguen dos roles
bull Nodos privados solo accesibles desde la red interna y configuradoscomo un conjunto de escala un recurso de Azure para gestionar ydesplegar maacutequinas con configuraciones ideacutenticas para permitir unraacutepido escalado
bull Un equipo conectado accesible desde Internet a travntildees de un balan-ceador de carga puacuteblico y situado en una subred externa
28
Dos balanceadores de carga
bull La interfaz puacuteblica del cluster que se conecta con el cliente puacuteblicobull Acceso a los equipos maestros para el administrador que soacutelo permiteconexioacuten mediante SSH y credenciales
Almacenamiento para todas las maacutequinas
Configuraciones necesarias de red y seguridad
En la figura 18 se observa un diagrama de la infraestructura
Figura 18 Infraestructura en Azure
El primer obstaacuteculo es la persistencia de estado de la aplicacioacuten que seconsigue gracias a una base de datos no relacional basada en MongoDB asiacutecomo el almacenamiento de las canciones Para implementarla tenemos variasposibilidades
Montar un sistema externo de almacenamiento conectado en red en todoslos agentes donde se ejecuten las tareas de esta manera si una tarea pasade un nodo a otro por cualquier motivo puede tener acceso a los mismosficheros (opcioacuten del caso de uso original)
Implementar un sistema de ficheros distribuidos en los agentes
Usar los servicios de almacenamiento de las nubes puacuteblicas
Aprovechar el sistema de voluacutemenes persistentes de Apache Mesos Eacutestepermite reservar recursos de un agente de forma que al arrancar una tarease crea un volumen independiente del ciclo de vida de eacutesta con ello esosrecursos donde se ha almacenado la informacioacuten pueden volver a ofrecerseal mismo entorno de tal manera que otra tarea pueda acceder a ella
DCOS aprovecha este sistema de voluacutemenes persistentes y permite instalarbases de datos distribuidas como ArangoDB o Apache Cassandra sin embargoesto implicariacutea modificar todo el coacutedigo referente al modelo de la base de datos
29
Por motivos de eficiencia y latencia asiacute como de una mayor gobernabilidadde los datos la mejor opcioacuten es usar el recurso de voluacutemenes persistentes queofrece Apache Mesos ya que de esta manera se gestionariacutea la aplicacioacuten completamediante una uacutenica herramienta Sin embargo esto implica que la informacioacutense encuentra exclusivamente en el agente donde se haya ejecutado la tarea y porlo tanto se sigue requiriendo de software externo para distribuir la informacioacutenpara que se accesible para todos los agentes A la hora de realizar este proyectose encontraba en desarrollo Flocker una solucioacuten desarrollada por ClusterHQque permite compartir los voluacutemenes de Docker a traveacutes de un cluster quesi bien es compatible con el planificador de Mesos el proyecto se encontrabatodaviacutea en fases tempranas de desarrollo y los sistemas de almacenamiento quesoporta quedaban fuera del aacutembito de este trabajo
Por todo ello dado que las maacutequinas se han desplegado en la nube puacuteblicade Azure se decidioacute usar su servicio de almacenamiento de objetos para lascanciones y otra maacutequina para desplegar MongoDB y asiacute mantener el modelode datos original de la aplicacioacuten La diferencia del almacenamiento de obje-tos con respecto a nivel de fichero es que el primero no tiene jerarquiacutea paraorganizar los archivos eacutestos se guardan como objetos (con sus metadatos) enun mismo espacio soacutelo diferenciaacutendose por un identificador uacutenico esto implicaentre otras cosas que se puede acceder a un fichero dado uacutenicamente su IDindependientemente de la localizacioacuten fiacutesica de eacuteste facilitando pues la gestioacuteny el desarrollo
El coacutedigo del proyecto se ha modificado en los siguientes apartados
Las direcciones de la base de datos y los balanceadores de carga asiacute comosus puertos estaban originalmente fijos Se han configurado como variablesde entorno para facilitar el descubrimiento del servicio y hacer transpa-rente la aplicacioacuten al entorno de despliegue
La API REST se ha adaptado al almacenamiento en Azure en vez de enlocal
Estas modificaciones no suponen un cambio sustancial pero permiten separala persistencia de las tareas ejecutadas por DCOS lo que facilita en granmedida su ejecucioacuten al ser totalmente sin estado y ademaacutes implican tenerlos datos bajo un mayor control
Para la orquestacioacuten de contenedores se va a usar el entorno Marathondesarrollado tambieacuten por Mesosphere Eacuteste se puede usar a traveacutes de una interfazgraacutefica la interfaz de liacutenea de comandos (en lo que sigue CLI por sus siglas eningleacutes) de DCOS o con su API HTTP
Primero se han publicado la imaacutegenes de los contenedores que encapsulanla interfaz web y la api de la aplicacioacuten en el repositorio puacuteblico DockerHub
Los despliegues en este entorno se describen mediante ficheros JSON en losque se detalla entre otras opciones la imagen del contenedor los puertos a usar
30
los recursos que debe ocupar en un nodo o las instrucciones de monitorizacioacuten
Para el servicio de descubrimiento DCOS ofrece la posibilidad de asignardirecciones IP virtuales (VIP por sus siglas en ingleacutes) a tareas que se compartenen todos los nodos DCOS lleva integrado un balanceador de carga a nivel TCP(el componente denominado Minuteman) que balancea entre las direccionesvirtuales de las tareas y todas las instancias de eacutestas a lo largo del cluster Estoes necesario por dos motivos equilibrar la carga de los equipos con el fin deevitar un punto de uacutenico fallo mediante redundancia y evitar la contienda dedirecciones al ejecutar las tareas en puertos aleatorios
Este balanceador de carga estaacute basado en el trabajo de Michael Mitzenma-cher The Power of Two Choices in Randomized Load Balancing18 A grandesrasgos el algoritmo mantiene una media moacutevil exponencial de latencias paracada destino (backend) ademaacutes de las caiacutedas consecutivas Si un destino noresponde a una negociacioacuten en tres pasos (three way handshake) de forma con-secutiva en un periodo inferior a 5 ms se considera caiacutedo El algoritmo iterasobre los destinos disponibles en base a su histoacuterico de fallos y escoge dos deforma aleatoria de los cuales coge el de mejor meacutetrica
Las direcciones virtuales soacutelo se pueden resolver dentro del cluster porello para implementar la interfaz puacuteblica de la aplicacioacuten esto es el balancea-dor de carga de la interfaz web usaremos un paquete de DCOS denominadomarathon-lb un balanceador basado en HAProxy y adaptado por MesosphereEn este caso equilibra la carga de todas instancias de las tareas ejecutadas porel entorno Marathon por sus etiquetas y permite ademaacutes definir como puntode entrada muacuteltiples hosts virtuales definidos por sus nombres completos dedominio (FQDN por sus siglas en ingleacutes) en nuestro caso la interfaz puacuteblicadel balanceador de Azure para los agentes
Por motivos de seguridad todas las tareas se ejecutan en los agentes privadoses decir los que son exclusivamente accesibles desde la red interna Por su partemarathon-lb se ejecuta en el agente puacuteblico que cuenta con IP puacuteblica y lospuertos 80 (HTTP) y 8080 abiertos de forma que la aplicacioacuten sea accesibledesde Internet Esto es posible debido a que Apache Mesos permite reservarrecursos mediante roles asignados a nodos para un uso especiacutefico De esta formala arquitectura vista desde la aplicacioacuten quedariacutea como en la figura 19
18httpswwweecsharvardedu~michaelmpostscriptstpds2001pdf
31
Figura 19 Arquitectura de la aplicacioacuten web en DCOS
Ejecucioacuten
A la hora de desplegar la aplicacioacuten DCOS puede gestionarse medianteuna interfaz graacutefica o una interfaz de liacutenea de comandos La primera se accedea traveacutes de un navegador web en el puerto 80 (HTTP) y permite instalar losentornos disponibles observar el estado de los nodos y las tareas que se estaacutenejecutando y los ficheros de registros que eacutestas generan
La CLI permite el control desde un nodo o una maacutequina remota (suponiendoque los maestros tienen IP puacuteblica y el puerto 80 abierto) ya que DCOS tieneun sistema de autorizacioacuten que permite tener una interfaz puacuteblica con ciertasgarantiacuteas de seguridad
Por su parte cada entorno de trabajo puede ser controlado por la CLI peroademaacutes cuenta con sus propias interfaces Marathon expone una API HTTPen el puerto 8080 de la direccioacuten puacuteblica de los maestros del cluster asiacute comootra interfaz graacutefica Para desplegar un contenedor se podriacutea usar la CLI
$ dcos marathon app add lt f i l e j songt
O la API HTTP
$ cu r l minusX POST http lt ip_maestro gt8080v2apps minusd ltf i l e jsongt minusH Contentminustype app l i c a t i o n j son
32
612 Nomad
La arquitectura de Nomad es maacutes sencilla ya que solo requiere de un ficheroejecutable en todos los nodos para funcionar Si DCOS es la base de instala-cioacuten de entornos de terceros Nomad integra todas las funcionalidades baacutesicasesto es gestor de recursos planificador y ejecutor en los nodos cliente Estaherramienta cuenta con un menor tiempo de desarrollo y en el momento deescribir este documento cuenta exclusivamente con los siguientes controladoresen comparacioacuten con los entornos de DCOS
Motor Docker es decir funcioacuten de orquestacioacuten de contenedores
Ejecucioacuten de archivos binarios como comandos de Shell
Ejecucioacuten de aplicaciones Java
Virtualizacioacuten de maacutequinas mediante tecnologiacutea QEMU
Todos ellos necesitan que la tecnologiacutea subyacente esteacute instalada en las maacute-quinas clientes (Docker Java QEMU) Actualmente no permite el registro decontroladores por parte de terceros aunque estaacute planificado en un futuro ofreceruna interfaz para su desarrollo
Nomad no cuenta con el servicio de descubrimiento sin embargo puede inte-grarse con la herramienta Consul desarrollada por la misma empresa Por otrolado para el balanceo de carga usaremos un contenedor Docker con HAProxyuna herramienta de coacutedigo abierto que ofrece tanto servicios de proxy como debalanceador y cuyos ficheros de configuracioacuten completaremos con el proyectoConsul Template19
Consul
Consul sigue la misma arquitectura que Nomad es decir un nodo servidorque orquesta un conjunto de maacutequinas clientes y permite a los procesos que seejecutan en los equipos definirlos como servicios ofreciendo diversas caracteriacutes-ticas entorno a estos de los cuales vamos a usar dos
Descubrimiento de servicio Las maacutequinas clientes publican en el cataacutelogode servicios las tareas en ejecucioacuten y Consul les asigna nombres de dominioaccesibles por todos los miembros del cluster a traveacutes de la interfaz DNSincluida en esta herramientaConsul se integra con Nomad de forma que todas las tareas que se ejecu-ten en la segunda son automaacuteticamente publicados como servicios de laprimera de esta manera no hace falta conocer la direccioacuten de la maacutequinacliente donde se esteacute ejecutando el proceso ya que se puede acceder a eacutela traveacutes de su nombre de dominio de forma transparente Por ejemplo si
19[httpsgithubcomhashicorpconsul-template]
33
ejecutamos una tarea con ID web en el puerto 8080 se puede acceder aella en la direccioacuten webserviceconsul8080Para que las direcciones propias de Consul las resuelva su propio DNS y noel que esteacute asignado por defecto en la maacutequina usaremos la herramientadnsmasq20 que permite especificar la direccioacuten de un servidor DNS paraconsultas de direcciones especiacuteficas
Monitorizacioacuten Permite realizar comprobaciones del servicio y seguir su esta-do Aprovecharemos esta funcionalidad tanto para definir el propio procesode Nomad como servicio de Consul como las tareas desplegadas
HAProxy + Consul Template
HAProxy es una solucioacuten versaacutetil de coacutedigo abierto que ofrece solucionesde balanceo de carga y proxy Existen otras herramientas en el mercado comoNGINX o ldirectord sin embargo HAProxy suponiacutea una solucioacuten sencilla deconfigurar para mostrar el caso de uso
El uso de estas herramientas se debe a dos motivos para que no existacontienda con respecto a los puertos de los clientes usados por las tareas eacutestos sevan a asignar de forma dinaacutemica lo que en principio implicariacutea que la aplicacioacutendeberiacutea realizar consultas DNS de tipo SRV (que incluye puertos) a la interfazde Consul y balancear la carga entre tareas por redundancia y capacidad
Como la direccioacuten IP y puerto son variables cada vez que las tareas seactualicen o se reasignen es necesario volver a configurar HAProxy de formamanual Por ello HashiCorp ha desarrollado un programa denominado Con-sul Template que realiza peticiones sucesivas a la interfaz HTTP de Consul delas direcciones fiacutesicas de un servicio y reinicia automaacuteticamente el proceso deHAProxy Asiacute definiendo estas tareas como servicios Consul podremos tantomonitorizarlas como escalar las tareas dinaacutemicamente sin necesidad de cambiarel balanceador A partir del contenedor Docker oficial de HAProxy se ha desa-rrollado otro con la configuracioacuten baacutesica y con Consul Template para desplegarlocomo una tarea en Nomad
Despliegue
Se ha usado el mismo coacutedigo que en el apartado anterior con la persistenciaen el servicio de almacenamiento de Azure Desde la perspectiva del hardwarese implementaraacute la misma infraestructura que en el caso de DCOS (figura 18)estos es definiremos dos tipos de maacutequinas clientes un agente que se conectaraacutecon el balanceador de carga con nombre de dominio puacuteblico y donde se desple-garaacute el balanceador de carga de la vista web y agentes privados no accesiblesdesde fuera del cluster y donde se ejecutaraacuten el resto de tareas en la red inter-na La principal diferencia radica en las tareas que ejecutan HAproxy y ConsulTemplate que sustituye a las direcciones IP virtuales que ofrece DCOS
20httpwwwthekelleysorgukdnsmasqdochtml
34
Figura 20 Despliegue en Azure de Nomad+Consul
Cabe matizar que los balanceadores basados en HAProxy se implementanpor necesidad de la aplicacioacuten para el descubrimiento del servicio a diferenciade los de Azure que se implementan por motivos de seguridad y escalabilidaddel cluster en siacute
Configuracioacuten Nomad
Los ficheros de configuracioacuten de las maacutequinas maacutester y cliente son similaresy comparten la mayoriacutea de las opciones como por ejemplo el nombre del nodoo la interfaz de red donde escucha Nomad las peticiones Sus opciones son engeneral auto-explicativas sin embargo existen dos detalles que matizar
El proceso de Nomad escucha las peticiones tanto de los protocolos deconsenso como del usuario a traveacutes de una interfaz de red que se debeindicar en el fichero de configuracioacuten
En el caso de los clientes se deben indicar las direcciones de los servidoresdel cluster sin embargo se trata de un sistema dinaacutemico en el que losnodos pueden sufrir errores y cambiar de direccioacuten Por ello se ha definidoNomad como un servicio de Consul y asiacute poder definir la direccioacuten de losservidores como un nombre de dominio no por su direccioacuten fiacutesica que elservidor DNS de Consul se encargaraacute de resolver
Por defecto Nomad usa los siguientes puertos
API HTTP 4646 Peticiones HTTP y recepcioacuten de oacuterdenes mediante laliacutenea de comandos
RPC 4647 Protocolo de consenso entre los nodos del cluster
Serf 4648 Protocolo de gossip entre los servidores de los centros de datosgobernados por Nomad
35
Los dos uacuteltimos deben ser interfaces alcanzables por otros nodos sin embargo laAPI HTTP por motivos de seguridad deberiacutea ser local ya que en caso contrariocualquier persona con acceso a ella tiene el control sobre la herramienta Eacutestasolo deberiacutea estar accesible en un servidor o gestionarlo mediante una terminalSSH por ejemplo En este trabajo al ser una prueba de concepto se ha abiertoen todos los nodos
Trabajos de Nomad
Las tareas se detallan en ficheros con formato HashiCorp Configuration Lan-guage un derivado del formato JSON creado por la empresa que le da nombrecompatible con eacuteste y que permite comentarios
En estos ficheros se puede definir
La regioacuten y el centro de datos donde se ejecutaraacute (Nomad permite lagestioacuten de centros de datos geograacuteficamente distribuidos en regiones)
La poliacutetica de actualizacioacuten de la tarea
Grupo de tareas esto es que se ejecutaraacuten en el mismo nodo
El nuacutemero de grupos a ejecutarescalar asiacute como los liacutemite que debencumplir los nodos asignados
La poliacutetica de reinicio ante fallo o error
Tareas El controlador su configuracioacuten los paraacutemetros del servicio aso-ciado a registrar en Consul asiacute como los recursos que consume (puertosmemoria)
En nuestro caso usamos sobre todo el controlador Docker esto eso orques-tacioacuten de contenedores en los nodos clientes y tres de sus opciones
Imagen del contenedor Se han subido todas las imaacutegenes del proyecto a Doc-ker Hub donde por defecto se busca la imagen
Puertos Los puertos a usar por el contenedor que pueden ser estaacuteticos asigna-dos por el usuario o dinaacutemicos siendo Nomad el que se encarga de mapearun puerto libre del nodo cliente al expuesto por el contenedor
Servidores DNS Como usamos la interfaz DNS de Consul como descubri-miento de servicio se debe configurar el contenedor para que use cualquiernodo del cluster como servidor DNS
Configuracioacuten Consul
Al ser desarrolladas por la misma empresa los ficheros de configuracioacuten deConsul y Nomad comparten muchas opciones Consul tambieacuten acepta peticionesa traveacutes de una interfaz de red siendo los puertos usados por defecto
36
RPC 8300 8400 Maneja la peticiones del resto de nodos y usuarios
Serf 8301 8302 Protocolo gossip
HTTP API 8500
HTTPS API Desactivada por defecto
Interfaz DNS 8600
Se debe asignar a los protocolos internos del cluster esto es RPC y Serf unainterfaz alcanzable por los nodos y por el contrarioasignar a los dos uacuteltimos ala interfaz de loopback por motivos de seguridad
Cabe destacar que Consul tambieacuten cuenta con una interfaz graacutefica que per-mite ver el estado de los equipos y los servicios registrados y que se encuentra enel mismo puerto que la API HTTP en la direccioacuten httpIP_EQUIPO8500ui
Ejecucioacuten
Tanto Nomad como Consul requieren de la ejecucioacuten de un fichero en todoslos nodos integrantes del cluster Como prueba de concepto se ha decidido usardos servidores para ambos aunque cabe matizar que es un nuacutemero ineficienteya que la caiacuteda de uno de ellos supondriacutea la peacuterdida del cuoacuterum y por tantodel consenso del cluster
En primer lugar se arrancan los servidores que son los encargados de ejecu-tar el protocolo de consenso y gestionar el cluster y a continuacioacuten los clientesque no tienen praacutecticamente estado y dependen de los servidores
En el caso de Consul se debe indicar el directorio donde se guardan losficheros que describen los servicios asiacute como el archivo que especifica el resto delas opciones
1 Se inicia el primer servidor en uno de los equipos
$ consu l agent minuscon f i gminusd i r e t c consu l d s e r v i c e s minuscon f i gminus f i l e consu l_server j son
2 Los siguientes equipos deben unirse al anterior por lo que antildeadimos elargumento join con la direccioacuten del primer servidor Para el caso de otrosservidores
$ consu l agent minuscon f i gminusd i r e t c consu l d s e r v i c e s minuscon f i gminus f i l e consu l_server j son minus j o i n ltIP_servidor1gt
37
Una vez los servidores han alcanzado el consenso y elegido un liacuteder en losclientes
$ consu l agent minuscon f i gminusd i r e t c consu l d s e r v i c e s minuscon f i gminus f i l e c on su l_c l i en t j son minus j o i n ltIP_cualquierServ idorgt
El proceso para iniciar Nomad es igual y los comandos similares sin embargoya no es necesario indicar una direccioacuten IP fija en los equipos sino el nombre dedominio del servicio de Nomad registrado por Consul En el primer servidor
$ nomad agent minusc on f i g nomad_server j son
Y el resto de equipos (con su fichero de configuracioacuten correspondiente)$ nomad agent minusc on f i g nomad_server j son minus j o i n nomad s e r v i c e consu l
Por uacuteltimo para desplegar la aplicacioacuten web se han escrito tres ficherosque detallan las tareas de la interfaz web API y los balanceadores de cargaMediante la CLI
$ nomad run minusaddress=http lt ip_c lus te r gt4646 lt f i l e hclgt
O mediante la API HTTP de Nomad$ cu r l minusX POST minusd ltf i l e hclgthttp lt ip_c lus te r gt4646 jobltjob_namegt
Ansible
Como se puede comprobar con el aumento del nuacutemero de equipos pasa aser inviable manejar todos los nodos a traveacutes de terminal Ademaacutes como seha comentado con anterioridad Nomad requiere que en los nodos clientes es-teacuten instalados las herramientas que soporten las tareas por ejemplo el motorde Docker Por ello para facilitar tanto el arranque como la instalacioacuten de lasdependencias vamos a usar Ansible una herramienta de coacutedigo abierto desarro-llada en Python que permite gestionar configuraciones aprovisionar recursosdespliegue de aplicaciones de forma automaacutetica
A grandes rasgos esta herramienta funciona mediante ficheros en formatoYAML denominados play-books que describen un conjunto de pasos a ejecutaren una lista de equipos remotos Estos pasos son ejecutados por moacutedulos inde-pendientes a traveacutes de SSH es decir en cualquier ordenador con conexioacuten a los
38
hosts dado su contrasentildea o clave puacuteblica puede arrancar el script y realizariacutealos pasos de forma remota gestionando el cluster desde un solo equipo
Se han desarrollado guiones para lo siguiente
Descarga de los binarios de Nomad y Consul en todos los nodos copiade los ficheros de configuracioacuten baacutesicos y modificarlos de acuerdo a cadanodo (nombre del equipo direccioacuten IP)
Instalacioacuten de las dependencias
Arranque de Nomad y Consul
Ansible extiende su funcionalidad a traveacutes de moacutedulos independientes que per-miten por ejemplo instalar paquetes mediante herramientas de gestioacuten de pa-quetes (APT yum) aprovisionar automaacuteticamente maacutequinas virtuales de Ama-zon EC2
Algunas opciones de los ficheros de configuracioacuten de Nomad y Consul sondependientes del nodo particular por ejemplo la interfaz de red Para estetrabajo se ha realizado un moacutedulo para modificar los ficheros de configuracioacutende forma automaacutetica En el repositorio del proyecto se encuentra una carpetadonde se encuentran todos los ficheros necesarios para desplegar un clustertotalmente funcional solo requiere de una liacutenea de terminal con Ansible
$ ans ib l eminusplaybook minus i hos t s minusk ltssh_passgt minusu ltnode_usergt s i t e yml
39
62 Servicio de integracioacuten continua
Se ha implementado un sistema de integracioacuten continua que permite ejecu-tar tareas de compilacioacuten y pruebas de forma distribuida aumentando asiacute elrendimiento de los equipos En primer lugar se detallaraacute los motivos por los quepuede resultar beneficioso para las empresas una implementacioacuten de este tipo alo que seguiraacute los detalles del despliegue
621 DevOps
Metodologiacutea que defiende la comunicacioacuten y colaboracioacuten entre desarrolla-dores de software y los profesionales de operaciones a lo largo de todo el ciclo devida de una aplicacioacuten Estaacute muy relacionado con el desarrollo aacutegil de softwareesto es un enfoque para los proyectos que defiende el desarrollo iterativo e in-cremental donde los requisitos y soluciones evolucionan con el tiempo seguacuten lanecesidad del proyecto DevOps extiende esta filosofiacutea a todas los componentesde un servicio incluyendo sistemas y operaciones
Se trata de un concepto que cada organizacioacuten o empresa adapta a suspropias necesidades y procesos de negocio en este proyecto nos vamos a centraren la integracioacuten continua una praacutectica fundamental tanto del desarrollo aacutegilcomo de esta filosofiacutea
622 Integracioacuten Continua
Se define como una praacutectica de desarrollo software donde los miembros delequipo ponen en comuacuten su trabajo frecuentemente al menos una vez al diacutea21Cada integracioacuten se verifica con una compilacioacuten automaacutetica que incluye laejecucioacuten de pruebas para detectar errores de integracioacuten tan pronto como seaposible
Desde el punto de vista operativo esto supone automatizar la configuracioacutende equipos o el despliegue de maacutequinas virtuales donde compilar el proyecto yejecutar las pruebas y posteriormente eliminarlas Este flujo de trabajo se vebeneficiado en entornos distribuidos ya que el objetivo del desarrollador es com-probar el resultado de las pruebas raacutepidamente sin preocuparse del despliegueo los propios equipos
Para esta prueba de concepto vamos a usar Jenkins un servidor de integra-cioacuten continua escrito en Java que nos permite definir trabajos que contendraacutenla descripcioacuten tanto del entorno como su ejecucioacuten
Este sigue una estructura maestro-esclavo muy similar al de los gestores declusters usados en este proyecto el maestro contiene toda la loacutegica del servicio
21httpmartinfowlercomarticlescontinuousIntegrationhtml
40
trabajos autenticacioacuten y los esclavos son los encargados de la ejecucioacuten ensiacute Jenkins tiene varias viacuteas para aprovisionar los uacuteltimos
Mediante SSH
Interfaz graacutefica
Desarrollar un script propio
Ejecucioacuten de un fichero java
La ventaja de usar planificadores es que el despliegue de esclavos es dinaacutemicoes decir no tener una maacutequina especiacuteficamente configurada para ello DCOS yNomad se encargaraacuten de configurar estos despliegues en sus maacutequinas y poste-riormente eliminarlos Para ello se ha usado la uacuteltima opcioacuten definiendo tareasque descarguen el fichero java Con todo ello se consigue un entorno de inte-gracioacuten continua eficiente que ademaacutes permite la ejecucioacuten de otros servicios deforma independiente
Jenkins permite la creacioacuten de plugins que extienden sus funcionalidadesTanto Nomad22 como Apache Mesos cuentan con uno que permite su integra-cioacuten
Para esta prueba se va a usar el mismo proyecto que para el caso de usode orquestacioacuten de contenedores la aplicacioacuten web al que se le ha antildeadido untest para comprobar que se conecta correctamente a la base de datos medianteMocha un framework de Nodejs Por otro lado se antildeade el plugin de git ya queel coacutedigo se obtiene de GitHub el repositorio remoto de control de versiones delproyecto
El proceso general de ejecucioacuten seriacutea como sigue
1 Se ejecuta el maestro de Jenkins como tarea Docker partiendo de la imagenoficial
2 Al arrancar un trabajo se manda una tarea a los planificadores que laasignaraacuten a un nodo cliente Esta tarea consiste en la descarga del ficherode configuracioacuten Java y arrancarlo configurando el equipo como un clientede Jenkins temporalmente
3 Jenkins ejecuta el trabajo en el nuevo cliente en este caso iniciar la apli-cacioacuten web iniciar las pruebas y generar un informe
4 Se elimina el cliente
A continuacioacuten se detallan los matices de cada herramienta a la hora de imple-mentar este servicio
22Desarrollado por Ivo Verberk httpwwwivoverberknl
41
623 Jenkins con Nomad
El plugin permite la ejecucioacuten del fichero Java mediante dos controladorescontenedores Docker y Java En este proyecto nos hemos decantado por el pri-mero ya que nos ahorra instalar la maacutequina virtual de java en todos los nodoscliente Por ello se ha construido un contenedor base con Java para la ejecucioacutendel fichero de configuracioacuten y Nodejs para lanzar la aplicacioacuten web
El plugin se configura con la direccioacuten IP del cluster y el contenedor queejecuta el esclavo Jenkins Por su parte el trabajo en Jenkins se define conel repositorio en GitHub donde se aloja el coacutedigo del proyecto a probar y loscomandos a ejecutar en este caso npm update y npm test
624 Jenkins con DCOS
En el caso de DCOS su sistema de paquetes incluye Jenkins por lo queal instalarlo ya se tiene la configuracioacuten de Mesos totalmente funcional Sinembargo para ejecutar la aplicacioacuten en particular y las pruebas se requiere deNodejs en los equipos esclavos por ello debemos antildeadir un plugin de Jenkinsque permite instalar este entorno antes de ejecutar el trabajo Una vez hechoesto soacutelo queda definir la tarea igual que en el caso anterior
Cabe destacar que Mesosphere tambieacuten ha desarrollado un plugin que per-mite hacer despliegues en Marathon de tal manera que permitiriacutea con cadacommit del coacutedigo compilar la imagen del contenedor Docker y desplegarlaautomaacuteticamente aunque en este proyecto no se ha hecho pruebas de esta fun-cionalidad
42
7 Escalando la infraestructura
Uno de los factores clave que se busca a la hora de implementar sistemasdistribuidos es el poder escalar la infraestructura de forma maacutes sencilla estoes detectar que las maacutequinas estaacuten alcanzando el liacutemite de su capacidad yaumentar eacutesta ya sea mejorando sus caracteriacutesticas teacutecnicas o antildeadiendo maacutesnodos al cluster
El coacutedigo y todos los ficheros de configuracioacuten de esta seccioacuten tambieacuten sepueden encontrar en el repositorio del proyecto en GitHub23
71 Disentildeo
Microsoft Azure permite organizar los servicios cloud de forma loacutegica a traveacutesde grupos de recursos y asiacute poder crear o eliminar eacutestos en conjunto parauna aplicacioacuten determinada (por ejemplo una aplicacioacuten web suele requerir demaacutequinas virtuales bases de datos almacenamiento) Ademaacutes dispone dela opcioacuten de crear plantillas en formato JSON que permite al desarrolladordefinir los recursos y su interrelacioacuten para desplegar de forma automaacutetica unainfraestructura TI en la nube
Azure tambieacuten ofrece la posibilidad de monitorizar el estado de las maacutequinasvirtuales a traveacutes de extensiones lo que permite configurar el escalado automaacute-tico al alcanzar cierto liacutemite definido por el operador Eacutesta es a priori la formaen que deberiacutea implementarse hablando en teacuterminos de eficiencia sin embargoesta aproximacioacuten es totalmente dependiente de la plataforma es decir no sepuede extrapolar a otro proveedor o sobre recursos propios sin realizar un nue-vo disentildeo En este proyecto las tareas que son ejecutadas por estos equipos notienen estado ya que todo lo relativo a la persistencia lo hemos asignado fueradel cluster esto permite escalar la plataforma a traveacutes de otra aproximaciones
Las plantillas aceptan una serie de variables a indicar por el usuario entreotras los conjuntos de escala para definir los nodos aceptan una variable quedefine el nuacutemero de maacutequinas que los componen Por otro lado Azure ofreceuna API REST y kits de desarrollo software (SDK por sus siglas en ingleacutes) quepermiten su despliegue de forma programaacutetica Aprovechando estas facilidadesen este proyecto se va a aproximar la escalabilidad con el sucesivo desplieguede la infraestructura de forma automaacutetica se monitorizan los equipos y si sedetecta una maacutequina excesivamente cargada se aumenta el nuacutemero de equiposen la plantilla y se vuelve a desplegar
23httpsgithubcomAntonioAlfrzCloud-Orchestrators
43
En este proyecto se han disentildeado las plantillas para desplegar la arquitec-tura necesaria tanto de Nomad como de DCOS En el caso de la primera eldespliegue es maacutes descriptivo ya que incluye maacutequinas virtuales grupos de se-guridad redes En el caso de DCOS Azure cuenta con un servicio especiacuteficopara clusters gobernados por DCOS denominado Azure Container Service queincluye los componentes necesarios y la instalacioacuten ya realizada
72 Implementacioacuten
En primer lugar para monitorizar el estado de los equipos se va a usar laherramienta Nagios un sistema que permite controlar el estado del hardwarey los servicios de un equipo Se trata de una herramienta muy completa de laque se va a usar su capacidad para ejecutar comandos (plugins) en los nodospara detectar picos de carga generar alertas y ejecutar programas para estoseventos
Se ha desplegado una maacutequina virtual con esta herramienta en ambos siste-mas y se ha instalado una extensioacuten de Nagios (Nagios Remote Plugin Executor)en todos los nodos que permite ejecutar comprobaciones remotamente en con-creto para esta prueba de concepto medir el nivel de saturacioacuten de la unidadcentral de procesamiento (CPU por sus siglas del ingleacutes) Cuando sucede uncambio de estado de una maacutequina esto es cuando este paraacutemetro supera el liacutemi-te definido por el operador Nagios permite actuar en consecuencia ejecutandoprogramas por ello se ha desarrollado un script que ejecuta lo siguiente
Un programa desarrollado en Python con el SDK de Azure que modificalas plantillas y despliega los recursos
Un guioacuten de Ansible para instalar todos los componentes necesarios en lasnuevas maacutequinas y arrancar de nuevo el cluster y las aplicaciones
44
8 Resultados y conclusiones
En este uacuteltimo apartado se da una visioacuten global del proyecto asiacute como a lasconclusiones maacutes importantes a las que se ha llegado y posibles temas futurosde desarrollo
81 Comparacioacuten
Ambas herramientas ofrecen las funcionalidades para gestionar los recursoseficientemente ofreciendo a los desarrolladores una plataforma donde desplegarsus aplicaciones de forma distribuida independientemente de los equipos fiacutesicosy el hardware que las soporten
DCOS es una herramienta que en un comienzo fue privativa pero cuyos res-ponsables la empresa Mesosphere decidieron publicar una versioacuten de coacutedigoEacutesta nos permite gestionar un cluster de una forma sencilla y usable ademaacutes decomplementarlo con otras herramientas como el balanceador de carga integradoo la autenticacioacuten de usuarios ademaacutes estaacute basada en Apache Mesos un pro-yecto de relativa madurez y con el soporte de la Apache Software FoundationDe forma resumida DCOS ofrece muchas posibilidades y servicios a cambiode una arquitectura e instalacioacuten maacutes compleja
Por su parte HashiCorp con menor tiempo de desarrollo ha conseguidouna herramienta muy sencilla de desplegar que ademaacutes cumple con todas lasfuncionalidades baacutesicas ejecutando un simple binario en cada nodo se puededesplegar un gestor de clusters totalmente funcional Sin embargo no cuentacon todas las posibilidades de Mesos (Nomad cuenta con menos controladoresque entornos posibles de Mesos) ni con los antildeadidos de DCOS lo que implicael uso de otras herramientas para complementar el servicio (Consul HAProxy)
De entre las dificultades encontradas al usar estas herramientas y desplegaraplicaciones sobre ellas se puede destacar la depuracioacuten en ocasiones se desco-noce si un error viene de la propia herramienta de la aplicacioacuten desplegada o delequipo fiacutesico si no se cuenta con un sistema de procesamiento de registro unose puede encontrar con muacuteltiples terminales abiertas inspeccionando numerososficheros de registro buscando posibles errores Ademaacutes no dejan de ser solucio-nes que para usar eficientemente se debe conocer parte de su funcionamientoy sintaxis a la hora de describir la tareas lo que supone un esfuerzo antildeadido yaque cada una tiene sus particularidades y liacutemites
45
82 Conclusiones
En una sociedad cada vez maacutes digital las empresas deben adaptarse a unmercado cuya demanda de contenido no deja de crecer Las nuevas arquitecturascomo microservicios asiacute como la gran cantidad de datos generada implica queuna mejor gestioacuten de los recursos y la rapidez para desplegar o escalar solucionesdando valor al cliente lo maacutes raacutepido posible es uno de los objetivos de todas lasempresas de base tecnoloacutegica
Las ventajas que ofrecen los planificadores con aplicaciones distribuidas sonnumerosas sin ir maacutes lejos empresas tan punteras como Google llevan maacutesde 10 antildeos orquestando contenedores24 Por un lado permiten aumentar elrendimiento de los equipos propios y por otro implementar un servicio comoplataforma para despliegues distribuidos sobre cualquier conjunto hardware deesta forma se provee un servicio similar al de la nube puacuteblica pero con laprincipal diferencia de que se elimina la independencia con el proveedor (vendorlock-in) esto es las aplicaciones no tienen limitaciones impuestas por eacuteste talescomo lenguaje de programacioacuten o herramientas y permite despliegues hiacutebridosentre recursos propios y la nube
83 Objetivos conseguidos
Implementacioacuten de los planificadores propuestos en la nube Se ha en-tendido y detallado el funcionamiento de estas herramientas y se hanimplementado en el servicio de infraestructura de Microsoft Azure
Despliegue de aplicaciones y servicios distribuidos Servicios que se usanactualmente en la industria del desarrollo software asiacute como una aplica-cioacuten web con una arquitectura moderna han sido desplegados de formadistribuida en los equipos cumpliendo con la funcionalidad esperada ade-maacutes de consiguiendo una alta disponibilidad
Aproximacioacuten de arquitectura escalable Se ha hecho una aproximacioacutende infraestructura escalable de forma que sea parcialmente extrapolable aotros proveedores
24httpwwwnextplatformcom20160322decade-container-control-google
46
84 Liacuteneas de investigacioacuten
Siguiendo con la materia de este proyecto se presentan posibles liacuteneas deinvestigacioacuten
Analizar el despliegue con estas herramientas de aplicaciones de Big Datay comparar la eficiencia con respecto a soluciones especializadas
Analizar el rendimiento de los algoritmos de planificacioacuten antes pruebasde estreacutes y situaciones de alta contienda
Comparar el uso de estas herramientas con las praacutecticas actuales de laindustria o implementacioacuten en un sistema de produccioacuten real
47
Referencias
[1] LA Barroso y U Houmllzle laquoThe Datacenter as a Computer An Introduc-tion to the Design of Warehouse-Scale Machinesraquo En Morgan amp ClaypoolPublishers ()
[2] Systems Research Group ndash NetOS (University of Cambridge) The evolu-tion of cluster scheduler architectures 2016 url httpswwwclcamacukresearchsrgnetoscamsasblog2016-03-09-scheduler-architectureshtml
[3] A Das I Gupta y A Motivala SWIM Scalable Weakly-consistent Infection-style Process Group Membership Protocol Inf teacutec Dept of ComputerScience Cornell University url https www cs cornell edu ~asdasresearchdsn02-swimpdf
[4] D Dubhashi y A Das Mastering Mesos PACKT Publishing mayo de2016
[5] The Apache Software Foundation Apache Mesos documentation urlhttpsmesosapacheorg
[6] David Greenberg Building Applications on Mesos OrsquoReilly Media 2016[7] Armand Grillet Comparison of Container Schedulers Inf teacutec Technische
Universitaumlt Berlin[8] HashiCorp Consul documentation url httpswwwconsulio[9] HashiCorp Nomad documentation url httpsdcosio[10] Dan C Marinescu Cloud computing theory and practice Morgan Kauf-
mann 2013[11] Mesosphere DCOS documentation url httpswwwnomadproject
io[12] Microsoft Azure documentation url httpsazuremicrosoftcom
es-esdocumentation[13] D Ongaro y J Ousterhout In Search of an Understandable Consensus
Algorithm Inf teacutec Stanford University url httpsraftgithubioraftpdf
[14] Fei Teng laquoRessource allocation and schelduling models for cloud compu-tingraquo Tesis de mtriacutea Ecole Centrale Paris 2011
[15] A Williams y col Automation and Orchestration with Docker and Contai-ners A Comprehensive Overview of the Docker and Container Ecosystem3 The New Stack 2016
48
- Resumen
- Summary
- Iacutendice de figuras
- Introduccioacuten y objetivos
-
- Contexto
- Objetivos
- Estructura del documento
-
- Cloud Computing
- Nuevas cargas de trabajo
- Gestioacuten de recursos Planificadores
-
- Sistemas distribuidos
-
- Clasificacioacuten
-
- Herramientas
-
- DCOS
-
- Apache Mesos
- Ejemplos de uso
-
- Nomad
-
- Protocolo de consenso Raft
- Protocolo gossip SWIM
- Planificacioacuten
-
- Casos de uso y despliegue
-
- Aplicacioacuten Web
-
- DCOS
- Nomad
-
- Servicio de integracioacuten continua
-
- DevOps
- Integracioacuten Continua
- Jenkins con Nomad
- Jenkins con DCOS
-
- Escalando la infraestructura
-
- Disentildeo
- Implementacioacuten
-
- Resultados y conclusiones
-
- Comparacioacuten
- Conclusiones
- Objetivos conseguidos
- Liacuteneas de investigacioacuten
-
Docker
Proyecto de coacutedigo abierto que facilita y automatiza el despliegue de aplica-ciones al encapsular el entorno de trabajo en contenedores Linux una tecnologiacuteaque permite a un sistema fiacutesico ejecutar muacuteltiples instancias de sistemas opera-tivos aislados mediante entornos virtuales con sus propios espacios de procesosy redes pero compartiendo el nuacutecleo (kernel) con el equipo anfitrioacuten
En la figura 2 se compara la pila de una virtualizacioacuten tradicional con res-pecto a los contenedores no se simula el sistema operativo por lo que el procesoes mucho maacutes ligero
Docker se caracteriza por
Autosuficiencia Los contenedores cuentan con las libreriacuteas y configuracio-nes necesarias para ejecutarse de manera autoacutenoma al compartir el nuacutecleo
Portabilidad El hecho de que sean autosuficientes implica que es inde-pendiente del host es decir se puede desplegar en cualquier equipo quesoporte esta tecnologiacutea
Tamantildeo El peso de un contenedor es sustancialmente inferior a otrastecnologiacuteas de virtualizacioacuten
Figura 2 Arquitectura DockerFuente httpsdockercom
6
Los componentes fundamentales de esta herramienta son
Imaacutegenes Describen el entorno de base sobre el que ejecutar el contene-dor por ejemplo la imagen del sistema operativo Ubuntu Sobre eacutesta seconstruyen las aplicaciones particulares del usuario dando lugar a otraimagen
Contenedores Se crean a partir de las imaacutegenes y comprenden todo aquellonecesario para arrancar la aplicacioacuten decir su entorno de ejecucioacuten
bull Voluacutemenes Encargados de gestionar la persistencia de datos e inde-pendientes del ciclo de vida del contenedor
Registros Pueden ser puacuteblicos o privados y almacenan las imaacutegenes elregistro puacuteblico oficial de Docker es Docker Hub
Dadas estas caracteriacutesticas los profesionales TI estaacuten comenzando a adoptarDocker ya que facilita tanto los despliegues como el trabajo compartido en dis-tintos entornos Sin embargo esto requiere de un software que permita desplegarlos distintos contenedores de forma que puedan trabajar en conjunto procesoque se ha denominado orquestacioacuten de contenedores
7
4 Gestioacuten de recursos Planificadores
Para sacar el maacuteximo provecho a las tecnologiacuteas anteriormente descritaslo ideal es desplegarlas en sistemas distribuidos sin embargo esto aumenta lacomplejidad del propio despliegue asiacute como la necesidad de software especiali-zado para ello Se necesitan algoritmos de planificacioacuten que permitan obtener elmaacuteximo rendimiento de los recursos por un lado y dar ciertas garantiacuteas de quetodas las tareas y procesos se van a ejecuta por otro
41 Sistemas distribuidos
En primer lugar se definen los sistemas distribuidos o clusters como unconjunto de ordenadores conectados entre siacute cuyo objetivo es trabajar como unauacutenica instancia de gran capacidad5
Su clasificacioacuten variacutea de acuerdo a cada autor pero en general se puedendividir seguacuten su objetivo en alto rendimiento aquellos cuyo objetivos es proveerde gran capacidad de coacutemputo gracias al conjunto de los nodos y alta disponi-bilidad con los cuales se busca la fiabilidad del sistema mediante redundanciayo balanceo de carga
El intereacutes de este proyecto recae en los uacuteltimos ya que el objetivo es porun lado ofrecer al desarrollador un entorno donde desplegar sus aplicaciones deforma distribuida y por otro maximizar el rendimiento de los recursos
De forma general las caracteriacutesticas que se buscan son las siguientes
Elasticidad Adaptacioacuten a cargas dinaacutemicas de trabajo aumentando (o dis-minuyendo) recursos de manera automaacutetica de tal forma que la utilizacioacutensea lo maacutes cercana a la demanda
Disponibilidad Capacidad de un sistema para mantener el servicio fun-cional
Tolerancia a fallos Recuperacioacuten del servicio ante el fallo de un compo-nente
Balanceo de carga Compartir las tareas entre las diferentes maacutequinasredundadas evitando asiacute puntos de uacutenico fallo
5httpsenwikipediaorgwikiComputer_cluster
8
Los programas que se implementan en entornos distribuidos se caracterizanpor ejecutarse de forma concurrente en equipos independientes estar conectadospor una red que introduce fallos aleatorios y no compartir memoria ni reloj Estoimplica entre otras cosas que
Los nodos soacutelo tienen un acceso raacutepido a su memoria local por lo quecualquier informacioacuten relativa al estado global puede ser potencialmenteerroacutenea
Las maacutequinas pueden sufrir caiacutedas de forma aleatoria
El intercambio de informacioacuten puede fallar ya sea por error en transmisioacuteno por caiacuteda de los nodos
Estas dificultades se ponen de manifiesto en el teorema de CAP en cienciasde la computacioacuten el teorema de CAP que lanzado inicialmente como conjetu-ra en el antildeo 2000 por Eric Brewer (motivo por el cual al teorema se le conoceformalmente como teorema de Brewer) y posteriormente demostrado en el antildeo20026 establece que es imposible para un sistema de coacutemputo distribuido ga-rantizar simultaacuteneamente dos de las tres propiedades siguientes
Consistencia (Consistency) es decir que todos los nodos vean la mismainformacioacuten al mismo tiempo Se busca que un cambio en el sistema soacutelose ejecute satisfactoriamente si y soacutelo si se efectuacutea a todos las maacutequinasde tal forma que los datos entre ellos nunca difieren y la respuesta a unapeticioacuten sea la misma independientemente del nodo que la atienda
Disponibilidad (Availability) esto es la garantiacutea de que toda peticioacuten debeobtener una respuesta (servicio funcional) aunque exista inconsistenciaentre nodos
Tolerancia al particionado (Partition Tolerance) es decir que el sistemasiga funcionado a pesar de un fallo en la comunicacioacuten entre los equipos
Por todo lo expresado anteriormente conseguir un sistema distribuido capazde ofrecer procesamiento de forma transparente implica una arquitectura TIcompleja Se requieren de subsistemas y herramientas que permitan la cohesioacutenentre todos los nodos
Gestor de los recursos de las diferentes maacutequinas
Monitorizacioacuten tanto de los servicios activos como de la funcionalidad delsistema ademaacutes de poliacuteticas para recuperacioacuten de fallo
Protocolos de consenso que permitan a los nodos ser consistentes con elestado global del cluster
6urlhttpsgroupscsailmitedutdspapersGilbertBrewer2pdf
9
Herramientas de descubrimiento de servicios que permita la comunicacioacutenentre tareas distribuidas
Planificadores Encargados de distribuir las tareas y procesos en las dife-rentes maacutequinas asignaacutendole parte de su capacidad
Los planificadores del ingleacutes cluster schedulers son un componente funda-mental por lo que vamos a entrar un poco maacutes en detalle en ellos
Planificadores (Cluster Schedulers)
Es el software encargado de monitorizar los recursos usados por cada maacute-quina perteneciente a un cluster y distribuir la carga de trabajo entre ellas deacuerdo a un poliacutetica o reglas
Este tipo de herramientas comparten cierta terminologiacutea que es relevantedefinir
Tarea Unidad de trabajo computacional comprendida por una secuenciade instrucciones datos de entrada y recursos asociados Por ejemplo laejecucioacuten de un comando o el arranque de una base de datos
Nodo Cualquier maacutequina integrante de un cluster En una arquitecturamaestro-esclavo se definen dos roles
bull Cliente Agente Esclavo Aquellos ordenadores que se encargan deejecutar las tareas
bull Maestro Servidor Su objetivo es mantener el estado del cluster ygestionar sus recursos
411 Clasificacioacuten
A lo largo de los uacuteltimos antildeos se han desarrollado diferentes tipos de plani-ficadores[2]
Monoliacutetico
Un solo planificador que se encarga de distribuir todas las tareas entran-tes La mayoriacutea de los planificadores en computacioacuten de alto rendimiento asiacutecomo Borg desarrollado por Google son de este tipo En la figura 3 se pue-de observar de forma graacutefica el procedimiento siendo las cajas grises maacutequinaspertenecientes al cluster y los ciacuterculos las tareas a asignar
10
Figura 3 Planificador monoliacuteticoFuente httpswwwclcamacuk
Planificacioacuten de dos niveles
La mayoriacutea de los clusters ejecutan aplicaciones con distintas necesidadesdesde procesos casi instantaacuteneos hasta servicios persistenteslo que implica dis-tintas necesidades de recursos
Por ello la planificacioacuten a dos niveles distingue dos funciones la gestioacutende recursos (gestor) y la disposicioacuten de las tareas (planificador) Cada serviciotiene su propio planificador de tal manera que el gestor les ldquoofertardquo recursosde acuerdo a una poliacutetica y los planificadores se encargan de escoger la maacutesadecuada Esto permite que el proceso de distribucioacuten sea maacutes acorde con lasnecesidades de los diferentes servicios Apache Mesos que detallaremos maacutesadelante sigue este esquema
Como desventaja cabriacutea sentildealar que esta programacioacuten implica que los pla-nificadores pierden la vista general de la infraestructura y las tareas soacutelo puedenejecutarse con los recursos que les son ofrecidos lo que dificulta la implementa-cioacuten de prioridades de ejecucioacuten de tareas entre otras
Figura 4 Planificador de dos niveles
11
Planificacioacuten de estado compartido
Muacuteltiples reacuteplicas del estado del cluster se actualizan independientementepara cada planificador como se observa en la figura 5 cuando sucede un cambiode forma local el planificador se encarga de informar al resto
Ejemplo de este tipo son Omega la evolucioacuten de Borg por parte de GoogleMicrosoft Apollo y Nomad que usaremos para los casos de uso
De entre las desventajas se puede destacar el hecho de que en general losnodos trabajan con informacioacuten desactualizada lo que conlleva una degradacioacutendel rendimiento en situaciones de alta contienda
Figura 5 Planificador de estado compartido
Planificacioacuten distribuida
En este caso no existe coordinacioacuten entre los distintos planificadores Cadauno de ellos funciona con su propia vista del cluster Las tareas pueden serorganizadas por cualquiera de ellos y desplegadas en cualquier parte del clusteren base a la aleatoriedad y multiplexacioacuten estadiacutestica de los flujos de trabajosin ninguacuten control central
Figura 6 Planificador distribuido
12
5 Herramientas
En la industria comienzan a aparecer soluciones software de coacutedigo abiertoque aglutinan los servicios necesarios para gestionar la infraestructura TI de ma-nera maacutes eficaz El objetivo es doble se busca facilitar la gestioacuten de los recursosde computacioacuten para organizaciones con instalaciones propias mediante su usocon un enfoque cloud esto es desplegar aplicaciones a traveacutes de un conjuntode ordenadores de forma transparente y sin tener en cuenta la infraestructurasubyacente o aprovechar el maacuteximo rendimiento de la infraestructura de losproveedores cloud puacuteblicos de forma que se tiene el maacuteximo control sobre eacutestapero no se depende de las soluciones propietarias permitiendo asiacute despliegueshiacutebridos
Entre estas herramientas se pueden destacar
OpenStack Proyecto desarrollado por la fundacioacuten del mismo nombre paraproporcionar servicios de infraestructuras (IaaS) basado en componentesque se comunican a traveacutes de APIs El componente Magnum incluye mo-tores de orquestacioacuten de contenedores
Kubernetes Sistema de orquestacioacuten de contenedores Docker creado por Goo-gle
CoreOs Sistema operativo basado en Linux disentildeado para despliegues distri-buidos sobre contenedores incluyendo mecanismos de descubrimiento deservicio y comparticioacuten de configuracioacuten
Docker Swarm Herramienta nativa de orquestacioacuten de contenedores Docker
YARN Entorno de gestioacuten de recursos y aplicaciones distribuidas de Hadoopuna libreriacutea software de procesamiento de grandes conjuntos de datos
Como podemos observar existe un gran rango de opciones para gestionar lainfraestructura desde un bajo nivel como puede ser OpenStack hasta Kuberne-tes o Docker Swarm que ofrecen exclusivamente orquestacioacuten de contenedores
En este trabajo se ha optado por Mesosphere DCOS y HashiCorp Nomadque se encuentran en el teacutermino medio su objetivo es proporcionar serviciosde plataforma que permitan la coexistencia dediferentes cargas de trabajo en elcluster
13
51 DCOS
DCOS es un proyecto de coacutedigo abierto7 creado y desarrollado por la empre-sa Mesosphere Se describe como un sistema operativo distribuido que abstraelos recursos de un cluster (capacidad de procesamiento memoria) permite lagestioacuten de muacuteltiples ordenadores de forma transparente y simplifica la instala-cioacuten de aplicaciones distribuidas
Su arquitectura se puede comparar a la de Linux en teacuterminos de nuacutecleo(kernel) y espacio de usuario El primero consta de recursos protegidos a losque no puede acceder el usuario e involucra operaciones de bajo nivel comoasignacioacuten de recursos o aislamiento de procesos En el espacio de usuario seejecutan las aplicaciones y servicios de maacutes alto nivel
Siguiendo con este siacutemil el nuacutecleo de DCOS estaacute basado en Apache Mesosque se explicaraacute en un apartado posterior y el espacio de usuario que estaacute com-prendido por los componentes del sistema esto es las diferentes herramientasque en conjunto conforman DCOS y los servicios encargados de planificar yejecutar las aplicaciones y tareas del usuario
Figura 7 Arquitectura DCOSFuente httpsdcosio
De entre los componentes que conforman DCOS destacan
Admin Router Balanceador de carga central basado en NGINX que dis-pone un proxy entre todos los servicios en el puerto 80 permitiendo sugestioacuten mediante la interfaz graacutefica Ademaacutes se encarga de la autenticacioacutenpara acceder al panel de administracioacuten
Cosmos Gestor de paquetes de las aplicaciones
Diagnostics Se ejecuta en todos los nodos y se encarga de monitorizar elestado de los daemons que sustentan DCOS
7Desde abril de 2016 httpsmesospherecomblog20160419open-source-dcos
14
Exhibitor Gestiona y automatiza el despliegue de ZooKeper la herra-mienta que provee de configuracioacuten centralizada y registro de nombres
Marathon Equivale al proceso init de los sistemas tipo Unix esto es elprimer proceso en ejecucioacuten tras la carga del kernel y que genera los demaacutesprocesos Se encarga de arrancar y monitorizar las aplicaciones y servicios
Mesos-DNS Servicio de DNS interno que define el dominio mesos pa-ra nodos y tareas en el cluster es decir permite resolver nombres conindependencia de la direccioacuten fiacutesica
Minuteman Balanceador de carga integrado a nivel TCPUDP disponiblepara las propias aplicaciones
Por otra parte se definen como servicios a las diferentes aplicaciones dis-tribuidas que DCOS permite instalar en el cluster y que pueden haber sidodesarrollados por la misma empresa Mesosphere o por terceros por ejemploApache Spark Jenkins o Apache Hadoop En la figura 8 se muestra un diagramade los servicios disponibles incluyendo algunos de las aplicaciones distribuidasque soporta DCOS
Figura 8 Servicios DCOSFuente httpsdcosio
511 Apache Mesos
El nuacutecleo de DCOS estaacute basado en Apache Mesos un proyecto de coacutedigoabierto creado por la Universidad de California Berkeley y desarrollado actual-mente por la fundacioacuten Apache Se trata de un administrador de clusters queabstrae los recursos y los dispone para diferentes aplicaciones y entornos de tra-bajo distribuidos (frameworks) mediante una interfaz comuacuten En el momento deredaccioacuten de este proyecto Apache Mesos soportaba una variedad de entornosque abarcaba desde Big Data (Apache Spark Hadoop) hasta bases de datos(Cassandra Hypertable)
15
Arquitectura
Mesos se basa en la asignacioacuten de dos roles diferentes a los nodos
Maestros (Masters) Se encargan de la gestioacuten y reparticioacuten de los recursospara los diferentes entornos de trabajo mediante ldquoofertas de recursosrdquo deacuerdo a los disponibles y a la poliacutetica de asignacioacuten (planificacioacuten en dosniveles)
Esclavos (Slaves) Ordenadores donde se ejecutaraacuten las aplicaciones y cu-yos recursos son ofertados por los maestros
En el caso de fallo del maestro las tareas pueden seguir ejecutaacutendose perono se podraacute asignar nuevos recursos ni tareas por ello pueden existir varios enel cluster para configuraciones de alta disponibilidad pero soacutelo uno orquesta alos esclavos
Para la eleccioacuten del master liacuteder Mesos usa Apache ZooKeeper un proyectode software desarrollado por la misma fundacioacuten cuyo objetivo es proveer deun servicio de configuracioacuten centralizado y registro de nombres8
Por otra parte los entornos de trabajo son los programas que deciden final-mente queacute recursos se van a usar y se encargan de que los esclavos ejecuten lastareas Eacutestos se ejecutan sobre Mesos y constan de dos componentes
Planificador (Scheduler) Optimiza y decide los recursos a utilizar de losofertados informando a los Masters
Procesador (Executor) Ejecuta las aplicaciones o servicios en los esclavos
El objetivo final es conseguir una interfaz liviana tolerante a fallos paracualquier tipo de entorno de trabajo de tal manera que en los esclavos del clusterpuedan ejecutarse simultaacuteneamente tareas con necesidades y duracioacuten diferentesPara ello se basa en dos conceptos asignacioacuten y aislamiento de recursos
Asignacioacuten de recursos
En el cluster pueden coexistir entornos de trabajo con tareas de larga dura-cioacuten y con gran consumo de recursos con tareas cortas que los ocupan y liberancon rapidez El maestro integra un moacutedulo de asignacioacuten de recursos (allocationmodule) que se encarga del algoritmo de distribucioacuten
En el momento de escribir este proyecto estaban desarrollados dos moacutedulosuno mediante el cual el usuario puede asignar prioridades y otro que implementa
8httpszookeeperapacheorg
16
el algoritmo Dominant Resource Fairness9 a grandes rasgos se determina entodos los esclavos la tarea en ejecucioacuten que necesita maacutes recursos y se calcula laproporcioacuten del recurso de mayor peso con respecto al total por ejemplo si unatarea ocupa 2 GB de memoria con respecto a 10 GB totales que tiene el clusterse le asigna un dominant share del 20 la tarea se asignaraacute al nodo con menordominant share
Aislamiento de recursos
Para conseguir que tareas de diferentes entornos de trabajo y con distin-ta naturaleza se ejecuten simultaacuteneamente en un mismo nodo Mesos usa loscontenedores Linux (descritos en la seccioacuten 3)
Funcionamiento
La figura 9 muestra el esquema de la arquitectura de Apache Mesos conalta disponibilidad (tres maestros) y con dos entornos de trabajo ejecutaacutendo-se Hadoop que permite el almacenamiento y procesamiento de gran cantidadde datos para proyectos de big data y un sistema que implementa la interfazsistema de paso de mensajes MPI
Como se puede observar el sistema ZooKeeper elige a un solo maestro comoliacuteder y eacuteste orquesta el cluster comunicando los esclavos con los planificadoresde los diferentes entornos de trabajo Tambieacuten se puede observar como las tareasde los distintos entornos estaacuten distribuidas entre los tres esclavos disponibles
Figura 9 Arquitectura de Apache MesosFuente httpsmesosapacheorg
El proceso de asignacioacuten se realiza como sigue en primer lugar un usuariosolicita la ejecucioacuten de una tarea mediante la interfaz de cada entorno de traba-jo (interfaz graacutefica API HTTP ) De forma paralela un esclavo informa almaestro de los recursos que tiene libres En consecuencia eacuteste se lo notifica almoacutedulo de asignacioacuten que en funcioacuten de su configuracioacuten decide cuaacutento ofertar
9httpspeopleeecsberkeleyedu~aligpapersdrfpdf
17
y a queacute entorno de trabajo y enviacutea la oferta a los planificadores Eacutestos respondenal maestro con queacute recursos ha decidido usar para cada tarea Finalmente lastareas son enviadas al esclavo seleccionado el cual asigna los recursos indicadosal procesador (executor) quien finalmente las ejecuta
Cabriacutea pensar que esta metodologiacutea puede conducir a situaciones en lasque un entorno podriacutea quedarse con tareas sin ejecutarse a la espera de unaoferta satisfactoria para ello Mesos implementa un sistema de filtros medianteel cual los entornos especifican los requisitos miacutenimos que debe cumplir unaoferta por ejemplo se puede especificar en queacute nodos debe desplegarse la tareaEste sistema estaacute disentildeado asiacute con el objetivo de mantener lo maacutes transparenteposible esta herramientas de forma que acepte entornos de trabajo de distintasnaturalezas
512 Ejemplos de uso
Grandes empresas estaacuten usando Apache Mesos con eficacia de acuerdo a susnecesidades e infraestructuras Caben destacar
Ebay En el modelo de implementacioacuten continua en esta empresa10 cadadesarrollador cuenta con su propia instancia que se ejecuta en una maacutequinavirtual dedicada lo que ha conllevado un uso de los recursos poco eficiente Enuna prueba de concepto consiguieron realizar una herramienta de integracioacutencontinua distribuida basada en un cluster con Apache mesos y con el entornoMarathon y Jenkins
Apple Anuncioacute que el motor de su famosa herramienta de asistencia per-sonal para iPhones Siri estaacute desplegada sobre Apache Mesos11 Para ello handesarrollado su propio entorno para facilitar a los ingenieros a desplegar los ser-vicios que la herramienta necesita para resolver las peticiones de los usuarios
Twitter Desarrolloacute su propio entorno denominado Aurora y actualmentegestionan sus recursos y miden el coste de las tareas que los empleados usancon el objetivo de que sean conscientes del gasto que puede suponer un usoinadecuado de la infraestructura12
10httpwwwebaytechblogcom20140404delivering-ebays-ci-solution-with-apache-mesos-part-i11httpwwwbusinessinsidercomapple-siri-uses-apache-mesos-2015-812httpswwwlinuxcomNEWS4-UNIQUE-WAYS-UBER-TWITTER-PAYPAL-AND-HUBSPOT-USE-APACHE-MESOS
18
52 Nomad
Herramienta de coacutedigo abierto de gestioacuten de clusters creada y desarrolladapor Hashicorp13 que permite el despliegue de aplicaciones y procesos de formadistribuida
Las principales diferencias con Apache Mesos a grandes rasgos son
Arquitectura maacutes ligera Nomad soacutelo requiere de un fichero para funcionarejecutaacutendolo con las correspondientes configuraciones en todos los nodosrealiza las funciones de gestioacuten del cluster eleccioacuten de liacuteder planificacioacutende recursos y ejecucioacuten de las tareas
Centro de datos y regiones muacuteltiples Su arquitectura estaacute orientada afacilitar la gestioacuten de diferentes centros de datos geograacuteficamente distri-buidos
Entorno de ejecucioacuten Las tareas se definen y son interpretadas mediantecontroladores integrados en Nomad que se valen de los recursos y herra-mientas de los nodos clientes para ejecutarlas Esta integracioacuten dificultael desarrollo de controladores por parte de terceros a diferencia de Mesosque delega dicha responsabilidad en los entornos de trabajo externos alproyecto
Usa un planificador de estado compartido con respecto a la planificacioacutenen dos niveles de Mesos
Antes de entrar en maacutes detalle en la arquitectura es importante definir lossiguientes teacuterminos
Controlador (Driver) Software que se encarga de interpretar las definicionesde las tareas y ejecutarlas semejante a los procesadores de los entornosde trabajo de Mesos A la hora de redactar este proyecto Nomad contabacon controladores para contenedores Docker virtualizacioacuten de maacutequinasmediante el emulador QEMU aplicaciones java y archivos binarios
Grupo de trabajo (Task Group) Conjunto de tareas que se ejecutan en elmismo nodo cliente
Trabajo (Job) Conjunto loacutegico de tareas y grupos de trabajo que se despliegana la vez
Asignacioacuten (Allocation) Relacioacuten entre un grupo de trabajo y el cliente don-de se ejecuta
Evaluacioacuten (Evaluation) Proceso mediante el cual Nomad planifica y ges-tiona el registro o actualizaciones de los trabajos
13httpswwwhashicorpcom
19
Nomad sigue una arquitectura maestro-esclavo similar a la de Apache Mesosmuacuteltiples servidores acuerdan entre siacute un liacuteder que gestiona la planificacioacuten detareas en los clientes que soacutelo conocen sus asignaciones y las ejecutan
Todos los servidores participan paralelamente en tareas de planificacioacuten derecursos y asignacioacuten de tareas y ademaacutes entre ellos eligen un liacuteder que seencarga de la coordinacioacuten de la suscripcioacuten de los clientes al cluster y de lagestioacuten de las peticiones
Los clientes estaacuten configurados para comunicarse con el servidor usando lla-madas a procedimiento remoto (RPC por sus siglas en ingleacutes) que permite unordenador ejecutar coacutedigo en otra maacutequina Mediante esta tecnologiacutea los nodosclientes avisan de su estado e informa de sus asignaciones recursos y controla-dores disponibles
Existe la posibilidad de gestionar varios centros de datos agrupados en regio-nes eacutestas son independientes pero permite definir tareas o comprobar el estadode todas ellas desde cualquier punto A continuacioacuten se muestra una figura dela arquitectura a alto nivel de esta configuracioacuten
Figura 10 Arquitectura multi-regioacuten en NomadFuente httpswwwnomadprojectio
La herramienta se sustenta sobre tres protocolos fundamentales un protocolode consenso entre los servidores para compartir informacioacuten sobre su estado yel liacuteder un protocolo Gossip para la gestioacuten entre regiones y el planificador detareas
521 Protocolo de consenso Raft
El objetivo es obtener consistencia en un conjunto de nodos que comparteninformacioacuten es decir si un cliente realiza un cambio que todos los nodos veanla misma informacioacuten a la vez y ademaacutes sea tolerante a fallos Para ello se basaen el algoritmo Raft[13] que se detalla brevemente a continuacioacuten
20
Los nodos participantes en el algoritmo pueden estar en tres estados
Liacuteder (Leader) Todos los cambios que realicen en el cluster pasan por eacutel pri-mero
Seguidor (Follower) Nodo pasivo cuya responsabilidad es responder a laspeticiones del nodo liacuteder
Candidato (Candidate) Maacutequina que no ha encontrado liacuteder y solicita sueleccioacuten
Supongamos que tenemos cinco equipos que acaban de arrancar el protocoloEn la figura 11 se observan los nodos y sus respectivos registros a la derecha
Figura 11 Equipos sin consenso ejecutando el protocolo RAFTFuente httpsgithubcomongardieraftscope
Al comenzar todos los nodos son seguidores esperando recibir comunicacioacutende un nodo que actuacutee como liacuteder Cada nodo tiene un tiempo de espera aleatoriodespueacutes del cual si no es informado por un liacuteder pasa a estado candidato y pideel ldquovotordquo al resto de los participantes El algoritmo divide el tiempo en plazos uncandidato pasa a liacuteder si recibe la mayoriacutea de los votos en un plazo determinadoSe define mayoriacutea o cuoacuterum (quorum) comolceil
N2rceil
+ 1 (1)
donde N representa el nuacutemero de nodos
Para el ejemplo propuesto de 5 equipos se requieren de 3 votos Soacutelo losnodos que se encuentren en estado seguidor pueden votar una uacutenica vez a laprimera solicitud que reciba dentro de un plazo
Supoacutengase que el nodo denotado con S1 ha cumplido su tiempo de espera yrealiza la peticioacuten de voto (figura 12) A partir de este momento se pueden dartres casos
La maacutequina gana la eleccioacuten y pasa a ser liacuteder informando al resto
Otro servidor se establece como liacuteder en el mismo momento
Varios nodos pasan a ser candidatos por lo que ninguno consigue los votos
21
Figura 12 Un equipo pasa a estado candidato (RAFT)
Si un candidato recibe un aviso de un liacuteder en el mismo plazo el primeropasa a ser seguidor y se acaba la eleccioacuten de liacuteder
Por otro lado si un equipo candidato no recibe los votos en el plazo y agotasu tiempo de espera avanza al siguiente plazo y repite el proceso de votacioacutenLa tercera posibilidad puede conllevar a un estado indefinido ya que varioscandidatos pueden agotar su tiempo de espera al mismo tiempo y repartir losvotos Para solventarlo el algoritmo establece tiempos de espera aleatorios paralos candidatos
Siguiendo con el ejemplo propuesto el servidor S1 pasa a ser el liacuteder Cadacierto tiempo eacuteste debe realizar avisos a los nodos seguidores para no agotar sutiempo de espera
En este momento el cluster de servidores estaacute en ldquoconsensordquo y la informacioacutenen todos los nodos estaacute actualizada Un cambio en la informacioacuten inicia unproceso de replicacioacuten el liacuteder registra el cambio lo pasa al resto de nodos yuna vez eacutestos responden el cambio se hace efectivo
Supoacutengase que se realiza un cambio en los datos en la figura 13 en la partederecha se observa el cambio en el registro del servidor S1 que informa a losnodos seguidores En consecuencia los nodos registran el cambio y responden aS1
Figura 13 Cambio en un registro (RAFT)
Una vez el cuoacuterum (en el ejemplo tres equipos) informa al liacuteder de que
22
ha registrado el cambio el liacuteder lo hace efectivo en su sistema y notifica a losnodos que hacen lo mismo En la figura 14 el enviacuteo todaviacutea no ha llegado ala maacutequina S3 y se observa que no ha hecho efectivo el cambio (en el registroaparece punteado)
Figura 14 Aprobacioacuten del resto de equipos (RAFT)
Este protocolo funcionaraacute correctamente mientras exista un nuacutemero de nodosen funcionamiento igual o superior al cuoacuterum en el ejemplo propuesto elcuoacuterum es tres por lo que el sistema puede tolerar la caiacuteda de dos de los equipos
522 Protocolo gossip SWIM
Nomad permite la gestioacuten simultaacutenea de varios centros de datos reparti-dos en regiones geograacuteficamente separadas requiriendo de un protocolo ligeroque mantenga a los miembros actualizados sobre los participantes del conjun-to Para ello usa una ligera variante del protocolo SWIM[3] (Scalable Weakly-consistent Infection-style Process Group Membership Protocol) desarrollada porHashiCorp Estaacute clasificado como un protocolo de tipo gossip que debe su nom-bre a la semejanza con coacutemo se distribuye un rumor en una red social
SWIM se sustenta en dos caracteriacutesticas fundamentales la deteccioacuten de fallosy la distribucioacuten de la informacioacuten relativa a los miembros A continuacioacuten sedetalla el funcionamiento de ambos componentes
Deteccioacuten de fallos
Este componente tiene dos paraacutemetros el periodo de protocolo T y el nuacutemerode subgrupos de deteccioacuten de fallos k en los que se dividen los nodos Paracomprobar la comunicacioacuten entre dos maacutequinas usa la utilidad ping basadaen el protocolo ICMP La deteccioacuten de caiacuteda de un servidor sigue el siguientealgoritmo
Durante el periodo T cada miembro Mi de un subgrupo elige otro al azar Mjdel mismo subgrupo y le enviacutea un mensaje ping para comprobar su estado Enel caso de que se cumpla un tiempo de espera determinado por una estimacioacuten
23
del tiempo de ida y vuelta (RTT por sus siglas en ingleacutes) de la red y no hayarespuesta Mi le vuelve a enviar un mensaje ping indirectamente a traveacutes deun nuacutemero k de miembros escogidos aleatoriamente De no recibir ninguna res-puesta Mi establece que Mj ha sufrido un fallo y lo etiqueta como ldquosospechosordquoinformando al componente de distribucioacuten
Figura 15 Diagrama de tiempo del protocolo SWIMFuente httpswwwcscornelledu
Componente de distribucioacuten
Se encarga de informar de cualquier cambio en los miembros a todo el con-junto Los eventos de nodo caiacutedo y la unioacuten o disociacioacuten de un miembro setransmiten a todos los servidores para que actualicen sus lista Para distribuirla informacioacuten a todos los nodos se podriacutea usar el meacutetodo de multicast perosuele estar deshabilitado Por ello se utiliza una teacutecnica de transmisioacuten denomi-nada Piggybacking mediante la cual se adjunta a los propios mensajes PINGy ACK del algoritmo la informacioacuten a distribuir reduciendo asiacute la congestioacutenen la red
523 Planificacioacuten
Proceso encargado de distribuir las tareas entre los nodos clientes de acuerdoa su estado
El planificador de Nomad estaacute basado en las publicaciones de Google sobresus herramientas de gestioacuten de clusters Borg y Omega14 y entiende los trabajosdescritos por el usuario como un estado deseado es decir su despliegue en unamaacutequina cliente de forma correcta y los clientes como el estado actual esto eslo que se encuentra en ejecucioacuten El registro actualizacioacuten o cancelacioacuten de un
14httpresearchgooglecompubspub43438html
24
trabajo asiacute como el fallo de un nodo cliente implican un cambio de estado atramitar por el sistema lo que se define como evaluacioacuten (evaluation) Esto uacutelti-mo supone comparar el estado actual (clientes) con el estado deseado (conjuntode trabajos registrados) y enviarlos a los planificadores correspondientes que seencargaraacuten de asignar las tareas a los nodos clientes
Figura 16 Procedimiento de asignacioacuten en NomadFuente httpswwwnomadprojectio
En la figura 16 se observa el flujo de trabajo en el que las distintas evalua-ciones se encolan en el evaluation broker que se ejecuta en el servidor liacuteder ygestiona las evaluaciones pendientes asignaacutendoles prioridades
A continuacioacuten los nodos servidores ejecutan los scheduling workers queprocesan las evaluaciones llamando a los distintos planificadores que generanun plan de asignacioacuten esto es un conjunto de relaciones entre las tareas y losnodos clientes donde se ejecutaraacuten Este proceso se divide en dos fases primerose descartan aquellos clientes que no cumplan los requisitos y posteriormentese asigna una calificacioacuten al resto Se selecciona el nodo con mayor puntuacioacuteny se encola el plan en el gestor que se ejecuta en el servidor liacuteder Existen tresplanificadores de acuerdo al tipo de trabajo
Service Incluye aquellos trabajos que estaacuten destinados a ejecutarse en un pe-riacuteodo largo de tiempo Para realizar las asignaciones el planificador evaluacuteala mayor parte de los nodos y usa una versioacuten del algoritmo Best fit in-fluenciada por el trabajo de Google en su herramienta Borg Se trata deun algoritmo de planificacioacuten que sacrifica tiempo a cambio de maximizarel rendimiento de los clientes asignando la tarea a la maacutequina que tengala mayor carga de trabajo con el objetivo de reducir equipos en funciona-
25
miento
Batch Tareas que incluyen listas de comandos en general de menor duracioacuteny que no requieren interaccioacuten con el usuario Se vale del algoritmo deSparrow desarrollado por la universidad de Berkeley15 para limitar losnodos clientes a evaluar
System Trabajos destinados a ejecutarse en todos los nodos incluso los que seunen al cluster posteriormente
Core Mantenimiento interno de Nomad
Una vez se ha realizado el proceso de planificacioacuten el nodo liacuteder lo registra enla cola de planes (plan queue) que se encarga de asignarles prioridad y manejarcondiciones de carrera es decir que no accedan a los recursos de los clientes sincontrol y evitar que eacutestos superen su capacidad
La maacutequina liacuteder del conjunto puede de este modo aceptar una asignacioacuteny ser ejecutada por los clientes o por el contrario rechazaacutersela al planificadorlo que implicariacutea realizar un plan parcial o totalmente nuevo
Finalmente el estado de las evaluaciones se actualizan y los clientes soninformados de las asignaciones ejecutaacutendose las tareas
15httppeopleeecsberkeleyedu~keopublicationssosp13-final17pdf
26
6 Casos de uso y despliegue
Con el objetivo de mostrar las posibles utilidades que este tipo de sistemaspueden tener en las infraestructuras TI actuales se han desplegado las dos he-rramientas en la nube Microsoft Azure usando su servicio cloud de instancias demaacutequinas virtuales Linux para simular un conjunto de ordenadores conectadosentre siacute por una red LAN Sobre ellas se ha implementado dos casos de usouna aplicacioacuten web con una arquitectura con cierta orientacioacuten a microserviciosy un sistema de integracioacuten continua
El coacutedigo y todos los ficheros de configuracioacuten se pueden encontrar en elrepositorio del proyecto en GitHub16
61 Aplicacioacuten Web
Se busca simular el proceso de adaptacioacuten de una solucioacuten web para su des-pliegue en un sistema distribuido con las herramientas anteriormente descritascon el objetivo de aumentar tanto su escalabilidad como disponibilidad medianteredundancia
Se ha partido de una aplicacioacuten ya existente17 un servicio de almacenamien-to y reproduccioacuten de canciones A grandes rasgos este servicio permite crearusuarios subir canciones con sus respectivas portadas tener playlists propias yescuchar las canciones a traveacutes de un navegador web
La solucioacuten estaacute dividida en 4 partes (figura 17)
Una vista web con la loacutegica
Un almacenamiento conectado en red (NAS por sus siglas en ingleacutes)
Una API REST para gestionar las peticiones al almacenamiento
Base de datos NoSQL basada en MongoDB
La nueva tendencia de los proyectos web es su implementacioacuten en contene-dores Docker ya que facilitan su portabilidad y ofrecen un procedimiento dedespliegue raacutepido sobre todo a la hora de desarrollar y realizar pruebas en en-tornos de produccioacuten simulados Por ello en este caso se va a hacer uso de los
16httpsgithubcomAntonioAlfrzCloud-Orchestrators17httpsgithubcomsonsoleslpCDPSfy
27
motores de orquestacioacuten de contenedores de ambas herramientas Marathon enDCOS y el controlador Docker en el caso de Nomad
Figura 17 Arquitectura aplicacioacuten web
A continuacioacuten vamos detallar el despliegue en ambas herramientas de es-ta solucioacuten y observar tanto queacute dificultades se encuentran como que ventajasofrecen El objetivo final es adaptar el proyecto modificaacutendolo lo menos posiblecon objeto de analizar la capacidad de estas herramientas para desplegar cual-quier aplicacioacuten sin que eso conlleve la modificacioacuten de la arquitectura de eacutestaes decir que no sea dependiente del entorno
611 DCOS
Se ha descrito DCOS como una herramienta que se despliega sobre un con-junto de ordenadores y que permite instalar gestionar el despliegue de sistemasdistribuidos
Microsoft Azure cuenta con una plantilla para desplegar en su servicio cloudun cluster de maacutequinas virtuales con DCOS ya instalado que cuenta con
Maacutequinas maestras (1 3 o 5 a seleccionar por el usuario) configuradascomo un conjunto de disponibilidad esto eso Azure da ciertas garantiacuteasde que al menos una maacutequina estaraacute en funcionamiento
Maacutequinas agentes Por motivos de seguridad se distinguen dos roles
bull Nodos privados solo accesibles desde la red interna y configuradoscomo un conjunto de escala un recurso de Azure para gestionar ydesplegar maacutequinas con configuraciones ideacutenticas para permitir unraacutepido escalado
bull Un equipo conectado accesible desde Internet a travntildees de un balan-ceador de carga puacuteblico y situado en una subred externa
28
Dos balanceadores de carga
bull La interfaz puacuteblica del cluster que se conecta con el cliente puacuteblicobull Acceso a los equipos maestros para el administrador que soacutelo permiteconexioacuten mediante SSH y credenciales
Almacenamiento para todas las maacutequinas
Configuraciones necesarias de red y seguridad
En la figura 18 se observa un diagrama de la infraestructura
Figura 18 Infraestructura en Azure
El primer obstaacuteculo es la persistencia de estado de la aplicacioacuten que seconsigue gracias a una base de datos no relacional basada en MongoDB asiacutecomo el almacenamiento de las canciones Para implementarla tenemos variasposibilidades
Montar un sistema externo de almacenamiento conectado en red en todoslos agentes donde se ejecuten las tareas de esta manera si una tarea pasade un nodo a otro por cualquier motivo puede tener acceso a los mismosficheros (opcioacuten del caso de uso original)
Implementar un sistema de ficheros distribuidos en los agentes
Usar los servicios de almacenamiento de las nubes puacuteblicas
Aprovechar el sistema de voluacutemenes persistentes de Apache Mesos Eacutestepermite reservar recursos de un agente de forma que al arrancar una tarease crea un volumen independiente del ciclo de vida de eacutesta con ello esosrecursos donde se ha almacenado la informacioacuten pueden volver a ofrecerseal mismo entorno de tal manera que otra tarea pueda acceder a ella
DCOS aprovecha este sistema de voluacutemenes persistentes y permite instalarbases de datos distribuidas como ArangoDB o Apache Cassandra sin embargoesto implicariacutea modificar todo el coacutedigo referente al modelo de la base de datos
29
Por motivos de eficiencia y latencia asiacute como de una mayor gobernabilidadde los datos la mejor opcioacuten es usar el recurso de voluacutemenes persistentes queofrece Apache Mesos ya que de esta manera se gestionariacutea la aplicacioacuten completamediante una uacutenica herramienta Sin embargo esto implica que la informacioacutense encuentra exclusivamente en el agente donde se haya ejecutado la tarea y porlo tanto se sigue requiriendo de software externo para distribuir la informacioacutenpara que se accesible para todos los agentes A la hora de realizar este proyectose encontraba en desarrollo Flocker una solucioacuten desarrollada por ClusterHQque permite compartir los voluacutemenes de Docker a traveacutes de un cluster quesi bien es compatible con el planificador de Mesos el proyecto se encontrabatodaviacutea en fases tempranas de desarrollo y los sistemas de almacenamiento quesoporta quedaban fuera del aacutembito de este trabajo
Por todo ello dado que las maacutequinas se han desplegado en la nube puacuteblicade Azure se decidioacute usar su servicio de almacenamiento de objetos para lascanciones y otra maacutequina para desplegar MongoDB y asiacute mantener el modelode datos original de la aplicacioacuten La diferencia del almacenamiento de obje-tos con respecto a nivel de fichero es que el primero no tiene jerarquiacutea paraorganizar los archivos eacutestos se guardan como objetos (con sus metadatos) enun mismo espacio soacutelo diferenciaacutendose por un identificador uacutenico esto implicaentre otras cosas que se puede acceder a un fichero dado uacutenicamente su IDindependientemente de la localizacioacuten fiacutesica de eacuteste facilitando pues la gestioacuteny el desarrollo
El coacutedigo del proyecto se ha modificado en los siguientes apartados
Las direcciones de la base de datos y los balanceadores de carga asiacute comosus puertos estaban originalmente fijos Se han configurado como variablesde entorno para facilitar el descubrimiento del servicio y hacer transpa-rente la aplicacioacuten al entorno de despliegue
La API REST se ha adaptado al almacenamiento en Azure en vez de enlocal
Estas modificaciones no suponen un cambio sustancial pero permiten separala persistencia de las tareas ejecutadas por DCOS lo que facilita en granmedida su ejecucioacuten al ser totalmente sin estado y ademaacutes implican tenerlos datos bajo un mayor control
Para la orquestacioacuten de contenedores se va a usar el entorno Marathondesarrollado tambieacuten por Mesosphere Eacuteste se puede usar a traveacutes de una interfazgraacutefica la interfaz de liacutenea de comandos (en lo que sigue CLI por sus siglas eningleacutes) de DCOS o con su API HTTP
Primero se han publicado la imaacutegenes de los contenedores que encapsulanla interfaz web y la api de la aplicacioacuten en el repositorio puacuteblico DockerHub
Los despliegues en este entorno se describen mediante ficheros JSON en losque se detalla entre otras opciones la imagen del contenedor los puertos a usar
30
los recursos que debe ocupar en un nodo o las instrucciones de monitorizacioacuten
Para el servicio de descubrimiento DCOS ofrece la posibilidad de asignardirecciones IP virtuales (VIP por sus siglas en ingleacutes) a tareas que se compartenen todos los nodos DCOS lleva integrado un balanceador de carga a nivel TCP(el componente denominado Minuteman) que balancea entre las direccionesvirtuales de las tareas y todas las instancias de eacutestas a lo largo del cluster Estoes necesario por dos motivos equilibrar la carga de los equipos con el fin deevitar un punto de uacutenico fallo mediante redundancia y evitar la contienda dedirecciones al ejecutar las tareas en puertos aleatorios
Este balanceador de carga estaacute basado en el trabajo de Michael Mitzenma-cher The Power of Two Choices in Randomized Load Balancing18 A grandesrasgos el algoritmo mantiene una media moacutevil exponencial de latencias paracada destino (backend) ademaacutes de las caiacutedas consecutivas Si un destino noresponde a una negociacioacuten en tres pasos (three way handshake) de forma con-secutiva en un periodo inferior a 5 ms se considera caiacutedo El algoritmo iterasobre los destinos disponibles en base a su histoacuterico de fallos y escoge dos deforma aleatoria de los cuales coge el de mejor meacutetrica
Las direcciones virtuales soacutelo se pueden resolver dentro del cluster porello para implementar la interfaz puacuteblica de la aplicacioacuten esto es el balancea-dor de carga de la interfaz web usaremos un paquete de DCOS denominadomarathon-lb un balanceador basado en HAProxy y adaptado por MesosphereEn este caso equilibra la carga de todas instancias de las tareas ejecutadas porel entorno Marathon por sus etiquetas y permite ademaacutes definir como puntode entrada muacuteltiples hosts virtuales definidos por sus nombres completos dedominio (FQDN por sus siglas en ingleacutes) en nuestro caso la interfaz puacuteblicadel balanceador de Azure para los agentes
Por motivos de seguridad todas las tareas se ejecutan en los agentes privadoses decir los que son exclusivamente accesibles desde la red interna Por su partemarathon-lb se ejecuta en el agente puacuteblico que cuenta con IP puacuteblica y lospuertos 80 (HTTP) y 8080 abiertos de forma que la aplicacioacuten sea accesibledesde Internet Esto es posible debido a que Apache Mesos permite reservarrecursos mediante roles asignados a nodos para un uso especiacutefico De esta formala arquitectura vista desde la aplicacioacuten quedariacutea como en la figura 19
18httpswwweecsharvardedu~michaelmpostscriptstpds2001pdf
31
Figura 19 Arquitectura de la aplicacioacuten web en DCOS
Ejecucioacuten
A la hora de desplegar la aplicacioacuten DCOS puede gestionarse medianteuna interfaz graacutefica o una interfaz de liacutenea de comandos La primera se accedea traveacutes de un navegador web en el puerto 80 (HTTP) y permite instalar losentornos disponibles observar el estado de los nodos y las tareas que se estaacutenejecutando y los ficheros de registros que eacutestas generan
La CLI permite el control desde un nodo o una maacutequina remota (suponiendoque los maestros tienen IP puacuteblica y el puerto 80 abierto) ya que DCOS tieneun sistema de autorizacioacuten que permite tener una interfaz puacuteblica con ciertasgarantiacuteas de seguridad
Por su parte cada entorno de trabajo puede ser controlado por la CLI peroademaacutes cuenta con sus propias interfaces Marathon expone una API HTTPen el puerto 8080 de la direccioacuten puacuteblica de los maestros del cluster asiacute comootra interfaz graacutefica Para desplegar un contenedor se podriacutea usar la CLI
$ dcos marathon app add lt f i l e j songt
O la API HTTP
$ cu r l minusX POST http lt ip_maestro gt8080v2apps minusd ltf i l e jsongt minusH Contentminustype app l i c a t i o n j son
32
612 Nomad
La arquitectura de Nomad es maacutes sencilla ya que solo requiere de un ficheroejecutable en todos los nodos para funcionar Si DCOS es la base de instala-cioacuten de entornos de terceros Nomad integra todas las funcionalidades baacutesicasesto es gestor de recursos planificador y ejecutor en los nodos cliente Estaherramienta cuenta con un menor tiempo de desarrollo y en el momento deescribir este documento cuenta exclusivamente con los siguientes controladoresen comparacioacuten con los entornos de DCOS
Motor Docker es decir funcioacuten de orquestacioacuten de contenedores
Ejecucioacuten de archivos binarios como comandos de Shell
Ejecucioacuten de aplicaciones Java
Virtualizacioacuten de maacutequinas mediante tecnologiacutea QEMU
Todos ellos necesitan que la tecnologiacutea subyacente esteacute instalada en las maacute-quinas clientes (Docker Java QEMU) Actualmente no permite el registro decontroladores por parte de terceros aunque estaacute planificado en un futuro ofreceruna interfaz para su desarrollo
Nomad no cuenta con el servicio de descubrimiento sin embargo puede inte-grarse con la herramienta Consul desarrollada por la misma empresa Por otrolado para el balanceo de carga usaremos un contenedor Docker con HAProxyuna herramienta de coacutedigo abierto que ofrece tanto servicios de proxy como debalanceador y cuyos ficheros de configuracioacuten completaremos con el proyectoConsul Template19
Consul
Consul sigue la misma arquitectura que Nomad es decir un nodo servidorque orquesta un conjunto de maacutequinas clientes y permite a los procesos que seejecutan en los equipos definirlos como servicios ofreciendo diversas caracteriacutes-ticas entorno a estos de los cuales vamos a usar dos
Descubrimiento de servicio Las maacutequinas clientes publican en el cataacutelogode servicios las tareas en ejecucioacuten y Consul les asigna nombres de dominioaccesibles por todos los miembros del cluster a traveacutes de la interfaz DNSincluida en esta herramientaConsul se integra con Nomad de forma que todas las tareas que se ejecu-ten en la segunda son automaacuteticamente publicados como servicios de laprimera de esta manera no hace falta conocer la direccioacuten de la maacutequinacliente donde se esteacute ejecutando el proceso ya que se puede acceder a eacutela traveacutes de su nombre de dominio de forma transparente Por ejemplo si
19[httpsgithubcomhashicorpconsul-template]
33
ejecutamos una tarea con ID web en el puerto 8080 se puede acceder aella en la direccioacuten webserviceconsul8080Para que las direcciones propias de Consul las resuelva su propio DNS y noel que esteacute asignado por defecto en la maacutequina usaremos la herramientadnsmasq20 que permite especificar la direccioacuten de un servidor DNS paraconsultas de direcciones especiacuteficas
Monitorizacioacuten Permite realizar comprobaciones del servicio y seguir su esta-do Aprovecharemos esta funcionalidad tanto para definir el propio procesode Nomad como servicio de Consul como las tareas desplegadas
HAProxy + Consul Template
HAProxy es una solucioacuten versaacutetil de coacutedigo abierto que ofrece solucionesde balanceo de carga y proxy Existen otras herramientas en el mercado comoNGINX o ldirectord sin embargo HAProxy suponiacutea una solucioacuten sencilla deconfigurar para mostrar el caso de uso
El uso de estas herramientas se debe a dos motivos para que no existacontienda con respecto a los puertos de los clientes usados por las tareas eacutestos sevan a asignar de forma dinaacutemica lo que en principio implicariacutea que la aplicacioacutendeberiacutea realizar consultas DNS de tipo SRV (que incluye puertos) a la interfazde Consul y balancear la carga entre tareas por redundancia y capacidad
Como la direccioacuten IP y puerto son variables cada vez que las tareas seactualicen o se reasignen es necesario volver a configurar HAProxy de formamanual Por ello HashiCorp ha desarrollado un programa denominado Con-sul Template que realiza peticiones sucesivas a la interfaz HTTP de Consul delas direcciones fiacutesicas de un servicio y reinicia automaacuteticamente el proceso deHAProxy Asiacute definiendo estas tareas como servicios Consul podremos tantomonitorizarlas como escalar las tareas dinaacutemicamente sin necesidad de cambiarel balanceador A partir del contenedor Docker oficial de HAProxy se ha desa-rrollado otro con la configuracioacuten baacutesica y con Consul Template para desplegarlocomo una tarea en Nomad
Despliegue
Se ha usado el mismo coacutedigo que en el apartado anterior con la persistenciaen el servicio de almacenamiento de Azure Desde la perspectiva del hardwarese implementaraacute la misma infraestructura que en el caso de DCOS (figura 18)estos es definiremos dos tipos de maacutequinas clientes un agente que se conectaraacutecon el balanceador de carga con nombre de dominio puacuteblico y donde se desple-garaacute el balanceador de carga de la vista web y agentes privados no accesiblesdesde fuera del cluster y donde se ejecutaraacuten el resto de tareas en la red inter-na La principal diferencia radica en las tareas que ejecutan HAproxy y ConsulTemplate que sustituye a las direcciones IP virtuales que ofrece DCOS
20httpwwwthekelleysorgukdnsmasqdochtml
34
Figura 20 Despliegue en Azure de Nomad+Consul
Cabe matizar que los balanceadores basados en HAProxy se implementanpor necesidad de la aplicacioacuten para el descubrimiento del servicio a diferenciade los de Azure que se implementan por motivos de seguridad y escalabilidaddel cluster en siacute
Configuracioacuten Nomad
Los ficheros de configuracioacuten de las maacutequinas maacutester y cliente son similaresy comparten la mayoriacutea de las opciones como por ejemplo el nombre del nodoo la interfaz de red donde escucha Nomad las peticiones Sus opciones son engeneral auto-explicativas sin embargo existen dos detalles que matizar
El proceso de Nomad escucha las peticiones tanto de los protocolos deconsenso como del usuario a traveacutes de una interfaz de red que se debeindicar en el fichero de configuracioacuten
En el caso de los clientes se deben indicar las direcciones de los servidoresdel cluster sin embargo se trata de un sistema dinaacutemico en el que losnodos pueden sufrir errores y cambiar de direccioacuten Por ello se ha definidoNomad como un servicio de Consul y asiacute poder definir la direccioacuten de losservidores como un nombre de dominio no por su direccioacuten fiacutesica que elservidor DNS de Consul se encargaraacute de resolver
Por defecto Nomad usa los siguientes puertos
API HTTP 4646 Peticiones HTTP y recepcioacuten de oacuterdenes mediante laliacutenea de comandos
RPC 4647 Protocolo de consenso entre los nodos del cluster
Serf 4648 Protocolo de gossip entre los servidores de los centros de datosgobernados por Nomad
35
Los dos uacuteltimos deben ser interfaces alcanzables por otros nodos sin embargo laAPI HTTP por motivos de seguridad deberiacutea ser local ya que en caso contrariocualquier persona con acceso a ella tiene el control sobre la herramienta Eacutestasolo deberiacutea estar accesible en un servidor o gestionarlo mediante una terminalSSH por ejemplo En este trabajo al ser una prueba de concepto se ha abiertoen todos los nodos
Trabajos de Nomad
Las tareas se detallan en ficheros con formato HashiCorp Configuration Lan-guage un derivado del formato JSON creado por la empresa que le da nombrecompatible con eacuteste y que permite comentarios
En estos ficheros se puede definir
La regioacuten y el centro de datos donde se ejecutaraacute (Nomad permite lagestioacuten de centros de datos geograacuteficamente distribuidos en regiones)
La poliacutetica de actualizacioacuten de la tarea
Grupo de tareas esto es que se ejecutaraacuten en el mismo nodo
El nuacutemero de grupos a ejecutarescalar asiacute como los liacutemite que debencumplir los nodos asignados
La poliacutetica de reinicio ante fallo o error
Tareas El controlador su configuracioacuten los paraacutemetros del servicio aso-ciado a registrar en Consul asiacute como los recursos que consume (puertosmemoria)
En nuestro caso usamos sobre todo el controlador Docker esto eso orques-tacioacuten de contenedores en los nodos clientes y tres de sus opciones
Imagen del contenedor Se han subido todas las imaacutegenes del proyecto a Doc-ker Hub donde por defecto se busca la imagen
Puertos Los puertos a usar por el contenedor que pueden ser estaacuteticos asigna-dos por el usuario o dinaacutemicos siendo Nomad el que se encarga de mapearun puerto libre del nodo cliente al expuesto por el contenedor
Servidores DNS Como usamos la interfaz DNS de Consul como descubri-miento de servicio se debe configurar el contenedor para que use cualquiernodo del cluster como servidor DNS
Configuracioacuten Consul
Al ser desarrolladas por la misma empresa los ficheros de configuracioacuten deConsul y Nomad comparten muchas opciones Consul tambieacuten acepta peticionesa traveacutes de una interfaz de red siendo los puertos usados por defecto
36
RPC 8300 8400 Maneja la peticiones del resto de nodos y usuarios
Serf 8301 8302 Protocolo gossip
HTTP API 8500
HTTPS API Desactivada por defecto
Interfaz DNS 8600
Se debe asignar a los protocolos internos del cluster esto es RPC y Serf unainterfaz alcanzable por los nodos y por el contrarioasignar a los dos uacuteltimos ala interfaz de loopback por motivos de seguridad
Cabe destacar que Consul tambieacuten cuenta con una interfaz graacutefica que per-mite ver el estado de los equipos y los servicios registrados y que se encuentra enel mismo puerto que la API HTTP en la direccioacuten httpIP_EQUIPO8500ui
Ejecucioacuten
Tanto Nomad como Consul requieren de la ejecucioacuten de un fichero en todoslos nodos integrantes del cluster Como prueba de concepto se ha decidido usardos servidores para ambos aunque cabe matizar que es un nuacutemero ineficienteya que la caiacuteda de uno de ellos supondriacutea la peacuterdida del cuoacuterum y por tantodel consenso del cluster
En primer lugar se arrancan los servidores que son los encargados de ejecu-tar el protocolo de consenso y gestionar el cluster y a continuacioacuten los clientesque no tienen praacutecticamente estado y dependen de los servidores
En el caso de Consul se debe indicar el directorio donde se guardan losficheros que describen los servicios asiacute como el archivo que especifica el resto delas opciones
1 Se inicia el primer servidor en uno de los equipos
$ consu l agent minuscon f i gminusd i r e t c consu l d s e r v i c e s minuscon f i gminus f i l e consu l_server j son
2 Los siguientes equipos deben unirse al anterior por lo que antildeadimos elargumento join con la direccioacuten del primer servidor Para el caso de otrosservidores
$ consu l agent minuscon f i gminusd i r e t c consu l d s e r v i c e s minuscon f i gminus f i l e consu l_server j son minus j o i n ltIP_servidor1gt
37
Una vez los servidores han alcanzado el consenso y elegido un liacuteder en losclientes
$ consu l agent minuscon f i gminusd i r e t c consu l d s e r v i c e s minuscon f i gminus f i l e c on su l_c l i en t j son minus j o i n ltIP_cualquierServ idorgt
El proceso para iniciar Nomad es igual y los comandos similares sin embargoya no es necesario indicar una direccioacuten IP fija en los equipos sino el nombre dedominio del servicio de Nomad registrado por Consul En el primer servidor
$ nomad agent minusc on f i g nomad_server j son
Y el resto de equipos (con su fichero de configuracioacuten correspondiente)$ nomad agent minusc on f i g nomad_server j son minus j o i n nomad s e r v i c e consu l
Por uacuteltimo para desplegar la aplicacioacuten web se han escrito tres ficherosque detallan las tareas de la interfaz web API y los balanceadores de cargaMediante la CLI
$ nomad run minusaddress=http lt ip_c lus te r gt4646 lt f i l e hclgt
O mediante la API HTTP de Nomad$ cu r l minusX POST minusd ltf i l e hclgthttp lt ip_c lus te r gt4646 jobltjob_namegt
Ansible
Como se puede comprobar con el aumento del nuacutemero de equipos pasa aser inviable manejar todos los nodos a traveacutes de terminal Ademaacutes como seha comentado con anterioridad Nomad requiere que en los nodos clientes es-teacuten instalados las herramientas que soporten las tareas por ejemplo el motorde Docker Por ello para facilitar tanto el arranque como la instalacioacuten de lasdependencias vamos a usar Ansible una herramienta de coacutedigo abierto desarro-llada en Python que permite gestionar configuraciones aprovisionar recursosdespliegue de aplicaciones de forma automaacutetica
A grandes rasgos esta herramienta funciona mediante ficheros en formatoYAML denominados play-books que describen un conjunto de pasos a ejecutaren una lista de equipos remotos Estos pasos son ejecutados por moacutedulos inde-pendientes a traveacutes de SSH es decir en cualquier ordenador con conexioacuten a los
38
hosts dado su contrasentildea o clave puacuteblica puede arrancar el script y realizariacutealos pasos de forma remota gestionando el cluster desde un solo equipo
Se han desarrollado guiones para lo siguiente
Descarga de los binarios de Nomad y Consul en todos los nodos copiade los ficheros de configuracioacuten baacutesicos y modificarlos de acuerdo a cadanodo (nombre del equipo direccioacuten IP)
Instalacioacuten de las dependencias
Arranque de Nomad y Consul
Ansible extiende su funcionalidad a traveacutes de moacutedulos independientes que per-miten por ejemplo instalar paquetes mediante herramientas de gestioacuten de pa-quetes (APT yum) aprovisionar automaacuteticamente maacutequinas virtuales de Ama-zon EC2
Algunas opciones de los ficheros de configuracioacuten de Nomad y Consul sondependientes del nodo particular por ejemplo la interfaz de red Para estetrabajo se ha realizado un moacutedulo para modificar los ficheros de configuracioacutende forma automaacutetica En el repositorio del proyecto se encuentra una carpetadonde se encuentran todos los ficheros necesarios para desplegar un clustertotalmente funcional solo requiere de una liacutenea de terminal con Ansible
$ ans ib l eminusplaybook minus i hos t s minusk ltssh_passgt minusu ltnode_usergt s i t e yml
39
62 Servicio de integracioacuten continua
Se ha implementado un sistema de integracioacuten continua que permite ejecu-tar tareas de compilacioacuten y pruebas de forma distribuida aumentando asiacute elrendimiento de los equipos En primer lugar se detallaraacute los motivos por los quepuede resultar beneficioso para las empresas una implementacioacuten de este tipo alo que seguiraacute los detalles del despliegue
621 DevOps
Metodologiacutea que defiende la comunicacioacuten y colaboracioacuten entre desarrolla-dores de software y los profesionales de operaciones a lo largo de todo el ciclo devida de una aplicacioacuten Estaacute muy relacionado con el desarrollo aacutegil de softwareesto es un enfoque para los proyectos que defiende el desarrollo iterativo e in-cremental donde los requisitos y soluciones evolucionan con el tiempo seguacuten lanecesidad del proyecto DevOps extiende esta filosofiacutea a todas los componentesde un servicio incluyendo sistemas y operaciones
Se trata de un concepto que cada organizacioacuten o empresa adapta a suspropias necesidades y procesos de negocio en este proyecto nos vamos a centraren la integracioacuten continua una praacutectica fundamental tanto del desarrollo aacutegilcomo de esta filosofiacutea
622 Integracioacuten Continua
Se define como una praacutectica de desarrollo software donde los miembros delequipo ponen en comuacuten su trabajo frecuentemente al menos una vez al diacutea21Cada integracioacuten se verifica con una compilacioacuten automaacutetica que incluye laejecucioacuten de pruebas para detectar errores de integracioacuten tan pronto como seaposible
Desde el punto de vista operativo esto supone automatizar la configuracioacutende equipos o el despliegue de maacutequinas virtuales donde compilar el proyecto yejecutar las pruebas y posteriormente eliminarlas Este flujo de trabajo se vebeneficiado en entornos distribuidos ya que el objetivo del desarrollador es com-probar el resultado de las pruebas raacutepidamente sin preocuparse del despliegueo los propios equipos
Para esta prueba de concepto vamos a usar Jenkins un servidor de integra-cioacuten continua escrito en Java que nos permite definir trabajos que contendraacutenla descripcioacuten tanto del entorno como su ejecucioacuten
Este sigue una estructura maestro-esclavo muy similar al de los gestores declusters usados en este proyecto el maestro contiene toda la loacutegica del servicio
21httpmartinfowlercomarticlescontinuousIntegrationhtml
40
trabajos autenticacioacuten y los esclavos son los encargados de la ejecucioacuten ensiacute Jenkins tiene varias viacuteas para aprovisionar los uacuteltimos
Mediante SSH
Interfaz graacutefica
Desarrollar un script propio
Ejecucioacuten de un fichero java
La ventaja de usar planificadores es que el despliegue de esclavos es dinaacutemicoes decir no tener una maacutequina especiacuteficamente configurada para ello DCOS yNomad se encargaraacuten de configurar estos despliegues en sus maacutequinas y poste-riormente eliminarlos Para ello se ha usado la uacuteltima opcioacuten definiendo tareasque descarguen el fichero java Con todo ello se consigue un entorno de inte-gracioacuten continua eficiente que ademaacutes permite la ejecucioacuten de otros servicios deforma independiente
Jenkins permite la creacioacuten de plugins que extienden sus funcionalidadesTanto Nomad22 como Apache Mesos cuentan con uno que permite su integra-cioacuten
Para esta prueba se va a usar el mismo proyecto que para el caso de usode orquestacioacuten de contenedores la aplicacioacuten web al que se le ha antildeadido untest para comprobar que se conecta correctamente a la base de datos medianteMocha un framework de Nodejs Por otro lado se antildeade el plugin de git ya queel coacutedigo se obtiene de GitHub el repositorio remoto de control de versiones delproyecto
El proceso general de ejecucioacuten seriacutea como sigue
1 Se ejecuta el maestro de Jenkins como tarea Docker partiendo de la imagenoficial
2 Al arrancar un trabajo se manda una tarea a los planificadores que laasignaraacuten a un nodo cliente Esta tarea consiste en la descarga del ficherode configuracioacuten Java y arrancarlo configurando el equipo como un clientede Jenkins temporalmente
3 Jenkins ejecuta el trabajo en el nuevo cliente en este caso iniciar la apli-cacioacuten web iniciar las pruebas y generar un informe
4 Se elimina el cliente
A continuacioacuten se detallan los matices de cada herramienta a la hora de imple-mentar este servicio
22Desarrollado por Ivo Verberk httpwwwivoverberknl
41
623 Jenkins con Nomad
El plugin permite la ejecucioacuten del fichero Java mediante dos controladorescontenedores Docker y Java En este proyecto nos hemos decantado por el pri-mero ya que nos ahorra instalar la maacutequina virtual de java en todos los nodoscliente Por ello se ha construido un contenedor base con Java para la ejecucioacutendel fichero de configuracioacuten y Nodejs para lanzar la aplicacioacuten web
El plugin se configura con la direccioacuten IP del cluster y el contenedor queejecuta el esclavo Jenkins Por su parte el trabajo en Jenkins se define conel repositorio en GitHub donde se aloja el coacutedigo del proyecto a probar y loscomandos a ejecutar en este caso npm update y npm test
624 Jenkins con DCOS
En el caso de DCOS su sistema de paquetes incluye Jenkins por lo queal instalarlo ya se tiene la configuracioacuten de Mesos totalmente funcional Sinembargo para ejecutar la aplicacioacuten en particular y las pruebas se requiere deNodejs en los equipos esclavos por ello debemos antildeadir un plugin de Jenkinsque permite instalar este entorno antes de ejecutar el trabajo Una vez hechoesto soacutelo queda definir la tarea igual que en el caso anterior
Cabe destacar que Mesosphere tambieacuten ha desarrollado un plugin que per-mite hacer despliegues en Marathon de tal manera que permitiriacutea con cadacommit del coacutedigo compilar la imagen del contenedor Docker y desplegarlaautomaacuteticamente aunque en este proyecto no se ha hecho pruebas de esta fun-cionalidad
42
7 Escalando la infraestructura
Uno de los factores clave que se busca a la hora de implementar sistemasdistribuidos es el poder escalar la infraestructura de forma maacutes sencilla estoes detectar que las maacutequinas estaacuten alcanzando el liacutemite de su capacidad yaumentar eacutesta ya sea mejorando sus caracteriacutesticas teacutecnicas o antildeadiendo maacutesnodos al cluster
El coacutedigo y todos los ficheros de configuracioacuten de esta seccioacuten tambieacuten sepueden encontrar en el repositorio del proyecto en GitHub23
71 Disentildeo
Microsoft Azure permite organizar los servicios cloud de forma loacutegica a traveacutesde grupos de recursos y asiacute poder crear o eliminar eacutestos en conjunto parauna aplicacioacuten determinada (por ejemplo una aplicacioacuten web suele requerir demaacutequinas virtuales bases de datos almacenamiento) Ademaacutes dispone dela opcioacuten de crear plantillas en formato JSON que permite al desarrolladordefinir los recursos y su interrelacioacuten para desplegar de forma automaacutetica unainfraestructura TI en la nube
Azure tambieacuten ofrece la posibilidad de monitorizar el estado de las maacutequinasvirtuales a traveacutes de extensiones lo que permite configurar el escalado automaacute-tico al alcanzar cierto liacutemite definido por el operador Eacutesta es a priori la formaen que deberiacutea implementarse hablando en teacuterminos de eficiencia sin embargoesta aproximacioacuten es totalmente dependiente de la plataforma es decir no sepuede extrapolar a otro proveedor o sobre recursos propios sin realizar un nue-vo disentildeo En este proyecto las tareas que son ejecutadas por estos equipos notienen estado ya que todo lo relativo a la persistencia lo hemos asignado fueradel cluster esto permite escalar la plataforma a traveacutes de otra aproximaciones
Las plantillas aceptan una serie de variables a indicar por el usuario entreotras los conjuntos de escala para definir los nodos aceptan una variable quedefine el nuacutemero de maacutequinas que los componen Por otro lado Azure ofreceuna API REST y kits de desarrollo software (SDK por sus siglas en ingleacutes) quepermiten su despliegue de forma programaacutetica Aprovechando estas facilidadesen este proyecto se va a aproximar la escalabilidad con el sucesivo desplieguede la infraestructura de forma automaacutetica se monitorizan los equipos y si sedetecta una maacutequina excesivamente cargada se aumenta el nuacutemero de equiposen la plantilla y se vuelve a desplegar
23httpsgithubcomAntonioAlfrzCloud-Orchestrators
43
En este proyecto se han disentildeado las plantillas para desplegar la arquitec-tura necesaria tanto de Nomad como de DCOS En el caso de la primera eldespliegue es maacutes descriptivo ya que incluye maacutequinas virtuales grupos de se-guridad redes En el caso de DCOS Azure cuenta con un servicio especiacuteficopara clusters gobernados por DCOS denominado Azure Container Service queincluye los componentes necesarios y la instalacioacuten ya realizada
72 Implementacioacuten
En primer lugar para monitorizar el estado de los equipos se va a usar laherramienta Nagios un sistema que permite controlar el estado del hardwarey los servicios de un equipo Se trata de una herramienta muy completa de laque se va a usar su capacidad para ejecutar comandos (plugins) en los nodospara detectar picos de carga generar alertas y ejecutar programas para estoseventos
Se ha desplegado una maacutequina virtual con esta herramienta en ambos siste-mas y se ha instalado una extensioacuten de Nagios (Nagios Remote Plugin Executor)en todos los nodos que permite ejecutar comprobaciones remotamente en con-creto para esta prueba de concepto medir el nivel de saturacioacuten de la unidadcentral de procesamiento (CPU por sus siglas del ingleacutes) Cuando sucede uncambio de estado de una maacutequina esto es cuando este paraacutemetro supera el liacutemi-te definido por el operador Nagios permite actuar en consecuencia ejecutandoprogramas por ello se ha desarrollado un script que ejecuta lo siguiente
Un programa desarrollado en Python con el SDK de Azure que modificalas plantillas y despliega los recursos
Un guioacuten de Ansible para instalar todos los componentes necesarios en lasnuevas maacutequinas y arrancar de nuevo el cluster y las aplicaciones
44
8 Resultados y conclusiones
En este uacuteltimo apartado se da una visioacuten global del proyecto asiacute como a lasconclusiones maacutes importantes a las que se ha llegado y posibles temas futurosde desarrollo
81 Comparacioacuten
Ambas herramientas ofrecen las funcionalidades para gestionar los recursoseficientemente ofreciendo a los desarrolladores una plataforma donde desplegarsus aplicaciones de forma distribuida independientemente de los equipos fiacutesicosy el hardware que las soporten
DCOS es una herramienta que en un comienzo fue privativa pero cuyos res-ponsables la empresa Mesosphere decidieron publicar una versioacuten de coacutedigoEacutesta nos permite gestionar un cluster de una forma sencilla y usable ademaacutes decomplementarlo con otras herramientas como el balanceador de carga integradoo la autenticacioacuten de usuarios ademaacutes estaacute basada en Apache Mesos un pro-yecto de relativa madurez y con el soporte de la Apache Software FoundationDe forma resumida DCOS ofrece muchas posibilidades y servicios a cambiode una arquitectura e instalacioacuten maacutes compleja
Por su parte HashiCorp con menor tiempo de desarrollo ha conseguidouna herramienta muy sencilla de desplegar que ademaacutes cumple con todas lasfuncionalidades baacutesicas ejecutando un simple binario en cada nodo se puededesplegar un gestor de clusters totalmente funcional Sin embargo no cuentacon todas las posibilidades de Mesos (Nomad cuenta con menos controladoresque entornos posibles de Mesos) ni con los antildeadidos de DCOS lo que implicael uso de otras herramientas para complementar el servicio (Consul HAProxy)
De entre las dificultades encontradas al usar estas herramientas y desplegaraplicaciones sobre ellas se puede destacar la depuracioacuten en ocasiones se desco-noce si un error viene de la propia herramienta de la aplicacioacuten desplegada o delequipo fiacutesico si no se cuenta con un sistema de procesamiento de registro unose puede encontrar con muacuteltiples terminales abiertas inspeccionando numerososficheros de registro buscando posibles errores Ademaacutes no dejan de ser solucio-nes que para usar eficientemente se debe conocer parte de su funcionamientoy sintaxis a la hora de describir la tareas lo que supone un esfuerzo antildeadido yaque cada una tiene sus particularidades y liacutemites
45
82 Conclusiones
En una sociedad cada vez maacutes digital las empresas deben adaptarse a unmercado cuya demanda de contenido no deja de crecer Las nuevas arquitecturascomo microservicios asiacute como la gran cantidad de datos generada implica queuna mejor gestioacuten de los recursos y la rapidez para desplegar o escalar solucionesdando valor al cliente lo maacutes raacutepido posible es uno de los objetivos de todas lasempresas de base tecnoloacutegica
Las ventajas que ofrecen los planificadores con aplicaciones distribuidas sonnumerosas sin ir maacutes lejos empresas tan punteras como Google llevan maacutesde 10 antildeos orquestando contenedores24 Por un lado permiten aumentar elrendimiento de los equipos propios y por otro implementar un servicio comoplataforma para despliegues distribuidos sobre cualquier conjunto hardware deesta forma se provee un servicio similar al de la nube puacuteblica pero con laprincipal diferencia de que se elimina la independencia con el proveedor (vendorlock-in) esto es las aplicaciones no tienen limitaciones impuestas por eacuteste talescomo lenguaje de programacioacuten o herramientas y permite despliegues hiacutebridosentre recursos propios y la nube
83 Objetivos conseguidos
Implementacioacuten de los planificadores propuestos en la nube Se ha en-tendido y detallado el funcionamiento de estas herramientas y se hanimplementado en el servicio de infraestructura de Microsoft Azure
Despliegue de aplicaciones y servicios distribuidos Servicios que se usanactualmente en la industria del desarrollo software asiacute como una aplica-cioacuten web con una arquitectura moderna han sido desplegados de formadistribuida en los equipos cumpliendo con la funcionalidad esperada ade-maacutes de consiguiendo una alta disponibilidad
Aproximacioacuten de arquitectura escalable Se ha hecho una aproximacioacutende infraestructura escalable de forma que sea parcialmente extrapolable aotros proveedores
24httpwwwnextplatformcom20160322decade-container-control-google
46
84 Liacuteneas de investigacioacuten
Siguiendo con la materia de este proyecto se presentan posibles liacuteneas deinvestigacioacuten
Analizar el despliegue con estas herramientas de aplicaciones de Big Datay comparar la eficiencia con respecto a soluciones especializadas
Analizar el rendimiento de los algoritmos de planificacioacuten antes pruebasde estreacutes y situaciones de alta contienda
Comparar el uso de estas herramientas con las praacutecticas actuales de laindustria o implementacioacuten en un sistema de produccioacuten real
47
Referencias
[1] LA Barroso y U Houmllzle laquoThe Datacenter as a Computer An Introduc-tion to the Design of Warehouse-Scale Machinesraquo En Morgan amp ClaypoolPublishers ()
[2] Systems Research Group ndash NetOS (University of Cambridge) The evolu-tion of cluster scheduler architectures 2016 url httpswwwclcamacukresearchsrgnetoscamsasblog2016-03-09-scheduler-architectureshtml
[3] A Das I Gupta y A Motivala SWIM Scalable Weakly-consistent Infection-style Process Group Membership Protocol Inf teacutec Dept of ComputerScience Cornell University url https www cs cornell edu ~asdasresearchdsn02-swimpdf
[4] D Dubhashi y A Das Mastering Mesos PACKT Publishing mayo de2016
[5] The Apache Software Foundation Apache Mesos documentation urlhttpsmesosapacheorg
[6] David Greenberg Building Applications on Mesos OrsquoReilly Media 2016[7] Armand Grillet Comparison of Container Schedulers Inf teacutec Technische
Universitaumlt Berlin[8] HashiCorp Consul documentation url httpswwwconsulio[9] HashiCorp Nomad documentation url httpsdcosio[10] Dan C Marinescu Cloud computing theory and practice Morgan Kauf-
mann 2013[11] Mesosphere DCOS documentation url httpswwwnomadproject
io[12] Microsoft Azure documentation url httpsazuremicrosoftcom
es-esdocumentation[13] D Ongaro y J Ousterhout In Search of an Understandable Consensus
Algorithm Inf teacutec Stanford University url httpsraftgithubioraftpdf
[14] Fei Teng laquoRessource allocation and schelduling models for cloud compu-tingraquo Tesis de mtriacutea Ecole Centrale Paris 2011
[15] A Williams y col Automation and Orchestration with Docker and Contai-ners A Comprehensive Overview of the Docker and Container Ecosystem3 The New Stack 2016
48
- Resumen
- Summary
- Iacutendice de figuras
- Introduccioacuten y objetivos
-
- Contexto
- Objetivos
- Estructura del documento
-
- Cloud Computing
- Nuevas cargas de trabajo
- Gestioacuten de recursos Planificadores
-
- Sistemas distribuidos
-
- Clasificacioacuten
-
- Herramientas
-
- DCOS
-
- Apache Mesos
- Ejemplos de uso
-
- Nomad
-
- Protocolo de consenso Raft
- Protocolo gossip SWIM
- Planificacioacuten
-
- Casos de uso y despliegue
-
- Aplicacioacuten Web
-
- DCOS
- Nomad
-
- Servicio de integracioacuten continua
-
- DevOps
- Integracioacuten Continua
- Jenkins con Nomad
- Jenkins con DCOS
-
- Escalando la infraestructura
-
- Disentildeo
- Implementacioacuten
-
- Resultados y conclusiones
-
- Comparacioacuten
- Conclusiones
- Objetivos conseguidos
- Liacuteneas de investigacioacuten
-
Los componentes fundamentales de esta herramienta son
Imaacutegenes Describen el entorno de base sobre el que ejecutar el contene-dor por ejemplo la imagen del sistema operativo Ubuntu Sobre eacutesta seconstruyen las aplicaciones particulares del usuario dando lugar a otraimagen
Contenedores Se crean a partir de las imaacutegenes y comprenden todo aquellonecesario para arrancar la aplicacioacuten decir su entorno de ejecucioacuten
bull Voluacutemenes Encargados de gestionar la persistencia de datos e inde-pendientes del ciclo de vida del contenedor
Registros Pueden ser puacuteblicos o privados y almacenan las imaacutegenes elregistro puacuteblico oficial de Docker es Docker Hub
Dadas estas caracteriacutesticas los profesionales TI estaacuten comenzando a adoptarDocker ya que facilita tanto los despliegues como el trabajo compartido en dis-tintos entornos Sin embargo esto requiere de un software que permita desplegarlos distintos contenedores de forma que puedan trabajar en conjunto procesoque se ha denominado orquestacioacuten de contenedores
7
4 Gestioacuten de recursos Planificadores
Para sacar el maacuteximo provecho a las tecnologiacuteas anteriormente descritaslo ideal es desplegarlas en sistemas distribuidos sin embargo esto aumenta lacomplejidad del propio despliegue asiacute como la necesidad de software especiali-zado para ello Se necesitan algoritmos de planificacioacuten que permitan obtener elmaacuteximo rendimiento de los recursos por un lado y dar ciertas garantiacuteas de quetodas las tareas y procesos se van a ejecuta por otro
41 Sistemas distribuidos
En primer lugar se definen los sistemas distribuidos o clusters como unconjunto de ordenadores conectados entre siacute cuyo objetivo es trabajar como unauacutenica instancia de gran capacidad5
Su clasificacioacuten variacutea de acuerdo a cada autor pero en general se puedendividir seguacuten su objetivo en alto rendimiento aquellos cuyo objetivos es proveerde gran capacidad de coacutemputo gracias al conjunto de los nodos y alta disponi-bilidad con los cuales se busca la fiabilidad del sistema mediante redundanciayo balanceo de carga
El intereacutes de este proyecto recae en los uacuteltimos ya que el objetivo es porun lado ofrecer al desarrollador un entorno donde desplegar sus aplicaciones deforma distribuida y por otro maximizar el rendimiento de los recursos
De forma general las caracteriacutesticas que se buscan son las siguientes
Elasticidad Adaptacioacuten a cargas dinaacutemicas de trabajo aumentando (o dis-minuyendo) recursos de manera automaacutetica de tal forma que la utilizacioacutensea lo maacutes cercana a la demanda
Disponibilidad Capacidad de un sistema para mantener el servicio fun-cional
Tolerancia a fallos Recuperacioacuten del servicio ante el fallo de un compo-nente
Balanceo de carga Compartir las tareas entre las diferentes maacutequinasredundadas evitando asiacute puntos de uacutenico fallo
5httpsenwikipediaorgwikiComputer_cluster
8
Los programas que se implementan en entornos distribuidos se caracterizanpor ejecutarse de forma concurrente en equipos independientes estar conectadospor una red que introduce fallos aleatorios y no compartir memoria ni reloj Estoimplica entre otras cosas que
Los nodos soacutelo tienen un acceso raacutepido a su memoria local por lo quecualquier informacioacuten relativa al estado global puede ser potencialmenteerroacutenea
Las maacutequinas pueden sufrir caiacutedas de forma aleatoria
El intercambio de informacioacuten puede fallar ya sea por error en transmisioacuteno por caiacuteda de los nodos
Estas dificultades se ponen de manifiesto en el teorema de CAP en cienciasde la computacioacuten el teorema de CAP que lanzado inicialmente como conjetu-ra en el antildeo 2000 por Eric Brewer (motivo por el cual al teorema se le conoceformalmente como teorema de Brewer) y posteriormente demostrado en el antildeo20026 establece que es imposible para un sistema de coacutemputo distribuido ga-rantizar simultaacuteneamente dos de las tres propiedades siguientes
Consistencia (Consistency) es decir que todos los nodos vean la mismainformacioacuten al mismo tiempo Se busca que un cambio en el sistema soacutelose ejecute satisfactoriamente si y soacutelo si se efectuacutea a todos las maacutequinasde tal forma que los datos entre ellos nunca difieren y la respuesta a unapeticioacuten sea la misma independientemente del nodo que la atienda
Disponibilidad (Availability) esto es la garantiacutea de que toda peticioacuten debeobtener una respuesta (servicio funcional) aunque exista inconsistenciaentre nodos
Tolerancia al particionado (Partition Tolerance) es decir que el sistemasiga funcionado a pesar de un fallo en la comunicacioacuten entre los equipos
Por todo lo expresado anteriormente conseguir un sistema distribuido capazde ofrecer procesamiento de forma transparente implica una arquitectura TIcompleja Se requieren de subsistemas y herramientas que permitan la cohesioacutenentre todos los nodos
Gestor de los recursos de las diferentes maacutequinas
Monitorizacioacuten tanto de los servicios activos como de la funcionalidad delsistema ademaacutes de poliacuteticas para recuperacioacuten de fallo
Protocolos de consenso que permitan a los nodos ser consistentes con elestado global del cluster
6urlhttpsgroupscsailmitedutdspapersGilbertBrewer2pdf
9
Herramientas de descubrimiento de servicios que permita la comunicacioacutenentre tareas distribuidas
Planificadores Encargados de distribuir las tareas y procesos en las dife-rentes maacutequinas asignaacutendole parte de su capacidad
Los planificadores del ingleacutes cluster schedulers son un componente funda-mental por lo que vamos a entrar un poco maacutes en detalle en ellos
Planificadores (Cluster Schedulers)
Es el software encargado de monitorizar los recursos usados por cada maacute-quina perteneciente a un cluster y distribuir la carga de trabajo entre ellas deacuerdo a un poliacutetica o reglas
Este tipo de herramientas comparten cierta terminologiacutea que es relevantedefinir
Tarea Unidad de trabajo computacional comprendida por una secuenciade instrucciones datos de entrada y recursos asociados Por ejemplo laejecucioacuten de un comando o el arranque de una base de datos
Nodo Cualquier maacutequina integrante de un cluster En una arquitecturamaestro-esclavo se definen dos roles
bull Cliente Agente Esclavo Aquellos ordenadores que se encargan deejecutar las tareas
bull Maestro Servidor Su objetivo es mantener el estado del cluster ygestionar sus recursos
411 Clasificacioacuten
A lo largo de los uacuteltimos antildeos se han desarrollado diferentes tipos de plani-ficadores[2]
Monoliacutetico
Un solo planificador que se encarga de distribuir todas las tareas entran-tes La mayoriacutea de los planificadores en computacioacuten de alto rendimiento asiacutecomo Borg desarrollado por Google son de este tipo En la figura 3 se pue-de observar de forma graacutefica el procedimiento siendo las cajas grises maacutequinaspertenecientes al cluster y los ciacuterculos las tareas a asignar
10
Figura 3 Planificador monoliacuteticoFuente httpswwwclcamacuk
Planificacioacuten de dos niveles
La mayoriacutea de los clusters ejecutan aplicaciones con distintas necesidadesdesde procesos casi instantaacuteneos hasta servicios persistenteslo que implica dis-tintas necesidades de recursos
Por ello la planificacioacuten a dos niveles distingue dos funciones la gestioacutende recursos (gestor) y la disposicioacuten de las tareas (planificador) Cada serviciotiene su propio planificador de tal manera que el gestor les ldquoofertardquo recursosde acuerdo a una poliacutetica y los planificadores se encargan de escoger la maacutesadecuada Esto permite que el proceso de distribucioacuten sea maacutes acorde con lasnecesidades de los diferentes servicios Apache Mesos que detallaremos maacutesadelante sigue este esquema
Como desventaja cabriacutea sentildealar que esta programacioacuten implica que los pla-nificadores pierden la vista general de la infraestructura y las tareas soacutelo puedenejecutarse con los recursos que les son ofrecidos lo que dificulta la implementa-cioacuten de prioridades de ejecucioacuten de tareas entre otras
Figura 4 Planificador de dos niveles
11
Planificacioacuten de estado compartido
Muacuteltiples reacuteplicas del estado del cluster se actualizan independientementepara cada planificador como se observa en la figura 5 cuando sucede un cambiode forma local el planificador se encarga de informar al resto
Ejemplo de este tipo son Omega la evolucioacuten de Borg por parte de GoogleMicrosoft Apollo y Nomad que usaremos para los casos de uso
De entre las desventajas se puede destacar el hecho de que en general losnodos trabajan con informacioacuten desactualizada lo que conlleva una degradacioacutendel rendimiento en situaciones de alta contienda
Figura 5 Planificador de estado compartido
Planificacioacuten distribuida
En este caso no existe coordinacioacuten entre los distintos planificadores Cadauno de ellos funciona con su propia vista del cluster Las tareas pueden serorganizadas por cualquiera de ellos y desplegadas en cualquier parte del clusteren base a la aleatoriedad y multiplexacioacuten estadiacutestica de los flujos de trabajosin ninguacuten control central
Figura 6 Planificador distribuido
12
5 Herramientas
En la industria comienzan a aparecer soluciones software de coacutedigo abiertoque aglutinan los servicios necesarios para gestionar la infraestructura TI de ma-nera maacutes eficaz El objetivo es doble se busca facilitar la gestioacuten de los recursosde computacioacuten para organizaciones con instalaciones propias mediante su usocon un enfoque cloud esto es desplegar aplicaciones a traveacutes de un conjuntode ordenadores de forma transparente y sin tener en cuenta la infraestructurasubyacente o aprovechar el maacuteximo rendimiento de la infraestructura de losproveedores cloud puacuteblicos de forma que se tiene el maacuteximo control sobre eacutestapero no se depende de las soluciones propietarias permitiendo asiacute despliegueshiacutebridos
Entre estas herramientas se pueden destacar
OpenStack Proyecto desarrollado por la fundacioacuten del mismo nombre paraproporcionar servicios de infraestructuras (IaaS) basado en componentesque se comunican a traveacutes de APIs El componente Magnum incluye mo-tores de orquestacioacuten de contenedores
Kubernetes Sistema de orquestacioacuten de contenedores Docker creado por Goo-gle
CoreOs Sistema operativo basado en Linux disentildeado para despliegues distri-buidos sobre contenedores incluyendo mecanismos de descubrimiento deservicio y comparticioacuten de configuracioacuten
Docker Swarm Herramienta nativa de orquestacioacuten de contenedores Docker
YARN Entorno de gestioacuten de recursos y aplicaciones distribuidas de Hadoopuna libreriacutea software de procesamiento de grandes conjuntos de datos
Como podemos observar existe un gran rango de opciones para gestionar lainfraestructura desde un bajo nivel como puede ser OpenStack hasta Kuberne-tes o Docker Swarm que ofrecen exclusivamente orquestacioacuten de contenedores
En este trabajo se ha optado por Mesosphere DCOS y HashiCorp Nomadque se encuentran en el teacutermino medio su objetivo es proporcionar serviciosde plataforma que permitan la coexistencia dediferentes cargas de trabajo en elcluster
13
51 DCOS
DCOS es un proyecto de coacutedigo abierto7 creado y desarrollado por la empre-sa Mesosphere Se describe como un sistema operativo distribuido que abstraelos recursos de un cluster (capacidad de procesamiento memoria) permite lagestioacuten de muacuteltiples ordenadores de forma transparente y simplifica la instala-cioacuten de aplicaciones distribuidas
Su arquitectura se puede comparar a la de Linux en teacuterminos de nuacutecleo(kernel) y espacio de usuario El primero consta de recursos protegidos a losque no puede acceder el usuario e involucra operaciones de bajo nivel comoasignacioacuten de recursos o aislamiento de procesos En el espacio de usuario seejecutan las aplicaciones y servicios de maacutes alto nivel
Siguiendo con este siacutemil el nuacutecleo de DCOS estaacute basado en Apache Mesosque se explicaraacute en un apartado posterior y el espacio de usuario que estaacute com-prendido por los componentes del sistema esto es las diferentes herramientasque en conjunto conforman DCOS y los servicios encargados de planificar yejecutar las aplicaciones y tareas del usuario
Figura 7 Arquitectura DCOSFuente httpsdcosio
De entre los componentes que conforman DCOS destacan
Admin Router Balanceador de carga central basado en NGINX que dis-pone un proxy entre todos los servicios en el puerto 80 permitiendo sugestioacuten mediante la interfaz graacutefica Ademaacutes se encarga de la autenticacioacutenpara acceder al panel de administracioacuten
Cosmos Gestor de paquetes de las aplicaciones
Diagnostics Se ejecuta en todos los nodos y se encarga de monitorizar elestado de los daemons que sustentan DCOS
7Desde abril de 2016 httpsmesospherecomblog20160419open-source-dcos
14
Exhibitor Gestiona y automatiza el despliegue de ZooKeper la herra-mienta que provee de configuracioacuten centralizada y registro de nombres
Marathon Equivale al proceso init de los sistemas tipo Unix esto es elprimer proceso en ejecucioacuten tras la carga del kernel y que genera los demaacutesprocesos Se encarga de arrancar y monitorizar las aplicaciones y servicios
Mesos-DNS Servicio de DNS interno que define el dominio mesos pa-ra nodos y tareas en el cluster es decir permite resolver nombres conindependencia de la direccioacuten fiacutesica
Minuteman Balanceador de carga integrado a nivel TCPUDP disponiblepara las propias aplicaciones
Por otra parte se definen como servicios a las diferentes aplicaciones dis-tribuidas que DCOS permite instalar en el cluster y que pueden haber sidodesarrollados por la misma empresa Mesosphere o por terceros por ejemploApache Spark Jenkins o Apache Hadoop En la figura 8 se muestra un diagramade los servicios disponibles incluyendo algunos de las aplicaciones distribuidasque soporta DCOS
Figura 8 Servicios DCOSFuente httpsdcosio
511 Apache Mesos
El nuacutecleo de DCOS estaacute basado en Apache Mesos un proyecto de coacutedigoabierto creado por la Universidad de California Berkeley y desarrollado actual-mente por la fundacioacuten Apache Se trata de un administrador de clusters queabstrae los recursos y los dispone para diferentes aplicaciones y entornos de tra-bajo distribuidos (frameworks) mediante una interfaz comuacuten En el momento deredaccioacuten de este proyecto Apache Mesos soportaba una variedad de entornosque abarcaba desde Big Data (Apache Spark Hadoop) hasta bases de datos(Cassandra Hypertable)
15
Arquitectura
Mesos se basa en la asignacioacuten de dos roles diferentes a los nodos
Maestros (Masters) Se encargan de la gestioacuten y reparticioacuten de los recursospara los diferentes entornos de trabajo mediante ldquoofertas de recursosrdquo deacuerdo a los disponibles y a la poliacutetica de asignacioacuten (planificacioacuten en dosniveles)
Esclavos (Slaves) Ordenadores donde se ejecutaraacuten las aplicaciones y cu-yos recursos son ofertados por los maestros
En el caso de fallo del maestro las tareas pueden seguir ejecutaacutendose perono se podraacute asignar nuevos recursos ni tareas por ello pueden existir varios enel cluster para configuraciones de alta disponibilidad pero soacutelo uno orquesta alos esclavos
Para la eleccioacuten del master liacuteder Mesos usa Apache ZooKeeper un proyectode software desarrollado por la misma fundacioacuten cuyo objetivo es proveer deun servicio de configuracioacuten centralizado y registro de nombres8
Por otra parte los entornos de trabajo son los programas que deciden final-mente queacute recursos se van a usar y se encargan de que los esclavos ejecuten lastareas Eacutestos se ejecutan sobre Mesos y constan de dos componentes
Planificador (Scheduler) Optimiza y decide los recursos a utilizar de losofertados informando a los Masters
Procesador (Executor) Ejecuta las aplicaciones o servicios en los esclavos
El objetivo final es conseguir una interfaz liviana tolerante a fallos paracualquier tipo de entorno de trabajo de tal manera que en los esclavos del clusterpuedan ejecutarse simultaacuteneamente tareas con necesidades y duracioacuten diferentesPara ello se basa en dos conceptos asignacioacuten y aislamiento de recursos
Asignacioacuten de recursos
En el cluster pueden coexistir entornos de trabajo con tareas de larga dura-cioacuten y con gran consumo de recursos con tareas cortas que los ocupan y liberancon rapidez El maestro integra un moacutedulo de asignacioacuten de recursos (allocationmodule) que se encarga del algoritmo de distribucioacuten
En el momento de escribir este proyecto estaban desarrollados dos moacutedulosuno mediante el cual el usuario puede asignar prioridades y otro que implementa
8httpszookeeperapacheorg
16
el algoritmo Dominant Resource Fairness9 a grandes rasgos se determina entodos los esclavos la tarea en ejecucioacuten que necesita maacutes recursos y se calcula laproporcioacuten del recurso de mayor peso con respecto al total por ejemplo si unatarea ocupa 2 GB de memoria con respecto a 10 GB totales que tiene el clusterse le asigna un dominant share del 20 la tarea se asignaraacute al nodo con menordominant share
Aislamiento de recursos
Para conseguir que tareas de diferentes entornos de trabajo y con distin-ta naturaleza se ejecuten simultaacuteneamente en un mismo nodo Mesos usa loscontenedores Linux (descritos en la seccioacuten 3)
Funcionamiento
La figura 9 muestra el esquema de la arquitectura de Apache Mesos conalta disponibilidad (tres maestros) y con dos entornos de trabajo ejecutaacutendo-se Hadoop que permite el almacenamiento y procesamiento de gran cantidadde datos para proyectos de big data y un sistema que implementa la interfazsistema de paso de mensajes MPI
Como se puede observar el sistema ZooKeeper elige a un solo maestro comoliacuteder y eacuteste orquesta el cluster comunicando los esclavos con los planificadoresde los diferentes entornos de trabajo Tambieacuten se puede observar como las tareasde los distintos entornos estaacuten distribuidas entre los tres esclavos disponibles
Figura 9 Arquitectura de Apache MesosFuente httpsmesosapacheorg
El proceso de asignacioacuten se realiza como sigue en primer lugar un usuariosolicita la ejecucioacuten de una tarea mediante la interfaz de cada entorno de traba-jo (interfaz graacutefica API HTTP ) De forma paralela un esclavo informa almaestro de los recursos que tiene libres En consecuencia eacuteste se lo notifica almoacutedulo de asignacioacuten que en funcioacuten de su configuracioacuten decide cuaacutento ofertar
9httpspeopleeecsberkeleyedu~aligpapersdrfpdf
17
y a queacute entorno de trabajo y enviacutea la oferta a los planificadores Eacutestos respondenal maestro con queacute recursos ha decidido usar para cada tarea Finalmente lastareas son enviadas al esclavo seleccionado el cual asigna los recursos indicadosal procesador (executor) quien finalmente las ejecuta
Cabriacutea pensar que esta metodologiacutea puede conducir a situaciones en lasque un entorno podriacutea quedarse con tareas sin ejecutarse a la espera de unaoferta satisfactoria para ello Mesos implementa un sistema de filtros medianteel cual los entornos especifican los requisitos miacutenimos que debe cumplir unaoferta por ejemplo se puede especificar en queacute nodos debe desplegarse la tareaEste sistema estaacute disentildeado asiacute con el objetivo de mantener lo maacutes transparenteposible esta herramientas de forma que acepte entornos de trabajo de distintasnaturalezas
512 Ejemplos de uso
Grandes empresas estaacuten usando Apache Mesos con eficacia de acuerdo a susnecesidades e infraestructuras Caben destacar
Ebay En el modelo de implementacioacuten continua en esta empresa10 cadadesarrollador cuenta con su propia instancia que se ejecuta en una maacutequinavirtual dedicada lo que ha conllevado un uso de los recursos poco eficiente Enuna prueba de concepto consiguieron realizar una herramienta de integracioacutencontinua distribuida basada en un cluster con Apache mesos y con el entornoMarathon y Jenkins
Apple Anuncioacute que el motor de su famosa herramienta de asistencia per-sonal para iPhones Siri estaacute desplegada sobre Apache Mesos11 Para ello handesarrollado su propio entorno para facilitar a los ingenieros a desplegar los ser-vicios que la herramienta necesita para resolver las peticiones de los usuarios
Twitter Desarrolloacute su propio entorno denominado Aurora y actualmentegestionan sus recursos y miden el coste de las tareas que los empleados usancon el objetivo de que sean conscientes del gasto que puede suponer un usoinadecuado de la infraestructura12
10httpwwwebaytechblogcom20140404delivering-ebays-ci-solution-with-apache-mesos-part-i11httpwwwbusinessinsidercomapple-siri-uses-apache-mesos-2015-812httpswwwlinuxcomNEWS4-UNIQUE-WAYS-UBER-TWITTER-PAYPAL-AND-HUBSPOT-USE-APACHE-MESOS
18
52 Nomad
Herramienta de coacutedigo abierto de gestioacuten de clusters creada y desarrolladapor Hashicorp13 que permite el despliegue de aplicaciones y procesos de formadistribuida
Las principales diferencias con Apache Mesos a grandes rasgos son
Arquitectura maacutes ligera Nomad soacutelo requiere de un fichero para funcionarejecutaacutendolo con las correspondientes configuraciones en todos los nodosrealiza las funciones de gestioacuten del cluster eleccioacuten de liacuteder planificacioacutende recursos y ejecucioacuten de las tareas
Centro de datos y regiones muacuteltiples Su arquitectura estaacute orientada afacilitar la gestioacuten de diferentes centros de datos geograacuteficamente distri-buidos
Entorno de ejecucioacuten Las tareas se definen y son interpretadas mediantecontroladores integrados en Nomad que se valen de los recursos y herra-mientas de los nodos clientes para ejecutarlas Esta integracioacuten dificultael desarrollo de controladores por parte de terceros a diferencia de Mesosque delega dicha responsabilidad en los entornos de trabajo externos alproyecto
Usa un planificador de estado compartido con respecto a la planificacioacutenen dos niveles de Mesos
Antes de entrar en maacutes detalle en la arquitectura es importante definir lossiguientes teacuterminos
Controlador (Driver) Software que se encarga de interpretar las definicionesde las tareas y ejecutarlas semejante a los procesadores de los entornosde trabajo de Mesos A la hora de redactar este proyecto Nomad contabacon controladores para contenedores Docker virtualizacioacuten de maacutequinasmediante el emulador QEMU aplicaciones java y archivos binarios
Grupo de trabajo (Task Group) Conjunto de tareas que se ejecutan en elmismo nodo cliente
Trabajo (Job) Conjunto loacutegico de tareas y grupos de trabajo que se despliegana la vez
Asignacioacuten (Allocation) Relacioacuten entre un grupo de trabajo y el cliente don-de se ejecuta
Evaluacioacuten (Evaluation) Proceso mediante el cual Nomad planifica y ges-tiona el registro o actualizaciones de los trabajos
13httpswwwhashicorpcom
19
Nomad sigue una arquitectura maestro-esclavo similar a la de Apache Mesosmuacuteltiples servidores acuerdan entre siacute un liacuteder que gestiona la planificacioacuten detareas en los clientes que soacutelo conocen sus asignaciones y las ejecutan
Todos los servidores participan paralelamente en tareas de planificacioacuten derecursos y asignacioacuten de tareas y ademaacutes entre ellos eligen un liacuteder que seencarga de la coordinacioacuten de la suscripcioacuten de los clientes al cluster y de lagestioacuten de las peticiones
Los clientes estaacuten configurados para comunicarse con el servidor usando lla-madas a procedimiento remoto (RPC por sus siglas en ingleacutes) que permite unordenador ejecutar coacutedigo en otra maacutequina Mediante esta tecnologiacutea los nodosclientes avisan de su estado e informa de sus asignaciones recursos y controla-dores disponibles
Existe la posibilidad de gestionar varios centros de datos agrupados en regio-nes eacutestas son independientes pero permite definir tareas o comprobar el estadode todas ellas desde cualquier punto A continuacioacuten se muestra una figura dela arquitectura a alto nivel de esta configuracioacuten
Figura 10 Arquitectura multi-regioacuten en NomadFuente httpswwwnomadprojectio
La herramienta se sustenta sobre tres protocolos fundamentales un protocolode consenso entre los servidores para compartir informacioacuten sobre su estado yel liacuteder un protocolo Gossip para la gestioacuten entre regiones y el planificador detareas
521 Protocolo de consenso Raft
El objetivo es obtener consistencia en un conjunto de nodos que comparteninformacioacuten es decir si un cliente realiza un cambio que todos los nodos veanla misma informacioacuten a la vez y ademaacutes sea tolerante a fallos Para ello se basaen el algoritmo Raft[13] que se detalla brevemente a continuacioacuten
20
Los nodos participantes en el algoritmo pueden estar en tres estados
Liacuteder (Leader) Todos los cambios que realicen en el cluster pasan por eacutel pri-mero
Seguidor (Follower) Nodo pasivo cuya responsabilidad es responder a laspeticiones del nodo liacuteder
Candidato (Candidate) Maacutequina que no ha encontrado liacuteder y solicita sueleccioacuten
Supongamos que tenemos cinco equipos que acaban de arrancar el protocoloEn la figura 11 se observan los nodos y sus respectivos registros a la derecha
Figura 11 Equipos sin consenso ejecutando el protocolo RAFTFuente httpsgithubcomongardieraftscope
Al comenzar todos los nodos son seguidores esperando recibir comunicacioacutende un nodo que actuacutee como liacuteder Cada nodo tiene un tiempo de espera aleatoriodespueacutes del cual si no es informado por un liacuteder pasa a estado candidato y pideel ldquovotordquo al resto de los participantes El algoritmo divide el tiempo en plazos uncandidato pasa a liacuteder si recibe la mayoriacutea de los votos en un plazo determinadoSe define mayoriacutea o cuoacuterum (quorum) comolceil
N2rceil
+ 1 (1)
donde N representa el nuacutemero de nodos
Para el ejemplo propuesto de 5 equipos se requieren de 3 votos Soacutelo losnodos que se encuentren en estado seguidor pueden votar una uacutenica vez a laprimera solicitud que reciba dentro de un plazo
Supoacutengase que el nodo denotado con S1 ha cumplido su tiempo de espera yrealiza la peticioacuten de voto (figura 12) A partir de este momento se pueden dartres casos
La maacutequina gana la eleccioacuten y pasa a ser liacuteder informando al resto
Otro servidor se establece como liacuteder en el mismo momento
Varios nodos pasan a ser candidatos por lo que ninguno consigue los votos
21
Figura 12 Un equipo pasa a estado candidato (RAFT)
Si un candidato recibe un aviso de un liacuteder en el mismo plazo el primeropasa a ser seguidor y se acaba la eleccioacuten de liacuteder
Por otro lado si un equipo candidato no recibe los votos en el plazo y agotasu tiempo de espera avanza al siguiente plazo y repite el proceso de votacioacutenLa tercera posibilidad puede conllevar a un estado indefinido ya que varioscandidatos pueden agotar su tiempo de espera al mismo tiempo y repartir losvotos Para solventarlo el algoritmo establece tiempos de espera aleatorios paralos candidatos
Siguiendo con el ejemplo propuesto el servidor S1 pasa a ser el liacuteder Cadacierto tiempo eacuteste debe realizar avisos a los nodos seguidores para no agotar sutiempo de espera
En este momento el cluster de servidores estaacute en ldquoconsensordquo y la informacioacutenen todos los nodos estaacute actualizada Un cambio en la informacioacuten inicia unproceso de replicacioacuten el liacuteder registra el cambio lo pasa al resto de nodos yuna vez eacutestos responden el cambio se hace efectivo
Supoacutengase que se realiza un cambio en los datos en la figura 13 en la partederecha se observa el cambio en el registro del servidor S1 que informa a losnodos seguidores En consecuencia los nodos registran el cambio y responden aS1
Figura 13 Cambio en un registro (RAFT)
Una vez el cuoacuterum (en el ejemplo tres equipos) informa al liacuteder de que
22
ha registrado el cambio el liacuteder lo hace efectivo en su sistema y notifica a losnodos que hacen lo mismo En la figura 14 el enviacuteo todaviacutea no ha llegado ala maacutequina S3 y se observa que no ha hecho efectivo el cambio (en el registroaparece punteado)
Figura 14 Aprobacioacuten del resto de equipos (RAFT)
Este protocolo funcionaraacute correctamente mientras exista un nuacutemero de nodosen funcionamiento igual o superior al cuoacuterum en el ejemplo propuesto elcuoacuterum es tres por lo que el sistema puede tolerar la caiacuteda de dos de los equipos
522 Protocolo gossip SWIM
Nomad permite la gestioacuten simultaacutenea de varios centros de datos reparti-dos en regiones geograacuteficamente separadas requiriendo de un protocolo ligeroque mantenga a los miembros actualizados sobre los participantes del conjun-to Para ello usa una ligera variante del protocolo SWIM[3] (Scalable Weakly-consistent Infection-style Process Group Membership Protocol) desarrollada porHashiCorp Estaacute clasificado como un protocolo de tipo gossip que debe su nom-bre a la semejanza con coacutemo se distribuye un rumor en una red social
SWIM se sustenta en dos caracteriacutesticas fundamentales la deteccioacuten de fallosy la distribucioacuten de la informacioacuten relativa a los miembros A continuacioacuten sedetalla el funcionamiento de ambos componentes
Deteccioacuten de fallos
Este componente tiene dos paraacutemetros el periodo de protocolo T y el nuacutemerode subgrupos de deteccioacuten de fallos k en los que se dividen los nodos Paracomprobar la comunicacioacuten entre dos maacutequinas usa la utilidad ping basadaen el protocolo ICMP La deteccioacuten de caiacuteda de un servidor sigue el siguientealgoritmo
Durante el periodo T cada miembro Mi de un subgrupo elige otro al azar Mjdel mismo subgrupo y le enviacutea un mensaje ping para comprobar su estado Enel caso de que se cumpla un tiempo de espera determinado por una estimacioacuten
23
del tiempo de ida y vuelta (RTT por sus siglas en ingleacutes) de la red y no hayarespuesta Mi le vuelve a enviar un mensaje ping indirectamente a traveacutes deun nuacutemero k de miembros escogidos aleatoriamente De no recibir ninguna res-puesta Mi establece que Mj ha sufrido un fallo y lo etiqueta como ldquosospechosordquoinformando al componente de distribucioacuten
Figura 15 Diagrama de tiempo del protocolo SWIMFuente httpswwwcscornelledu
Componente de distribucioacuten
Se encarga de informar de cualquier cambio en los miembros a todo el con-junto Los eventos de nodo caiacutedo y la unioacuten o disociacioacuten de un miembro setransmiten a todos los servidores para que actualicen sus lista Para distribuirla informacioacuten a todos los nodos se podriacutea usar el meacutetodo de multicast perosuele estar deshabilitado Por ello se utiliza una teacutecnica de transmisioacuten denomi-nada Piggybacking mediante la cual se adjunta a los propios mensajes PINGy ACK del algoritmo la informacioacuten a distribuir reduciendo asiacute la congestioacutenen la red
523 Planificacioacuten
Proceso encargado de distribuir las tareas entre los nodos clientes de acuerdoa su estado
El planificador de Nomad estaacute basado en las publicaciones de Google sobresus herramientas de gestioacuten de clusters Borg y Omega14 y entiende los trabajosdescritos por el usuario como un estado deseado es decir su despliegue en unamaacutequina cliente de forma correcta y los clientes como el estado actual esto eslo que se encuentra en ejecucioacuten El registro actualizacioacuten o cancelacioacuten de un
14httpresearchgooglecompubspub43438html
24
trabajo asiacute como el fallo de un nodo cliente implican un cambio de estado atramitar por el sistema lo que se define como evaluacioacuten (evaluation) Esto uacutelti-mo supone comparar el estado actual (clientes) con el estado deseado (conjuntode trabajos registrados) y enviarlos a los planificadores correspondientes que seencargaraacuten de asignar las tareas a los nodos clientes
Figura 16 Procedimiento de asignacioacuten en NomadFuente httpswwwnomadprojectio
En la figura 16 se observa el flujo de trabajo en el que las distintas evalua-ciones se encolan en el evaluation broker que se ejecuta en el servidor liacuteder ygestiona las evaluaciones pendientes asignaacutendoles prioridades
A continuacioacuten los nodos servidores ejecutan los scheduling workers queprocesan las evaluaciones llamando a los distintos planificadores que generanun plan de asignacioacuten esto es un conjunto de relaciones entre las tareas y losnodos clientes donde se ejecutaraacuten Este proceso se divide en dos fases primerose descartan aquellos clientes que no cumplan los requisitos y posteriormentese asigna una calificacioacuten al resto Se selecciona el nodo con mayor puntuacioacuteny se encola el plan en el gestor que se ejecuta en el servidor liacuteder Existen tresplanificadores de acuerdo al tipo de trabajo
Service Incluye aquellos trabajos que estaacuten destinados a ejecutarse en un pe-riacuteodo largo de tiempo Para realizar las asignaciones el planificador evaluacuteala mayor parte de los nodos y usa una versioacuten del algoritmo Best fit in-fluenciada por el trabajo de Google en su herramienta Borg Se trata deun algoritmo de planificacioacuten que sacrifica tiempo a cambio de maximizarel rendimiento de los clientes asignando la tarea a la maacutequina que tengala mayor carga de trabajo con el objetivo de reducir equipos en funciona-
25
miento
Batch Tareas que incluyen listas de comandos en general de menor duracioacuteny que no requieren interaccioacuten con el usuario Se vale del algoritmo deSparrow desarrollado por la universidad de Berkeley15 para limitar losnodos clientes a evaluar
System Trabajos destinados a ejecutarse en todos los nodos incluso los que seunen al cluster posteriormente
Core Mantenimiento interno de Nomad
Una vez se ha realizado el proceso de planificacioacuten el nodo liacuteder lo registra enla cola de planes (plan queue) que se encarga de asignarles prioridad y manejarcondiciones de carrera es decir que no accedan a los recursos de los clientes sincontrol y evitar que eacutestos superen su capacidad
La maacutequina liacuteder del conjunto puede de este modo aceptar una asignacioacuteny ser ejecutada por los clientes o por el contrario rechazaacutersela al planificadorlo que implicariacutea realizar un plan parcial o totalmente nuevo
Finalmente el estado de las evaluaciones se actualizan y los clientes soninformados de las asignaciones ejecutaacutendose las tareas
15httppeopleeecsberkeleyedu~keopublicationssosp13-final17pdf
26
6 Casos de uso y despliegue
Con el objetivo de mostrar las posibles utilidades que este tipo de sistemaspueden tener en las infraestructuras TI actuales se han desplegado las dos he-rramientas en la nube Microsoft Azure usando su servicio cloud de instancias demaacutequinas virtuales Linux para simular un conjunto de ordenadores conectadosentre siacute por una red LAN Sobre ellas se ha implementado dos casos de usouna aplicacioacuten web con una arquitectura con cierta orientacioacuten a microserviciosy un sistema de integracioacuten continua
El coacutedigo y todos los ficheros de configuracioacuten se pueden encontrar en elrepositorio del proyecto en GitHub16
61 Aplicacioacuten Web
Se busca simular el proceso de adaptacioacuten de una solucioacuten web para su des-pliegue en un sistema distribuido con las herramientas anteriormente descritascon el objetivo de aumentar tanto su escalabilidad como disponibilidad medianteredundancia
Se ha partido de una aplicacioacuten ya existente17 un servicio de almacenamien-to y reproduccioacuten de canciones A grandes rasgos este servicio permite crearusuarios subir canciones con sus respectivas portadas tener playlists propias yescuchar las canciones a traveacutes de un navegador web
La solucioacuten estaacute dividida en 4 partes (figura 17)
Una vista web con la loacutegica
Un almacenamiento conectado en red (NAS por sus siglas en ingleacutes)
Una API REST para gestionar las peticiones al almacenamiento
Base de datos NoSQL basada en MongoDB
La nueva tendencia de los proyectos web es su implementacioacuten en contene-dores Docker ya que facilitan su portabilidad y ofrecen un procedimiento dedespliegue raacutepido sobre todo a la hora de desarrollar y realizar pruebas en en-tornos de produccioacuten simulados Por ello en este caso se va a hacer uso de los
16httpsgithubcomAntonioAlfrzCloud-Orchestrators17httpsgithubcomsonsoleslpCDPSfy
27
motores de orquestacioacuten de contenedores de ambas herramientas Marathon enDCOS y el controlador Docker en el caso de Nomad
Figura 17 Arquitectura aplicacioacuten web
A continuacioacuten vamos detallar el despliegue en ambas herramientas de es-ta solucioacuten y observar tanto queacute dificultades se encuentran como que ventajasofrecen El objetivo final es adaptar el proyecto modificaacutendolo lo menos posiblecon objeto de analizar la capacidad de estas herramientas para desplegar cual-quier aplicacioacuten sin que eso conlleve la modificacioacuten de la arquitectura de eacutestaes decir que no sea dependiente del entorno
611 DCOS
Se ha descrito DCOS como una herramienta que se despliega sobre un con-junto de ordenadores y que permite instalar gestionar el despliegue de sistemasdistribuidos
Microsoft Azure cuenta con una plantilla para desplegar en su servicio cloudun cluster de maacutequinas virtuales con DCOS ya instalado que cuenta con
Maacutequinas maestras (1 3 o 5 a seleccionar por el usuario) configuradascomo un conjunto de disponibilidad esto eso Azure da ciertas garantiacuteasde que al menos una maacutequina estaraacute en funcionamiento
Maacutequinas agentes Por motivos de seguridad se distinguen dos roles
bull Nodos privados solo accesibles desde la red interna y configuradoscomo un conjunto de escala un recurso de Azure para gestionar ydesplegar maacutequinas con configuraciones ideacutenticas para permitir unraacutepido escalado
bull Un equipo conectado accesible desde Internet a travntildees de un balan-ceador de carga puacuteblico y situado en una subred externa
28
Dos balanceadores de carga
bull La interfaz puacuteblica del cluster que se conecta con el cliente puacuteblicobull Acceso a los equipos maestros para el administrador que soacutelo permiteconexioacuten mediante SSH y credenciales
Almacenamiento para todas las maacutequinas
Configuraciones necesarias de red y seguridad
En la figura 18 se observa un diagrama de la infraestructura
Figura 18 Infraestructura en Azure
El primer obstaacuteculo es la persistencia de estado de la aplicacioacuten que seconsigue gracias a una base de datos no relacional basada en MongoDB asiacutecomo el almacenamiento de las canciones Para implementarla tenemos variasposibilidades
Montar un sistema externo de almacenamiento conectado en red en todoslos agentes donde se ejecuten las tareas de esta manera si una tarea pasade un nodo a otro por cualquier motivo puede tener acceso a los mismosficheros (opcioacuten del caso de uso original)
Implementar un sistema de ficheros distribuidos en los agentes
Usar los servicios de almacenamiento de las nubes puacuteblicas
Aprovechar el sistema de voluacutemenes persistentes de Apache Mesos Eacutestepermite reservar recursos de un agente de forma que al arrancar una tarease crea un volumen independiente del ciclo de vida de eacutesta con ello esosrecursos donde se ha almacenado la informacioacuten pueden volver a ofrecerseal mismo entorno de tal manera que otra tarea pueda acceder a ella
DCOS aprovecha este sistema de voluacutemenes persistentes y permite instalarbases de datos distribuidas como ArangoDB o Apache Cassandra sin embargoesto implicariacutea modificar todo el coacutedigo referente al modelo de la base de datos
29
Por motivos de eficiencia y latencia asiacute como de una mayor gobernabilidadde los datos la mejor opcioacuten es usar el recurso de voluacutemenes persistentes queofrece Apache Mesos ya que de esta manera se gestionariacutea la aplicacioacuten completamediante una uacutenica herramienta Sin embargo esto implica que la informacioacutense encuentra exclusivamente en el agente donde se haya ejecutado la tarea y porlo tanto se sigue requiriendo de software externo para distribuir la informacioacutenpara que se accesible para todos los agentes A la hora de realizar este proyectose encontraba en desarrollo Flocker una solucioacuten desarrollada por ClusterHQque permite compartir los voluacutemenes de Docker a traveacutes de un cluster quesi bien es compatible con el planificador de Mesos el proyecto se encontrabatodaviacutea en fases tempranas de desarrollo y los sistemas de almacenamiento quesoporta quedaban fuera del aacutembito de este trabajo
Por todo ello dado que las maacutequinas se han desplegado en la nube puacuteblicade Azure se decidioacute usar su servicio de almacenamiento de objetos para lascanciones y otra maacutequina para desplegar MongoDB y asiacute mantener el modelode datos original de la aplicacioacuten La diferencia del almacenamiento de obje-tos con respecto a nivel de fichero es que el primero no tiene jerarquiacutea paraorganizar los archivos eacutestos se guardan como objetos (con sus metadatos) enun mismo espacio soacutelo diferenciaacutendose por un identificador uacutenico esto implicaentre otras cosas que se puede acceder a un fichero dado uacutenicamente su IDindependientemente de la localizacioacuten fiacutesica de eacuteste facilitando pues la gestioacuteny el desarrollo
El coacutedigo del proyecto se ha modificado en los siguientes apartados
Las direcciones de la base de datos y los balanceadores de carga asiacute comosus puertos estaban originalmente fijos Se han configurado como variablesde entorno para facilitar el descubrimiento del servicio y hacer transpa-rente la aplicacioacuten al entorno de despliegue
La API REST se ha adaptado al almacenamiento en Azure en vez de enlocal
Estas modificaciones no suponen un cambio sustancial pero permiten separala persistencia de las tareas ejecutadas por DCOS lo que facilita en granmedida su ejecucioacuten al ser totalmente sin estado y ademaacutes implican tenerlos datos bajo un mayor control
Para la orquestacioacuten de contenedores se va a usar el entorno Marathondesarrollado tambieacuten por Mesosphere Eacuteste se puede usar a traveacutes de una interfazgraacutefica la interfaz de liacutenea de comandos (en lo que sigue CLI por sus siglas eningleacutes) de DCOS o con su API HTTP
Primero se han publicado la imaacutegenes de los contenedores que encapsulanla interfaz web y la api de la aplicacioacuten en el repositorio puacuteblico DockerHub
Los despliegues en este entorno se describen mediante ficheros JSON en losque se detalla entre otras opciones la imagen del contenedor los puertos a usar
30
los recursos que debe ocupar en un nodo o las instrucciones de monitorizacioacuten
Para el servicio de descubrimiento DCOS ofrece la posibilidad de asignardirecciones IP virtuales (VIP por sus siglas en ingleacutes) a tareas que se compartenen todos los nodos DCOS lleva integrado un balanceador de carga a nivel TCP(el componente denominado Minuteman) que balancea entre las direccionesvirtuales de las tareas y todas las instancias de eacutestas a lo largo del cluster Estoes necesario por dos motivos equilibrar la carga de los equipos con el fin deevitar un punto de uacutenico fallo mediante redundancia y evitar la contienda dedirecciones al ejecutar las tareas en puertos aleatorios
Este balanceador de carga estaacute basado en el trabajo de Michael Mitzenma-cher The Power of Two Choices in Randomized Load Balancing18 A grandesrasgos el algoritmo mantiene una media moacutevil exponencial de latencias paracada destino (backend) ademaacutes de las caiacutedas consecutivas Si un destino noresponde a una negociacioacuten en tres pasos (three way handshake) de forma con-secutiva en un periodo inferior a 5 ms se considera caiacutedo El algoritmo iterasobre los destinos disponibles en base a su histoacuterico de fallos y escoge dos deforma aleatoria de los cuales coge el de mejor meacutetrica
Las direcciones virtuales soacutelo se pueden resolver dentro del cluster porello para implementar la interfaz puacuteblica de la aplicacioacuten esto es el balancea-dor de carga de la interfaz web usaremos un paquete de DCOS denominadomarathon-lb un balanceador basado en HAProxy y adaptado por MesosphereEn este caso equilibra la carga de todas instancias de las tareas ejecutadas porel entorno Marathon por sus etiquetas y permite ademaacutes definir como puntode entrada muacuteltiples hosts virtuales definidos por sus nombres completos dedominio (FQDN por sus siglas en ingleacutes) en nuestro caso la interfaz puacuteblicadel balanceador de Azure para los agentes
Por motivos de seguridad todas las tareas se ejecutan en los agentes privadoses decir los que son exclusivamente accesibles desde la red interna Por su partemarathon-lb se ejecuta en el agente puacuteblico que cuenta con IP puacuteblica y lospuertos 80 (HTTP) y 8080 abiertos de forma que la aplicacioacuten sea accesibledesde Internet Esto es posible debido a que Apache Mesos permite reservarrecursos mediante roles asignados a nodos para un uso especiacutefico De esta formala arquitectura vista desde la aplicacioacuten quedariacutea como en la figura 19
18httpswwweecsharvardedu~michaelmpostscriptstpds2001pdf
31
Figura 19 Arquitectura de la aplicacioacuten web en DCOS
Ejecucioacuten
A la hora de desplegar la aplicacioacuten DCOS puede gestionarse medianteuna interfaz graacutefica o una interfaz de liacutenea de comandos La primera se accedea traveacutes de un navegador web en el puerto 80 (HTTP) y permite instalar losentornos disponibles observar el estado de los nodos y las tareas que se estaacutenejecutando y los ficheros de registros que eacutestas generan
La CLI permite el control desde un nodo o una maacutequina remota (suponiendoque los maestros tienen IP puacuteblica y el puerto 80 abierto) ya que DCOS tieneun sistema de autorizacioacuten que permite tener una interfaz puacuteblica con ciertasgarantiacuteas de seguridad
Por su parte cada entorno de trabajo puede ser controlado por la CLI peroademaacutes cuenta con sus propias interfaces Marathon expone una API HTTPen el puerto 8080 de la direccioacuten puacuteblica de los maestros del cluster asiacute comootra interfaz graacutefica Para desplegar un contenedor se podriacutea usar la CLI
$ dcos marathon app add lt f i l e j songt
O la API HTTP
$ cu r l minusX POST http lt ip_maestro gt8080v2apps minusd ltf i l e jsongt minusH Contentminustype app l i c a t i o n j son
32
612 Nomad
La arquitectura de Nomad es maacutes sencilla ya que solo requiere de un ficheroejecutable en todos los nodos para funcionar Si DCOS es la base de instala-cioacuten de entornos de terceros Nomad integra todas las funcionalidades baacutesicasesto es gestor de recursos planificador y ejecutor en los nodos cliente Estaherramienta cuenta con un menor tiempo de desarrollo y en el momento deescribir este documento cuenta exclusivamente con los siguientes controladoresen comparacioacuten con los entornos de DCOS
Motor Docker es decir funcioacuten de orquestacioacuten de contenedores
Ejecucioacuten de archivos binarios como comandos de Shell
Ejecucioacuten de aplicaciones Java
Virtualizacioacuten de maacutequinas mediante tecnologiacutea QEMU
Todos ellos necesitan que la tecnologiacutea subyacente esteacute instalada en las maacute-quinas clientes (Docker Java QEMU) Actualmente no permite el registro decontroladores por parte de terceros aunque estaacute planificado en un futuro ofreceruna interfaz para su desarrollo
Nomad no cuenta con el servicio de descubrimiento sin embargo puede inte-grarse con la herramienta Consul desarrollada por la misma empresa Por otrolado para el balanceo de carga usaremos un contenedor Docker con HAProxyuna herramienta de coacutedigo abierto que ofrece tanto servicios de proxy como debalanceador y cuyos ficheros de configuracioacuten completaremos con el proyectoConsul Template19
Consul
Consul sigue la misma arquitectura que Nomad es decir un nodo servidorque orquesta un conjunto de maacutequinas clientes y permite a los procesos que seejecutan en los equipos definirlos como servicios ofreciendo diversas caracteriacutes-ticas entorno a estos de los cuales vamos a usar dos
Descubrimiento de servicio Las maacutequinas clientes publican en el cataacutelogode servicios las tareas en ejecucioacuten y Consul les asigna nombres de dominioaccesibles por todos los miembros del cluster a traveacutes de la interfaz DNSincluida en esta herramientaConsul se integra con Nomad de forma que todas las tareas que se ejecu-ten en la segunda son automaacuteticamente publicados como servicios de laprimera de esta manera no hace falta conocer la direccioacuten de la maacutequinacliente donde se esteacute ejecutando el proceso ya que se puede acceder a eacutela traveacutes de su nombre de dominio de forma transparente Por ejemplo si
19[httpsgithubcomhashicorpconsul-template]
33
ejecutamos una tarea con ID web en el puerto 8080 se puede acceder aella en la direccioacuten webserviceconsul8080Para que las direcciones propias de Consul las resuelva su propio DNS y noel que esteacute asignado por defecto en la maacutequina usaremos la herramientadnsmasq20 que permite especificar la direccioacuten de un servidor DNS paraconsultas de direcciones especiacuteficas
Monitorizacioacuten Permite realizar comprobaciones del servicio y seguir su esta-do Aprovecharemos esta funcionalidad tanto para definir el propio procesode Nomad como servicio de Consul como las tareas desplegadas
HAProxy + Consul Template
HAProxy es una solucioacuten versaacutetil de coacutedigo abierto que ofrece solucionesde balanceo de carga y proxy Existen otras herramientas en el mercado comoNGINX o ldirectord sin embargo HAProxy suponiacutea una solucioacuten sencilla deconfigurar para mostrar el caso de uso
El uso de estas herramientas se debe a dos motivos para que no existacontienda con respecto a los puertos de los clientes usados por las tareas eacutestos sevan a asignar de forma dinaacutemica lo que en principio implicariacutea que la aplicacioacutendeberiacutea realizar consultas DNS de tipo SRV (que incluye puertos) a la interfazde Consul y balancear la carga entre tareas por redundancia y capacidad
Como la direccioacuten IP y puerto son variables cada vez que las tareas seactualicen o se reasignen es necesario volver a configurar HAProxy de formamanual Por ello HashiCorp ha desarrollado un programa denominado Con-sul Template que realiza peticiones sucesivas a la interfaz HTTP de Consul delas direcciones fiacutesicas de un servicio y reinicia automaacuteticamente el proceso deHAProxy Asiacute definiendo estas tareas como servicios Consul podremos tantomonitorizarlas como escalar las tareas dinaacutemicamente sin necesidad de cambiarel balanceador A partir del contenedor Docker oficial de HAProxy se ha desa-rrollado otro con la configuracioacuten baacutesica y con Consul Template para desplegarlocomo una tarea en Nomad
Despliegue
Se ha usado el mismo coacutedigo que en el apartado anterior con la persistenciaen el servicio de almacenamiento de Azure Desde la perspectiva del hardwarese implementaraacute la misma infraestructura que en el caso de DCOS (figura 18)estos es definiremos dos tipos de maacutequinas clientes un agente que se conectaraacutecon el balanceador de carga con nombre de dominio puacuteblico y donde se desple-garaacute el balanceador de carga de la vista web y agentes privados no accesiblesdesde fuera del cluster y donde se ejecutaraacuten el resto de tareas en la red inter-na La principal diferencia radica en las tareas que ejecutan HAproxy y ConsulTemplate que sustituye a las direcciones IP virtuales que ofrece DCOS
20httpwwwthekelleysorgukdnsmasqdochtml
34
Figura 20 Despliegue en Azure de Nomad+Consul
Cabe matizar que los balanceadores basados en HAProxy se implementanpor necesidad de la aplicacioacuten para el descubrimiento del servicio a diferenciade los de Azure que se implementan por motivos de seguridad y escalabilidaddel cluster en siacute
Configuracioacuten Nomad
Los ficheros de configuracioacuten de las maacutequinas maacutester y cliente son similaresy comparten la mayoriacutea de las opciones como por ejemplo el nombre del nodoo la interfaz de red donde escucha Nomad las peticiones Sus opciones son engeneral auto-explicativas sin embargo existen dos detalles que matizar
El proceso de Nomad escucha las peticiones tanto de los protocolos deconsenso como del usuario a traveacutes de una interfaz de red que se debeindicar en el fichero de configuracioacuten
En el caso de los clientes se deben indicar las direcciones de los servidoresdel cluster sin embargo se trata de un sistema dinaacutemico en el que losnodos pueden sufrir errores y cambiar de direccioacuten Por ello se ha definidoNomad como un servicio de Consul y asiacute poder definir la direccioacuten de losservidores como un nombre de dominio no por su direccioacuten fiacutesica que elservidor DNS de Consul se encargaraacute de resolver
Por defecto Nomad usa los siguientes puertos
API HTTP 4646 Peticiones HTTP y recepcioacuten de oacuterdenes mediante laliacutenea de comandos
RPC 4647 Protocolo de consenso entre los nodos del cluster
Serf 4648 Protocolo de gossip entre los servidores de los centros de datosgobernados por Nomad
35
Los dos uacuteltimos deben ser interfaces alcanzables por otros nodos sin embargo laAPI HTTP por motivos de seguridad deberiacutea ser local ya que en caso contrariocualquier persona con acceso a ella tiene el control sobre la herramienta Eacutestasolo deberiacutea estar accesible en un servidor o gestionarlo mediante una terminalSSH por ejemplo En este trabajo al ser una prueba de concepto se ha abiertoen todos los nodos
Trabajos de Nomad
Las tareas se detallan en ficheros con formato HashiCorp Configuration Lan-guage un derivado del formato JSON creado por la empresa que le da nombrecompatible con eacuteste y que permite comentarios
En estos ficheros se puede definir
La regioacuten y el centro de datos donde se ejecutaraacute (Nomad permite lagestioacuten de centros de datos geograacuteficamente distribuidos en regiones)
La poliacutetica de actualizacioacuten de la tarea
Grupo de tareas esto es que se ejecutaraacuten en el mismo nodo
El nuacutemero de grupos a ejecutarescalar asiacute como los liacutemite que debencumplir los nodos asignados
La poliacutetica de reinicio ante fallo o error
Tareas El controlador su configuracioacuten los paraacutemetros del servicio aso-ciado a registrar en Consul asiacute como los recursos que consume (puertosmemoria)
En nuestro caso usamos sobre todo el controlador Docker esto eso orques-tacioacuten de contenedores en los nodos clientes y tres de sus opciones
Imagen del contenedor Se han subido todas las imaacutegenes del proyecto a Doc-ker Hub donde por defecto se busca la imagen
Puertos Los puertos a usar por el contenedor que pueden ser estaacuteticos asigna-dos por el usuario o dinaacutemicos siendo Nomad el que se encarga de mapearun puerto libre del nodo cliente al expuesto por el contenedor
Servidores DNS Como usamos la interfaz DNS de Consul como descubri-miento de servicio se debe configurar el contenedor para que use cualquiernodo del cluster como servidor DNS
Configuracioacuten Consul
Al ser desarrolladas por la misma empresa los ficheros de configuracioacuten deConsul y Nomad comparten muchas opciones Consul tambieacuten acepta peticionesa traveacutes de una interfaz de red siendo los puertos usados por defecto
36
RPC 8300 8400 Maneja la peticiones del resto de nodos y usuarios
Serf 8301 8302 Protocolo gossip
HTTP API 8500
HTTPS API Desactivada por defecto
Interfaz DNS 8600
Se debe asignar a los protocolos internos del cluster esto es RPC y Serf unainterfaz alcanzable por los nodos y por el contrarioasignar a los dos uacuteltimos ala interfaz de loopback por motivos de seguridad
Cabe destacar que Consul tambieacuten cuenta con una interfaz graacutefica que per-mite ver el estado de los equipos y los servicios registrados y que se encuentra enel mismo puerto que la API HTTP en la direccioacuten httpIP_EQUIPO8500ui
Ejecucioacuten
Tanto Nomad como Consul requieren de la ejecucioacuten de un fichero en todoslos nodos integrantes del cluster Como prueba de concepto se ha decidido usardos servidores para ambos aunque cabe matizar que es un nuacutemero ineficienteya que la caiacuteda de uno de ellos supondriacutea la peacuterdida del cuoacuterum y por tantodel consenso del cluster
En primer lugar se arrancan los servidores que son los encargados de ejecu-tar el protocolo de consenso y gestionar el cluster y a continuacioacuten los clientesque no tienen praacutecticamente estado y dependen de los servidores
En el caso de Consul se debe indicar el directorio donde se guardan losficheros que describen los servicios asiacute como el archivo que especifica el resto delas opciones
1 Se inicia el primer servidor en uno de los equipos
$ consu l agent minuscon f i gminusd i r e t c consu l d s e r v i c e s minuscon f i gminus f i l e consu l_server j son
2 Los siguientes equipos deben unirse al anterior por lo que antildeadimos elargumento join con la direccioacuten del primer servidor Para el caso de otrosservidores
$ consu l agent minuscon f i gminusd i r e t c consu l d s e r v i c e s minuscon f i gminus f i l e consu l_server j son minus j o i n ltIP_servidor1gt
37
Una vez los servidores han alcanzado el consenso y elegido un liacuteder en losclientes
$ consu l agent minuscon f i gminusd i r e t c consu l d s e r v i c e s minuscon f i gminus f i l e c on su l_c l i en t j son minus j o i n ltIP_cualquierServ idorgt
El proceso para iniciar Nomad es igual y los comandos similares sin embargoya no es necesario indicar una direccioacuten IP fija en los equipos sino el nombre dedominio del servicio de Nomad registrado por Consul En el primer servidor
$ nomad agent minusc on f i g nomad_server j son
Y el resto de equipos (con su fichero de configuracioacuten correspondiente)$ nomad agent minusc on f i g nomad_server j son minus j o i n nomad s e r v i c e consu l
Por uacuteltimo para desplegar la aplicacioacuten web se han escrito tres ficherosque detallan las tareas de la interfaz web API y los balanceadores de cargaMediante la CLI
$ nomad run minusaddress=http lt ip_c lus te r gt4646 lt f i l e hclgt
O mediante la API HTTP de Nomad$ cu r l minusX POST minusd ltf i l e hclgthttp lt ip_c lus te r gt4646 jobltjob_namegt
Ansible
Como se puede comprobar con el aumento del nuacutemero de equipos pasa aser inviable manejar todos los nodos a traveacutes de terminal Ademaacutes como seha comentado con anterioridad Nomad requiere que en los nodos clientes es-teacuten instalados las herramientas que soporten las tareas por ejemplo el motorde Docker Por ello para facilitar tanto el arranque como la instalacioacuten de lasdependencias vamos a usar Ansible una herramienta de coacutedigo abierto desarro-llada en Python que permite gestionar configuraciones aprovisionar recursosdespliegue de aplicaciones de forma automaacutetica
A grandes rasgos esta herramienta funciona mediante ficheros en formatoYAML denominados play-books que describen un conjunto de pasos a ejecutaren una lista de equipos remotos Estos pasos son ejecutados por moacutedulos inde-pendientes a traveacutes de SSH es decir en cualquier ordenador con conexioacuten a los
38
hosts dado su contrasentildea o clave puacuteblica puede arrancar el script y realizariacutealos pasos de forma remota gestionando el cluster desde un solo equipo
Se han desarrollado guiones para lo siguiente
Descarga de los binarios de Nomad y Consul en todos los nodos copiade los ficheros de configuracioacuten baacutesicos y modificarlos de acuerdo a cadanodo (nombre del equipo direccioacuten IP)
Instalacioacuten de las dependencias
Arranque de Nomad y Consul
Ansible extiende su funcionalidad a traveacutes de moacutedulos independientes que per-miten por ejemplo instalar paquetes mediante herramientas de gestioacuten de pa-quetes (APT yum) aprovisionar automaacuteticamente maacutequinas virtuales de Ama-zon EC2
Algunas opciones de los ficheros de configuracioacuten de Nomad y Consul sondependientes del nodo particular por ejemplo la interfaz de red Para estetrabajo se ha realizado un moacutedulo para modificar los ficheros de configuracioacutende forma automaacutetica En el repositorio del proyecto se encuentra una carpetadonde se encuentran todos los ficheros necesarios para desplegar un clustertotalmente funcional solo requiere de una liacutenea de terminal con Ansible
$ ans ib l eminusplaybook minus i hos t s minusk ltssh_passgt minusu ltnode_usergt s i t e yml
39
62 Servicio de integracioacuten continua
Se ha implementado un sistema de integracioacuten continua que permite ejecu-tar tareas de compilacioacuten y pruebas de forma distribuida aumentando asiacute elrendimiento de los equipos En primer lugar se detallaraacute los motivos por los quepuede resultar beneficioso para las empresas una implementacioacuten de este tipo alo que seguiraacute los detalles del despliegue
621 DevOps
Metodologiacutea que defiende la comunicacioacuten y colaboracioacuten entre desarrolla-dores de software y los profesionales de operaciones a lo largo de todo el ciclo devida de una aplicacioacuten Estaacute muy relacionado con el desarrollo aacutegil de softwareesto es un enfoque para los proyectos que defiende el desarrollo iterativo e in-cremental donde los requisitos y soluciones evolucionan con el tiempo seguacuten lanecesidad del proyecto DevOps extiende esta filosofiacutea a todas los componentesde un servicio incluyendo sistemas y operaciones
Se trata de un concepto que cada organizacioacuten o empresa adapta a suspropias necesidades y procesos de negocio en este proyecto nos vamos a centraren la integracioacuten continua una praacutectica fundamental tanto del desarrollo aacutegilcomo de esta filosofiacutea
622 Integracioacuten Continua
Se define como una praacutectica de desarrollo software donde los miembros delequipo ponen en comuacuten su trabajo frecuentemente al menos una vez al diacutea21Cada integracioacuten se verifica con una compilacioacuten automaacutetica que incluye laejecucioacuten de pruebas para detectar errores de integracioacuten tan pronto como seaposible
Desde el punto de vista operativo esto supone automatizar la configuracioacutende equipos o el despliegue de maacutequinas virtuales donde compilar el proyecto yejecutar las pruebas y posteriormente eliminarlas Este flujo de trabajo se vebeneficiado en entornos distribuidos ya que el objetivo del desarrollador es com-probar el resultado de las pruebas raacutepidamente sin preocuparse del despliegueo los propios equipos
Para esta prueba de concepto vamos a usar Jenkins un servidor de integra-cioacuten continua escrito en Java que nos permite definir trabajos que contendraacutenla descripcioacuten tanto del entorno como su ejecucioacuten
Este sigue una estructura maestro-esclavo muy similar al de los gestores declusters usados en este proyecto el maestro contiene toda la loacutegica del servicio
21httpmartinfowlercomarticlescontinuousIntegrationhtml
40
trabajos autenticacioacuten y los esclavos son los encargados de la ejecucioacuten ensiacute Jenkins tiene varias viacuteas para aprovisionar los uacuteltimos
Mediante SSH
Interfaz graacutefica
Desarrollar un script propio
Ejecucioacuten de un fichero java
La ventaja de usar planificadores es que el despliegue de esclavos es dinaacutemicoes decir no tener una maacutequina especiacuteficamente configurada para ello DCOS yNomad se encargaraacuten de configurar estos despliegues en sus maacutequinas y poste-riormente eliminarlos Para ello se ha usado la uacuteltima opcioacuten definiendo tareasque descarguen el fichero java Con todo ello se consigue un entorno de inte-gracioacuten continua eficiente que ademaacutes permite la ejecucioacuten de otros servicios deforma independiente
Jenkins permite la creacioacuten de plugins que extienden sus funcionalidadesTanto Nomad22 como Apache Mesos cuentan con uno que permite su integra-cioacuten
Para esta prueba se va a usar el mismo proyecto que para el caso de usode orquestacioacuten de contenedores la aplicacioacuten web al que se le ha antildeadido untest para comprobar que se conecta correctamente a la base de datos medianteMocha un framework de Nodejs Por otro lado se antildeade el plugin de git ya queel coacutedigo se obtiene de GitHub el repositorio remoto de control de versiones delproyecto
El proceso general de ejecucioacuten seriacutea como sigue
1 Se ejecuta el maestro de Jenkins como tarea Docker partiendo de la imagenoficial
2 Al arrancar un trabajo se manda una tarea a los planificadores que laasignaraacuten a un nodo cliente Esta tarea consiste en la descarga del ficherode configuracioacuten Java y arrancarlo configurando el equipo como un clientede Jenkins temporalmente
3 Jenkins ejecuta el trabajo en el nuevo cliente en este caso iniciar la apli-cacioacuten web iniciar las pruebas y generar un informe
4 Se elimina el cliente
A continuacioacuten se detallan los matices de cada herramienta a la hora de imple-mentar este servicio
22Desarrollado por Ivo Verberk httpwwwivoverberknl
41
623 Jenkins con Nomad
El plugin permite la ejecucioacuten del fichero Java mediante dos controladorescontenedores Docker y Java En este proyecto nos hemos decantado por el pri-mero ya que nos ahorra instalar la maacutequina virtual de java en todos los nodoscliente Por ello se ha construido un contenedor base con Java para la ejecucioacutendel fichero de configuracioacuten y Nodejs para lanzar la aplicacioacuten web
El plugin se configura con la direccioacuten IP del cluster y el contenedor queejecuta el esclavo Jenkins Por su parte el trabajo en Jenkins se define conel repositorio en GitHub donde se aloja el coacutedigo del proyecto a probar y loscomandos a ejecutar en este caso npm update y npm test
624 Jenkins con DCOS
En el caso de DCOS su sistema de paquetes incluye Jenkins por lo queal instalarlo ya se tiene la configuracioacuten de Mesos totalmente funcional Sinembargo para ejecutar la aplicacioacuten en particular y las pruebas se requiere deNodejs en los equipos esclavos por ello debemos antildeadir un plugin de Jenkinsque permite instalar este entorno antes de ejecutar el trabajo Una vez hechoesto soacutelo queda definir la tarea igual que en el caso anterior
Cabe destacar que Mesosphere tambieacuten ha desarrollado un plugin que per-mite hacer despliegues en Marathon de tal manera que permitiriacutea con cadacommit del coacutedigo compilar la imagen del contenedor Docker y desplegarlaautomaacuteticamente aunque en este proyecto no se ha hecho pruebas de esta fun-cionalidad
42
7 Escalando la infraestructura
Uno de los factores clave que se busca a la hora de implementar sistemasdistribuidos es el poder escalar la infraestructura de forma maacutes sencilla estoes detectar que las maacutequinas estaacuten alcanzando el liacutemite de su capacidad yaumentar eacutesta ya sea mejorando sus caracteriacutesticas teacutecnicas o antildeadiendo maacutesnodos al cluster
El coacutedigo y todos los ficheros de configuracioacuten de esta seccioacuten tambieacuten sepueden encontrar en el repositorio del proyecto en GitHub23
71 Disentildeo
Microsoft Azure permite organizar los servicios cloud de forma loacutegica a traveacutesde grupos de recursos y asiacute poder crear o eliminar eacutestos en conjunto parauna aplicacioacuten determinada (por ejemplo una aplicacioacuten web suele requerir demaacutequinas virtuales bases de datos almacenamiento) Ademaacutes dispone dela opcioacuten de crear plantillas en formato JSON que permite al desarrolladordefinir los recursos y su interrelacioacuten para desplegar de forma automaacutetica unainfraestructura TI en la nube
Azure tambieacuten ofrece la posibilidad de monitorizar el estado de las maacutequinasvirtuales a traveacutes de extensiones lo que permite configurar el escalado automaacute-tico al alcanzar cierto liacutemite definido por el operador Eacutesta es a priori la formaen que deberiacutea implementarse hablando en teacuterminos de eficiencia sin embargoesta aproximacioacuten es totalmente dependiente de la plataforma es decir no sepuede extrapolar a otro proveedor o sobre recursos propios sin realizar un nue-vo disentildeo En este proyecto las tareas que son ejecutadas por estos equipos notienen estado ya que todo lo relativo a la persistencia lo hemos asignado fueradel cluster esto permite escalar la plataforma a traveacutes de otra aproximaciones
Las plantillas aceptan una serie de variables a indicar por el usuario entreotras los conjuntos de escala para definir los nodos aceptan una variable quedefine el nuacutemero de maacutequinas que los componen Por otro lado Azure ofreceuna API REST y kits de desarrollo software (SDK por sus siglas en ingleacutes) quepermiten su despliegue de forma programaacutetica Aprovechando estas facilidadesen este proyecto se va a aproximar la escalabilidad con el sucesivo desplieguede la infraestructura de forma automaacutetica se monitorizan los equipos y si sedetecta una maacutequina excesivamente cargada se aumenta el nuacutemero de equiposen la plantilla y se vuelve a desplegar
23httpsgithubcomAntonioAlfrzCloud-Orchestrators
43
En este proyecto se han disentildeado las plantillas para desplegar la arquitec-tura necesaria tanto de Nomad como de DCOS En el caso de la primera eldespliegue es maacutes descriptivo ya que incluye maacutequinas virtuales grupos de se-guridad redes En el caso de DCOS Azure cuenta con un servicio especiacuteficopara clusters gobernados por DCOS denominado Azure Container Service queincluye los componentes necesarios y la instalacioacuten ya realizada
72 Implementacioacuten
En primer lugar para monitorizar el estado de los equipos se va a usar laherramienta Nagios un sistema que permite controlar el estado del hardwarey los servicios de un equipo Se trata de una herramienta muy completa de laque se va a usar su capacidad para ejecutar comandos (plugins) en los nodospara detectar picos de carga generar alertas y ejecutar programas para estoseventos
Se ha desplegado una maacutequina virtual con esta herramienta en ambos siste-mas y se ha instalado una extensioacuten de Nagios (Nagios Remote Plugin Executor)en todos los nodos que permite ejecutar comprobaciones remotamente en con-creto para esta prueba de concepto medir el nivel de saturacioacuten de la unidadcentral de procesamiento (CPU por sus siglas del ingleacutes) Cuando sucede uncambio de estado de una maacutequina esto es cuando este paraacutemetro supera el liacutemi-te definido por el operador Nagios permite actuar en consecuencia ejecutandoprogramas por ello se ha desarrollado un script que ejecuta lo siguiente
Un programa desarrollado en Python con el SDK de Azure que modificalas plantillas y despliega los recursos
Un guioacuten de Ansible para instalar todos los componentes necesarios en lasnuevas maacutequinas y arrancar de nuevo el cluster y las aplicaciones
44
8 Resultados y conclusiones
En este uacuteltimo apartado se da una visioacuten global del proyecto asiacute como a lasconclusiones maacutes importantes a las que se ha llegado y posibles temas futurosde desarrollo
81 Comparacioacuten
Ambas herramientas ofrecen las funcionalidades para gestionar los recursoseficientemente ofreciendo a los desarrolladores una plataforma donde desplegarsus aplicaciones de forma distribuida independientemente de los equipos fiacutesicosy el hardware que las soporten
DCOS es una herramienta que en un comienzo fue privativa pero cuyos res-ponsables la empresa Mesosphere decidieron publicar una versioacuten de coacutedigoEacutesta nos permite gestionar un cluster de una forma sencilla y usable ademaacutes decomplementarlo con otras herramientas como el balanceador de carga integradoo la autenticacioacuten de usuarios ademaacutes estaacute basada en Apache Mesos un pro-yecto de relativa madurez y con el soporte de la Apache Software FoundationDe forma resumida DCOS ofrece muchas posibilidades y servicios a cambiode una arquitectura e instalacioacuten maacutes compleja
Por su parte HashiCorp con menor tiempo de desarrollo ha conseguidouna herramienta muy sencilla de desplegar que ademaacutes cumple con todas lasfuncionalidades baacutesicas ejecutando un simple binario en cada nodo se puededesplegar un gestor de clusters totalmente funcional Sin embargo no cuentacon todas las posibilidades de Mesos (Nomad cuenta con menos controladoresque entornos posibles de Mesos) ni con los antildeadidos de DCOS lo que implicael uso de otras herramientas para complementar el servicio (Consul HAProxy)
De entre las dificultades encontradas al usar estas herramientas y desplegaraplicaciones sobre ellas se puede destacar la depuracioacuten en ocasiones se desco-noce si un error viene de la propia herramienta de la aplicacioacuten desplegada o delequipo fiacutesico si no se cuenta con un sistema de procesamiento de registro unose puede encontrar con muacuteltiples terminales abiertas inspeccionando numerososficheros de registro buscando posibles errores Ademaacutes no dejan de ser solucio-nes que para usar eficientemente se debe conocer parte de su funcionamientoy sintaxis a la hora de describir la tareas lo que supone un esfuerzo antildeadido yaque cada una tiene sus particularidades y liacutemites
45
82 Conclusiones
En una sociedad cada vez maacutes digital las empresas deben adaptarse a unmercado cuya demanda de contenido no deja de crecer Las nuevas arquitecturascomo microservicios asiacute como la gran cantidad de datos generada implica queuna mejor gestioacuten de los recursos y la rapidez para desplegar o escalar solucionesdando valor al cliente lo maacutes raacutepido posible es uno de los objetivos de todas lasempresas de base tecnoloacutegica
Las ventajas que ofrecen los planificadores con aplicaciones distribuidas sonnumerosas sin ir maacutes lejos empresas tan punteras como Google llevan maacutesde 10 antildeos orquestando contenedores24 Por un lado permiten aumentar elrendimiento de los equipos propios y por otro implementar un servicio comoplataforma para despliegues distribuidos sobre cualquier conjunto hardware deesta forma se provee un servicio similar al de la nube puacuteblica pero con laprincipal diferencia de que se elimina la independencia con el proveedor (vendorlock-in) esto es las aplicaciones no tienen limitaciones impuestas por eacuteste talescomo lenguaje de programacioacuten o herramientas y permite despliegues hiacutebridosentre recursos propios y la nube
83 Objetivos conseguidos
Implementacioacuten de los planificadores propuestos en la nube Se ha en-tendido y detallado el funcionamiento de estas herramientas y se hanimplementado en el servicio de infraestructura de Microsoft Azure
Despliegue de aplicaciones y servicios distribuidos Servicios que se usanactualmente en la industria del desarrollo software asiacute como una aplica-cioacuten web con una arquitectura moderna han sido desplegados de formadistribuida en los equipos cumpliendo con la funcionalidad esperada ade-maacutes de consiguiendo una alta disponibilidad
Aproximacioacuten de arquitectura escalable Se ha hecho una aproximacioacutende infraestructura escalable de forma que sea parcialmente extrapolable aotros proveedores
24httpwwwnextplatformcom20160322decade-container-control-google
46
84 Liacuteneas de investigacioacuten
Siguiendo con la materia de este proyecto se presentan posibles liacuteneas deinvestigacioacuten
Analizar el despliegue con estas herramientas de aplicaciones de Big Datay comparar la eficiencia con respecto a soluciones especializadas
Analizar el rendimiento de los algoritmos de planificacioacuten antes pruebasde estreacutes y situaciones de alta contienda
Comparar el uso de estas herramientas con las praacutecticas actuales de laindustria o implementacioacuten en un sistema de produccioacuten real
47
Referencias
[1] LA Barroso y U Houmllzle laquoThe Datacenter as a Computer An Introduc-tion to the Design of Warehouse-Scale Machinesraquo En Morgan amp ClaypoolPublishers ()
[2] Systems Research Group ndash NetOS (University of Cambridge) The evolu-tion of cluster scheduler architectures 2016 url httpswwwclcamacukresearchsrgnetoscamsasblog2016-03-09-scheduler-architectureshtml
[3] A Das I Gupta y A Motivala SWIM Scalable Weakly-consistent Infection-style Process Group Membership Protocol Inf teacutec Dept of ComputerScience Cornell University url https www cs cornell edu ~asdasresearchdsn02-swimpdf
[4] D Dubhashi y A Das Mastering Mesos PACKT Publishing mayo de2016
[5] The Apache Software Foundation Apache Mesos documentation urlhttpsmesosapacheorg
[6] David Greenberg Building Applications on Mesos OrsquoReilly Media 2016[7] Armand Grillet Comparison of Container Schedulers Inf teacutec Technische
Universitaumlt Berlin[8] HashiCorp Consul documentation url httpswwwconsulio[9] HashiCorp Nomad documentation url httpsdcosio[10] Dan C Marinescu Cloud computing theory and practice Morgan Kauf-
mann 2013[11] Mesosphere DCOS documentation url httpswwwnomadproject
io[12] Microsoft Azure documentation url httpsazuremicrosoftcom
es-esdocumentation[13] D Ongaro y J Ousterhout In Search of an Understandable Consensus
Algorithm Inf teacutec Stanford University url httpsraftgithubioraftpdf
[14] Fei Teng laquoRessource allocation and schelduling models for cloud compu-tingraquo Tesis de mtriacutea Ecole Centrale Paris 2011
[15] A Williams y col Automation and Orchestration with Docker and Contai-ners A Comprehensive Overview of the Docker and Container Ecosystem3 The New Stack 2016
48
- Resumen
- Summary
- Iacutendice de figuras
- Introduccioacuten y objetivos
-
- Contexto
- Objetivos
- Estructura del documento
-
- Cloud Computing
- Nuevas cargas de trabajo
- Gestioacuten de recursos Planificadores
-
- Sistemas distribuidos
-
- Clasificacioacuten
-
- Herramientas
-
- DCOS
-
- Apache Mesos
- Ejemplos de uso
-
- Nomad
-
- Protocolo de consenso Raft
- Protocolo gossip SWIM
- Planificacioacuten
-
- Casos de uso y despliegue
-
- Aplicacioacuten Web
-
- DCOS
- Nomad
-
- Servicio de integracioacuten continua
-
- DevOps
- Integracioacuten Continua
- Jenkins con Nomad
- Jenkins con DCOS
-
- Escalando la infraestructura
-
- Disentildeo
- Implementacioacuten
-
- Resultados y conclusiones
-
- Comparacioacuten
- Conclusiones
- Objetivos conseguidos
- Liacuteneas de investigacioacuten
-
4 Gestioacuten de recursos Planificadores
Para sacar el maacuteximo provecho a las tecnologiacuteas anteriormente descritaslo ideal es desplegarlas en sistemas distribuidos sin embargo esto aumenta lacomplejidad del propio despliegue asiacute como la necesidad de software especiali-zado para ello Se necesitan algoritmos de planificacioacuten que permitan obtener elmaacuteximo rendimiento de los recursos por un lado y dar ciertas garantiacuteas de quetodas las tareas y procesos se van a ejecuta por otro
41 Sistemas distribuidos
En primer lugar se definen los sistemas distribuidos o clusters como unconjunto de ordenadores conectados entre siacute cuyo objetivo es trabajar como unauacutenica instancia de gran capacidad5
Su clasificacioacuten variacutea de acuerdo a cada autor pero en general se puedendividir seguacuten su objetivo en alto rendimiento aquellos cuyo objetivos es proveerde gran capacidad de coacutemputo gracias al conjunto de los nodos y alta disponi-bilidad con los cuales se busca la fiabilidad del sistema mediante redundanciayo balanceo de carga
El intereacutes de este proyecto recae en los uacuteltimos ya que el objetivo es porun lado ofrecer al desarrollador un entorno donde desplegar sus aplicaciones deforma distribuida y por otro maximizar el rendimiento de los recursos
De forma general las caracteriacutesticas que se buscan son las siguientes
Elasticidad Adaptacioacuten a cargas dinaacutemicas de trabajo aumentando (o dis-minuyendo) recursos de manera automaacutetica de tal forma que la utilizacioacutensea lo maacutes cercana a la demanda
Disponibilidad Capacidad de un sistema para mantener el servicio fun-cional
Tolerancia a fallos Recuperacioacuten del servicio ante el fallo de un compo-nente
Balanceo de carga Compartir las tareas entre las diferentes maacutequinasredundadas evitando asiacute puntos de uacutenico fallo
5httpsenwikipediaorgwikiComputer_cluster
8
Los programas que se implementan en entornos distribuidos se caracterizanpor ejecutarse de forma concurrente en equipos independientes estar conectadospor una red que introduce fallos aleatorios y no compartir memoria ni reloj Estoimplica entre otras cosas que
Los nodos soacutelo tienen un acceso raacutepido a su memoria local por lo quecualquier informacioacuten relativa al estado global puede ser potencialmenteerroacutenea
Las maacutequinas pueden sufrir caiacutedas de forma aleatoria
El intercambio de informacioacuten puede fallar ya sea por error en transmisioacuteno por caiacuteda de los nodos
Estas dificultades se ponen de manifiesto en el teorema de CAP en cienciasde la computacioacuten el teorema de CAP que lanzado inicialmente como conjetu-ra en el antildeo 2000 por Eric Brewer (motivo por el cual al teorema se le conoceformalmente como teorema de Brewer) y posteriormente demostrado en el antildeo20026 establece que es imposible para un sistema de coacutemputo distribuido ga-rantizar simultaacuteneamente dos de las tres propiedades siguientes
Consistencia (Consistency) es decir que todos los nodos vean la mismainformacioacuten al mismo tiempo Se busca que un cambio en el sistema soacutelose ejecute satisfactoriamente si y soacutelo si se efectuacutea a todos las maacutequinasde tal forma que los datos entre ellos nunca difieren y la respuesta a unapeticioacuten sea la misma independientemente del nodo que la atienda
Disponibilidad (Availability) esto es la garantiacutea de que toda peticioacuten debeobtener una respuesta (servicio funcional) aunque exista inconsistenciaentre nodos
Tolerancia al particionado (Partition Tolerance) es decir que el sistemasiga funcionado a pesar de un fallo en la comunicacioacuten entre los equipos
Por todo lo expresado anteriormente conseguir un sistema distribuido capazde ofrecer procesamiento de forma transparente implica una arquitectura TIcompleja Se requieren de subsistemas y herramientas que permitan la cohesioacutenentre todos los nodos
Gestor de los recursos de las diferentes maacutequinas
Monitorizacioacuten tanto de los servicios activos como de la funcionalidad delsistema ademaacutes de poliacuteticas para recuperacioacuten de fallo
Protocolos de consenso que permitan a los nodos ser consistentes con elestado global del cluster
6urlhttpsgroupscsailmitedutdspapersGilbertBrewer2pdf
9
Herramientas de descubrimiento de servicios que permita la comunicacioacutenentre tareas distribuidas
Planificadores Encargados de distribuir las tareas y procesos en las dife-rentes maacutequinas asignaacutendole parte de su capacidad
Los planificadores del ingleacutes cluster schedulers son un componente funda-mental por lo que vamos a entrar un poco maacutes en detalle en ellos
Planificadores (Cluster Schedulers)
Es el software encargado de monitorizar los recursos usados por cada maacute-quina perteneciente a un cluster y distribuir la carga de trabajo entre ellas deacuerdo a un poliacutetica o reglas
Este tipo de herramientas comparten cierta terminologiacutea que es relevantedefinir
Tarea Unidad de trabajo computacional comprendida por una secuenciade instrucciones datos de entrada y recursos asociados Por ejemplo laejecucioacuten de un comando o el arranque de una base de datos
Nodo Cualquier maacutequina integrante de un cluster En una arquitecturamaestro-esclavo se definen dos roles
bull Cliente Agente Esclavo Aquellos ordenadores que se encargan deejecutar las tareas
bull Maestro Servidor Su objetivo es mantener el estado del cluster ygestionar sus recursos
411 Clasificacioacuten
A lo largo de los uacuteltimos antildeos se han desarrollado diferentes tipos de plani-ficadores[2]
Monoliacutetico
Un solo planificador que se encarga de distribuir todas las tareas entran-tes La mayoriacutea de los planificadores en computacioacuten de alto rendimiento asiacutecomo Borg desarrollado por Google son de este tipo En la figura 3 se pue-de observar de forma graacutefica el procedimiento siendo las cajas grises maacutequinaspertenecientes al cluster y los ciacuterculos las tareas a asignar
10
Figura 3 Planificador monoliacuteticoFuente httpswwwclcamacuk
Planificacioacuten de dos niveles
La mayoriacutea de los clusters ejecutan aplicaciones con distintas necesidadesdesde procesos casi instantaacuteneos hasta servicios persistenteslo que implica dis-tintas necesidades de recursos
Por ello la planificacioacuten a dos niveles distingue dos funciones la gestioacutende recursos (gestor) y la disposicioacuten de las tareas (planificador) Cada serviciotiene su propio planificador de tal manera que el gestor les ldquoofertardquo recursosde acuerdo a una poliacutetica y los planificadores se encargan de escoger la maacutesadecuada Esto permite que el proceso de distribucioacuten sea maacutes acorde con lasnecesidades de los diferentes servicios Apache Mesos que detallaremos maacutesadelante sigue este esquema
Como desventaja cabriacutea sentildealar que esta programacioacuten implica que los pla-nificadores pierden la vista general de la infraestructura y las tareas soacutelo puedenejecutarse con los recursos que les son ofrecidos lo que dificulta la implementa-cioacuten de prioridades de ejecucioacuten de tareas entre otras
Figura 4 Planificador de dos niveles
11
Planificacioacuten de estado compartido
Muacuteltiples reacuteplicas del estado del cluster se actualizan independientementepara cada planificador como se observa en la figura 5 cuando sucede un cambiode forma local el planificador se encarga de informar al resto
Ejemplo de este tipo son Omega la evolucioacuten de Borg por parte de GoogleMicrosoft Apollo y Nomad que usaremos para los casos de uso
De entre las desventajas se puede destacar el hecho de que en general losnodos trabajan con informacioacuten desactualizada lo que conlleva una degradacioacutendel rendimiento en situaciones de alta contienda
Figura 5 Planificador de estado compartido
Planificacioacuten distribuida
En este caso no existe coordinacioacuten entre los distintos planificadores Cadauno de ellos funciona con su propia vista del cluster Las tareas pueden serorganizadas por cualquiera de ellos y desplegadas en cualquier parte del clusteren base a la aleatoriedad y multiplexacioacuten estadiacutestica de los flujos de trabajosin ninguacuten control central
Figura 6 Planificador distribuido
12
5 Herramientas
En la industria comienzan a aparecer soluciones software de coacutedigo abiertoque aglutinan los servicios necesarios para gestionar la infraestructura TI de ma-nera maacutes eficaz El objetivo es doble se busca facilitar la gestioacuten de los recursosde computacioacuten para organizaciones con instalaciones propias mediante su usocon un enfoque cloud esto es desplegar aplicaciones a traveacutes de un conjuntode ordenadores de forma transparente y sin tener en cuenta la infraestructurasubyacente o aprovechar el maacuteximo rendimiento de la infraestructura de losproveedores cloud puacuteblicos de forma que se tiene el maacuteximo control sobre eacutestapero no se depende de las soluciones propietarias permitiendo asiacute despliegueshiacutebridos
Entre estas herramientas se pueden destacar
OpenStack Proyecto desarrollado por la fundacioacuten del mismo nombre paraproporcionar servicios de infraestructuras (IaaS) basado en componentesque se comunican a traveacutes de APIs El componente Magnum incluye mo-tores de orquestacioacuten de contenedores
Kubernetes Sistema de orquestacioacuten de contenedores Docker creado por Goo-gle
CoreOs Sistema operativo basado en Linux disentildeado para despliegues distri-buidos sobre contenedores incluyendo mecanismos de descubrimiento deservicio y comparticioacuten de configuracioacuten
Docker Swarm Herramienta nativa de orquestacioacuten de contenedores Docker
YARN Entorno de gestioacuten de recursos y aplicaciones distribuidas de Hadoopuna libreriacutea software de procesamiento de grandes conjuntos de datos
Como podemos observar existe un gran rango de opciones para gestionar lainfraestructura desde un bajo nivel como puede ser OpenStack hasta Kuberne-tes o Docker Swarm que ofrecen exclusivamente orquestacioacuten de contenedores
En este trabajo se ha optado por Mesosphere DCOS y HashiCorp Nomadque se encuentran en el teacutermino medio su objetivo es proporcionar serviciosde plataforma que permitan la coexistencia dediferentes cargas de trabajo en elcluster
13
51 DCOS
DCOS es un proyecto de coacutedigo abierto7 creado y desarrollado por la empre-sa Mesosphere Se describe como un sistema operativo distribuido que abstraelos recursos de un cluster (capacidad de procesamiento memoria) permite lagestioacuten de muacuteltiples ordenadores de forma transparente y simplifica la instala-cioacuten de aplicaciones distribuidas
Su arquitectura se puede comparar a la de Linux en teacuterminos de nuacutecleo(kernel) y espacio de usuario El primero consta de recursos protegidos a losque no puede acceder el usuario e involucra operaciones de bajo nivel comoasignacioacuten de recursos o aislamiento de procesos En el espacio de usuario seejecutan las aplicaciones y servicios de maacutes alto nivel
Siguiendo con este siacutemil el nuacutecleo de DCOS estaacute basado en Apache Mesosque se explicaraacute en un apartado posterior y el espacio de usuario que estaacute com-prendido por los componentes del sistema esto es las diferentes herramientasque en conjunto conforman DCOS y los servicios encargados de planificar yejecutar las aplicaciones y tareas del usuario
Figura 7 Arquitectura DCOSFuente httpsdcosio
De entre los componentes que conforman DCOS destacan
Admin Router Balanceador de carga central basado en NGINX que dis-pone un proxy entre todos los servicios en el puerto 80 permitiendo sugestioacuten mediante la interfaz graacutefica Ademaacutes se encarga de la autenticacioacutenpara acceder al panel de administracioacuten
Cosmos Gestor de paquetes de las aplicaciones
Diagnostics Se ejecuta en todos los nodos y se encarga de monitorizar elestado de los daemons que sustentan DCOS
7Desde abril de 2016 httpsmesospherecomblog20160419open-source-dcos
14
Exhibitor Gestiona y automatiza el despliegue de ZooKeper la herra-mienta que provee de configuracioacuten centralizada y registro de nombres
Marathon Equivale al proceso init de los sistemas tipo Unix esto es elprimer proceso en ejecucioacuten tras la carga del kernel y que genera los demaacutesprocesos Se encarga de arrancar y monitorizar las aplicaciones y servicios
Mesos-DNS Servicio de DNS interno que define el dominio mesos pa-ra nodos y tareas en el cluster es decir permite resolver nombres conindependencia de la direccioacuten fiacutesica
Minuteman Balanceador de carga integrado a nivel TCPUDP disponiblepara las propias aplicaciones
Por otra parte se definen como servicios a las diferentes aplicaciones dis-tribuidas que DCOS permite instalar en el cluster y que pueden haber sidodesarrollados por la misma empresa Mesosphere o por terceros por ejemploApache Spark Jenkins o Apache Hadoop En la figura 8 se muestra un diagramade los servicios disponibles incluyendo algunos de las aplicaciones distribuidasque soporta DCOS
Figura 8 Servicios DCOSFuente httpsdcosio
511 Apache Mesos
El nuacutecleo de DCOS estaacute basado en Apache Mesos un proyecto de coacutedigoabierto creado por la Universidad de California Berkeley y desarrollado actual-mente por la fundacioacuten Apache Se trata de un administrador de clusters queabstrae los recursos y los dispone para diferentes aplicaciones y entornos de tra-bajo distribuidos (frameworks) mediante una interfaz comuacuten En el momento deredaccioacuten de este proyecto Apache Mesos soportaba una variedad de entornosque abarcaba desde Big Data (Apache Spark Hadoop) hasta bases de datos(Cassandra Hypertable)
15
Arquitectura
Mesos se basa en la asignacioacuten de dos roles diferentes a los nodos
Maestros (Masters) Se encargan de la gestioacuten y reparticioacuten de los recursospara los diferentes entornos de trabajo mediante ldquoofertas de recursosrdquo deacuerdo a los disponibles y a la poliacutetica de asignacioacuten (planificacioacuten en dosniveles)
Esclavos (Slaves) Ordenadores donde se ejecutaraacuten las aplicaciones y cu-yos recursos son ofertados por los maestros
En el caso de fallo del maestro las tareas pueden seguir ejecutaacutendose perono se podraacute asignar nuevos recursos ni tareas por ello pueden existir varios enel cluster para configuraciones de alta disponibilidad pero soacutelo uno orquesta alos esclavos
Para la eleccioacuten del master liacuteder Mesos usa Apache ZooKeeper un proyectode software desarrollado por la misma fundacioacuten cuyo objetivo es proveer deun servicio de configuracioacuten centralizado y registro de nombres8
Por otra parte los entornos de trabajo son los programas que deciden final-mente queacute recursos se van a usar y se encargan de que los esclavos ejecuten lastareas Eacutestos se ejecutan sobre Mesos y constan de dos componentes
Planificador (Scheduler) Optimiza y decide los recursos a utilizar de losofertados informando a los Masters
Procesador (Executor) Ejecuta las aplicaciones o servicios en los esclavos
El objetivo final es conseguir una interfaz liviana tolerante a fallos paracualquier tipo de entorno de trabajo de tal manera que en los esclavos del clusterpuedan ejecutarse simultaacuteneamente tareas con necesidades y duracioacuten diferentesPara ello se basa en dos conceptos asignacioacuten y aislamiento de recursos
Asignacioacuten de recursos
En el cluster pueden coexistir entornos de trabajo con tareas de larga dura-cioacuten y con gran consumo de recursos con tareas cortas que los ocupan y liberancon rapidez El maestro integra un moacutedulo de asignacioacuten de recursos (allocationmodule) que se encarga del algoritmo de distribucioacuten
En el momento de escribir este proyecto estaban desarrollados dos moacutedulosuno mediante el cual el usuario puede asignar prioridades y otro que implementa
8httpszookeeperapacheorg
16
el algoritmo Dominant Resource Fairness9 a grandes rasgos se determina entodos los esclavos la tarea en ejecucioacuten que necesita maacutes recursos y se calcula laproporcioacuten del recurso de mayor peso con respecto al total por ejemplo si unatarea ocupa 2 GB de memoria con respecto a 10 GB totales que tiene el clusterse le asigna un dominant share del 20 la tarea se asignaraacute al nodo con menordominant share
Aislamiento de recursos
Para conseguir que tareas de diferentes entornos de trabajo y con distin-ta naturaleza se ejecuten simultaacuteneamente en un mismo nodo Mesos usa loscontenedores Linux (descritos en la seccioacuten 3)
Funcionamiento
La figura 9 muestra el esquema de la arquitectura de Apache Mesos conalta disponibilidad (tres maestros) y con dos entornos de trabajo ejecutaacutendo-se Hadoop que permite el almacenamiento y procesamiento de gran cantidadde datos para proyectos de big data y un sistema que implementa la interfazsistema de paso de mensajes MPI
Como se puede observar el sistema ZooKeeper elige a un solo maestro comoliacuteder y eacuteste orquesta el cluster comunicando los esclavos con los planificadoresde los diferentes entornos de trabajo Tambieacuten se puede observar como las tareasde los distintos entornos estaacuten distribuidas entre los tres esclavos disponibles
Figura 9 Arquitectura de Apache MesosFuente httpsmesosapacheorg
El proceso de asignacioacuten se realiza como sigue en primer lugar un usuariosolicita la ejecucioacuten de una tarea mediante la interfaz de cada entorno de traba-jo (interfaz graacutefica API HTTP ) De forma paralela un esclavo informa almaestro de los recursos que tiene libres En consecuencia eacuteste se lo notifica almoacutedulo de asignacioacuten que en funcioacuten de su configuracioacuten decide cuaacutento ofertar
9httpspeopleeecsberkeleyedu~aligpapersdrfpdf
17
y a queacute entorno de trabajo y enviacutea la oferta a los planificadores Eacutestos respondenal maestro con queacute recursos ha decidido usar para cada tarea Finalmente lastareas son enviadas al esclavo seleccionado el cual asigna los recursos indicadosal procesador (executor) quien finalmente las ejecuta
Cabriacutea pensar que esta metodologiacutea puede conducir a situaciones en lasque un entorno podriacutea quedarse con tareas sin ejecutarse a la espera de unaoferta satisfactoria para ello Mesos implementa un sistema de filtros medianteel cual los entornos especifican los requisitos miacutenimos que debe cumplir unaoferta por ejemplo se puede especificar en queacute nodos debe desplegarse la tareaEste sistema estaacute disentildeado asiacute con el objetivo de mantener lo maacutes transparenteposible esta herramientas de forma que acepte entornos de trabajo de distintasnaturalezas
512 Ejemplos de uso
Grandes empresas estaacuten usando Apache Mesos con eficacia de acuerdo a susnecesidades e infraestructuras Caben destacar
Ebay En el modelo de implementacioacuten continua en esta empresa10 cadadesarrollador cuenta con su propia instancia que se ejecuta en una maacutequinavirtual dedicada lo que ha conllevado un uso de los recursos poco eficiente Enuna prueba de concepto consiguieron realizar una herramienta de integracioacutencontinua distribuida basada en un cluster con Apache mesos y con el entornoMarathon y Jenkins
Apple Anuncioacute que el motor de su famosa herramienta de asistencia per-sonal para iPhones Siri estaacute desplegada sobre Apache Mesos11 Para ello handesarrollado su propio entorno para facilitar a los ingenieros a desplegar los ser-vicios que la herramienta necesita para resolver las peticiones de los usuarios
Twitter Desarrolloacute su propio entorno denominado Aurora y actualmentegestionan sus recursos y miden el coste de las tareas que los empleados usancon el objetivo de que sean conscientes del gasto que puede suponer un usoinadecuado de la infraestructura12
10httpwwwebaytechblogcom20140404delivering-ebays-ci-solution-with-apache-mesos-part-i11httpwwwbusinessinsidercomapple-siri-uses-apache-mesos-2015-812httpswwwlinuxcomNEWS4-UNIQUE-WAYS-UBER-TWITTER-PAYPAL-AND-HUBSPOT-USE-APACHE-MESOS
18
52 Nomad
Herramienta de coacutedigo abierto de gestioacuten de clusters creada y desarrolladapor Hashicorp13 que permite el despliegue de aplicaciones y procesos de formadistribuida
Las principales diferencias con Apache Mesos a grandes rasgos son
Arquitectura maacutes ligera Nomad soacutelo requiere de un fichero para funcionarejecutaacutendolo con las correspondientes configuraciones en todos los nodosrealiza las funciones de gestioacuten del cluster eleccioacuten de liacuteder planificacioacutende recursos y ejecucioacuten de las tareas
Centro de datos y regiones muacuteltiples Su arquitectura estaacute orientada afacilitar la gestioacuten de diferentes centros de datos geograacuteficamente distri-buidos
Entorno de ejecucioacuten Las tareas se definen y son interpretadas mediantecontroladores integrados en Nomad que se valen de los recursos y herra-mientas de los nodos clientes para ejecutarlas Esta integracioacuten dificultael desarrollo de controladores por parte de terceros a diferencia de Mesosque delega dicha responsabilidad en los entornos de trabajo externos alproyecto
Usa un planificador de estado compartido con respecto a la planificacioacutenen dos niveles de Mesos
Antes de entrar en maacutes detalle en la arquitectura es importante definir lossiguientes teacuterminos
Controlador (Driver) Software que se encarga de interpretar las definicionesde las tareas y ejecutarlas semejante a los procesadores de los entornosde trabajo de Mesos A la hora de redactar este proyecto Nomad contabacon controladores para contenedores Docker virtualizacioacuten de maacutequinasmediante el emulador QEMU aplicaciones java y archivos binarios
Grupo de trabajo (Task Group) Conjunto de tareas que se ejecutan en elmismo nodo cliente
Trabajo (Job) Conjunto loacutegico de tareas y grupos de trabajo que se despliegana la vez
Asignacioacuten (Allocation) Relacioacuten entre un grupo de trabajo y el cliente don-de se ejecuta
Evaluacioacuten (Evaluation) Proceso mediante el cual Nomad planifica y ges-tiona el registro o actualizaciones de los trabajos
13httpswwwhashicorpcom
19
Nomad sigue una arquitectura maestro-esclavo similar a la de Apache Mesosmuacuteltiples servidores acuerdan entre siacute un liacuteder que gestiona la planificacioacuten detareas en los clientes que soacutelo conocen sus asignaciones y las ejecutan
Todos los servidores participan paralelamente en tareas de planificacioacuten derecursos y asignacioacuten de tareas y ademaacutes entre ellos eligen un liacuteder que seencarga de la coordinacioacuten de la suscripcioacuten de los clientes al cluster y de lagestioacuten de las peticiones
Los clientes estaacuten configurados para comunicarse con el servidor usando lla-madas a procedimiento remoto (RPC por sus siglas en ingleacutes) que permite unordenador ejecutar coacutedigo en otra maacutequina Mediante esta tecnologiacutea los nodosclientes avisan de su estado e informa de sus asignaciones recursos y controla-dores disponibles
Existe la posibilidad de gestionar varios centros de datos agrupados en regio-nes eacutestas son independientes pero permite definir tareas o comprobar el estadode todas ellas desde cualquier punto A continuacioacuten se muestra una figura dela arquitectura a alto nivel de esta configuracioacuten
Figura 10 Arquitectura multi-regioacuten en NomadFuente httpswwwnomadprojectio
La herramienta se sustenta sobre tres protocolos fundamentales un protocolode consenso entre los servidores para compartir informacioacuten sobre su estado yel liacuteder un protocolo Gossip para la gestioacuten entre regiones y el planificador detareas
521 Protocolo de consenso Raft
El objetivo es obtener consistencia en un conjunto de nodos que comparteninformacioacuten es decir si un cliente realiza un cambio que todos los nodos veanla misma informacioacuten a la vez y ademaacutes sea tolerante a fallos Para ello se basaen el algoritmo Raft[13] que se detalla brevemente a continuacioacuten
20
Los nodos participantes en el algoritmo pueden estar en tres estados
Liacuteder (Leader) Todos los cambios que realicen en el cluster pasan por eacutel pri-mero
Seguidor (Follower) Nodo pasivo cuya responsabilidad es responder a laspeticiones del nodo liacuteder
Candidato (Candidate) Maacutequina que no ha encontrado liacuteder y solicita sueleccioacuten
Supongamos que tenemos cinco equipos que acaban de arrancar el protocoloEn la figura 11 se observan los nodos y sus respectivos registros a la derecha
Figura 11 Equipos sin consenso ejecutando el protocolo RAFTFuente httpsgithubcomongardieraftscope
Al comenzar todos los nodos son seguidores esperando recibir comunicacioacutende un nodo que actuacutee como liacuteder Cada nodo tiene un tiempo de espera aleatoriodespueacutes del cual si no es informado por un liacuteder pasa a estado candidato y pideel ldquovotordquo al resto de los participantes El algoritmo divide el tiempo en plazos uncandidato pasa a liacuteder si recibe la mayoriacutea de los votos en un plazo determinadoSe define mayoriacutea o cuoacuterum (quorum) comolceil
N2rceil
+ 1 (1)
donde N representa el nuacutemero de nodos
Para el ejemplo propuesto de 5 equipos se requieren de 3 votos Soacutelo losnodos que se encuentren en estado seguidor pueden votar una uacutenica vez a laprimera solicitud que reciba dentro de un plazo
Supoacutengase que el nodo denotado con S1 ha cumplido su tiempo de espera yrealiza la peticioacuten de voto (figura 12) A partir de este momento se pueden dartres casos
La maacutequina gana la eleccioacuten y pasa a ser liacuteder informando al resto
Otro servidor se establece como liacuteder en el mismo momento
Varios nodos pasan a ser candidatos por lo que ninguno consigue los votos
21
Figura 12 Un equipo pasa a estado candidato (RAFT)
Si un candidato recibe un aviso de un liacuteder en el mismo plazo el primeropasa a ser seguidor y se acaba la eleccioacuten de liacuteder
Por otro lado si un equipo candidato no recibe los votos en el plazo y agotasu tiempo de espera avanza al siguiente plazo y repite el proceso de votacioacutenLa tercera posibilidad puede conllevar a un estado indefinido ya que varioscandidatos pueden agotar su tiempo de espera al mismo tiempo y repartir losvotos Para solventarlo el algoritmo establece tiempos de espera aleatorios paralos candidatos
Siguiendo con el ejemplo propuesto el servidor S1 pasa a ser el liacuteder Cadacierto tiempo eacuteste debe realizar avisos a los nodos seguidores para no agotar sutiempo de espera
En este momento el cluster de servidores estaacute en ldquoconsensordquo y la informacioacutenen todos los nodos estaacute actualizada Un cambio en la informacioacuten inicia unproceso de replicacioacuten el liacuteder registra el cambio lo pasa al resto de nodos yuna vez eacutestos responden el cambio se hace efectivo
Supoacutengase que se realiza un cambio en los datos en la figura 13 en la partederecha se observa el cambio en el registro del servidor S1 que informa a losnodos seguidores En consecuencia los nodos registran el cambio y responden aS1
Figura 13 Cambio en un registro (RAFT)
Una vez el cuoacuterum (en el ejemplo tres equipos) informa al liacuteder de que
22
ha registrado el cambio el liacuteder lo hace efectivo en su sistema y notifica a losnodos que hacen lo mismo En la figura 14 el enviacuteo todaviacutea no ha llegado ala maacutequina S3 y se observa que no ha hecho efectivo el cambio (en el registroaparece punteado)
Figura 14 Aprobacioacuten del resto de equipos (RAFT)
Este protocolo funcionaraacute correctamente mientras exista un nuacutemero de nodosen funcionamiento igual o superior al cuoacuterum en el ejemplo propuesto elcuoacuterum es tres por lo que el sistema puede tolerar la caiacuteda de dos de los equipos
522 Protocolo gossip SWIM
Nomad permite la gestioacuten simultaacutenea de varios centros de datos reparti-dos en regiones geograacuteficamente separadas requiriendo de un protocolo ligeroque mantenga a los miembros actualizados sobre los participantes del conjun-to Para ello usa una ligera variante del protocolo SWIM[3] (Scalable Weakly-consistent Infection-style Process Group Membership Protocol) desarrollada porHashiCorp Estaacute clasificado como un protocolo de tipo gossip que debe su nom-bre a la semejanza con coacutemo se distribuye un rumor en una red social
SWIM se sustenta en dos caracteriacutesticas fundamentales la deteccioacuten de fallosy la distribucioacuten de la informacioacuten relativa a los miembros A continuacioacuten sedetalla el funcionamiento de ambos componentes
Deteccioacuten de fallos
Este componente tiene dos paraacutemetros el periodo de protocolo T y el nuacutemerode subgrupos de deteccioacuten de fallos k en los que se dividen los nodos Paracomprobar la comunicacioacuten entre dos maacutequinas usa la utilidad ping basadaen el protocolo ICMP La deteccioacuten de caiacuteda de un servidor sigue el siguientealgoritmo
Durante el periodo T cada miembro Mi de un subgrupo elige otro al azar Mjdel mismo subgrupo y le enviacutea un mensaje ping para comprobar su estado Enel caso de que se cumpla un tiempo de espera determinado por una estimacioacuten
23
del tiempo de ida y vuelta (RTT por sus siglas en ingleacutes) de la red y no hayarespuesta Mi le vuelve a enviar un mensaje ping indirectamente a traveacutes deun nuacutemero k de miembros escogidos aleatoriamente De no recibir ninguna res-puesta Mi establece que Mj ha sufrido un fallo y lo etiqueta como ldquosospechosordquoinformando al componente de distribucioacuten
Figura 15 Diagrama de tiempo del protocolo SWIMFuente httpswwwcscornelledu
Componente de distribucioacuten
Se encarga de informar de cualquier cambio en los miembros a todo el con-junto Los eventos de nodo caiacutedo y la unioacuten o disociacioacuten de un miembro setransmiten a todos los servidores para que actualicen sus lista Para distribuirla informacioacuten a todos los nodos se podriacutea usar el meacutetodo de multicast perosuele estar deshabilitado Por ello se utiliza una teacutecnica de transmisioacuten denomi-nada Piggybacking mediante la cual se adjunta a los propios mensajes PINGy ACK del algoritmo la informacioacuten a distribuir reduciendo asiacute la congestioacutenen la red
523 Planificacioacuten
Proceso encargado de distribuir las tareas entre los nodos clientes de acuerdoa su estado
El planificador de Nomad estaacute basado en las publicaciones de Google sobresus herramientas de gestioacuten de clusters Borg y Omega14 y entiende los trabajosdescritos por el usuario como un estado deseado es decir su despliegue en unamaacutequina cliente de forma correcta y los clientes como el estado actual esto eslo que se encuentra en ejecucioacuten El registro actualizacioacuten o cancelacioacuten de un
14httpresearchgooglecompubspub43438html
24
trabajo asiacute como el fallo de un nodo cliente implican un cambio de estado atramitar por el sistema lo que se define como evaluacioacuten (evaluation) Esto uacutelti-mo supone comparar el estado actual (clientes) con el estado deseado (conjuntode trabajos registrados) y enviarlos a los planificadores correspondientes que seencargaraacuten de asignar las tareas a los nodos clientes
Figura 16 Procedimiento de asignacioacuten en NomadFuente httpswwwnomadprojectio
En la figura 16 se observa el flujo de trabajo en el que las distintas evalua-ciones se encolan en el evaluation broker que se ejecuta en el servidor liacuteder ygestiona las evaluaciones pendientes asignaacutendoles prioridades
A continuacioacuten los nodos servidores ejecutan los scheduling workers queprocesan las evaluaciones llamando a los distintos planificadores que generanun plan de asignacioacuten esto es un conjunto de relaciones entre las tareas y losnodos clientes donde se ejecutaraacuten Este proceso se divide en dos fases primerose descartan aquellos clientes que no cumplan los requisitos y posteriormentese asigna una calificacioacuten al resto Se selecciona el nodo con mayor puntuacioacuteny se encola el plan en el gestor que se ejecuta en el servidor liacuteder Existen tresplanificadores de acuerdo al tipo de trabajo
Service Incluye aquellos trabajos que estaacuten destinados a ejecutarse en un pe-riacuteodo largo de tiempo Para realizar las asignaciones el planificador evaluacuteala mayor parte de los nodos y usa una versioacuten del algoritmo Best fit in-fluenciada por el trabajo de Google en su herramienta Borg Se trata deun algoritmo de planificacioacuten que sacrifica tiempo a cambio de maximizarel rendimiento de los clientes asignando la tarea a la maacutequina que tengala mayor carga de trabajo con el objetivo de reducir equipos en funciona-
25
miento
Batch Tareas que incluyen listas de comandos en general de menor duracioacuteny que no requieren interaccioacuten con el usuario Se vale del algoritmo deSparrow desarrollado por la universidad de Berkeley15 para limitar losnodos clientes a evaluar
System Trabajos destinados a ejecutarse en todos los nodos incluso los que seunen al cluster posteriormente
Core Mantenimiento interno de Nomad
Una vez se ha realizado el proceso de planificacioacuten el nodo liacuteder lo registra enla cola de planes (plan queue) que se encarga de asignarles prioridad y manejarcondiciones de carrera es decir que no accedan a los recursos de los clientes sincontrol y evitar que eacutestos superen su capacidad
La maacutequina liacuteder del conjunto puede de este modo aceptar una asignacioacuteny ser ejecutada por los clientes o por el contrario rechazaacutersela al planificadorlo que implicariacutea realizar un plan parcial o totalmente nuevo
Finalmente el estado de las evaluaciones se actualizan y los clientes soninformados de las asignaciones ejecutaacutendose las tareas
15httppeopleeecsberkeleyedu~keopublicationssosp13-final17pdf
26
6 Casos de uso y despliegue
Con el objetivo de mostrar las posibles utilidades que este tipo de sistemaspueden tener en las infraestructuras TI actuales se han desplegado las dos he-rramientas en la nube Microsoft Azure usando su servicio cloud de instancias demaacutequinas virtuales Linux para simular un conjunto de ordenadores conectadosentre siacute por una red LAN Sobre ellas se ha implementado dos casos de usouna aplicacioacuten web con una arquitectura con cierta orientacioacuten a microserviciosy un sistema de integracioacuten continua
El coacutedigo y todos los ficheros de configuracioacuten se pueden encontrar en elrepositorio del proyecto en GitHub16
61 Aplicacioacuten Web
Se busca simular el proceso de adaptacioacuten de una solucioacuten web para su des-pliegue en un sistema distribuido con las herramientas anteriormente descritascon el objetivo de aumentar tanto su escalabilidad como disponibilidad medianteredundancia
Se ha partido de una aplicacioacuten ya existente17 un servicio de almacenamien-to y reproduccioacuten de canciones A grandes rasgos este servicio permite crearusuarios subir canciones con sus respectivas portadas tener playlists propias yescuchar las canciones a traveacutes de un navegador web
La solucioacuten estaacute dividida en 4 partes (figura 17)
Una vista web con la loacutegica
Un almacenamiento conectado en red (NAS por sus siglas en ingleacutes)
Una API REST para gestionar las peticiones al almacenamiento
Base de datos NoSQL basada en MongoDB
La nueva tendencia de los proyectos web es su implementacioacuten en contene-dores Docker ya que facilitan su portabilidad y ofrecen un procedimiento dedespliegue raacutepido sobre todo a la hora de desarrollar y realizar pruebas en en-tornos de produccioacuten simulados Por ello en este caso se va a hacer uso de los
16httpsgithubcomAntonioAlfrzCloud-Orchestrators17httpsgithubcomsonsoleslpCDPSfy
27
motores de orquestacioacuten de contenedores de ambas herramientas Marathon enDCOS y el controlador Docker en el caso de Nomad
Figura 17 Arquitectura aplicacioacuten web
A continuacioacuten vamos detallar el despliegue en ambas herramientas de es-ta solucioacuten y observar tanto queacute dificultades se encuentran como que ventajasofrecen El objetivo final es adaptar el proyecto modificaacutendolo lo menos posiblecon objeto de analizar la capacidad de estas herramientas para desplegar cual-quier aplicacioacuten sin que eso conlleve la modificacioacuten de la arquitectura de eacutestaes decir que no sea dependiente del entorno
611 DCOS
Se ha descrito DCOS como una herramienta que se despliega sobre un con-junto de ordenadores y que permite instalar gestionar el despliegue de sistemasdistribuidos
Microsoft Azure cuenta con una plantilla para desplegar en su servicio cloudun cluster de maacutequinas virtuales con DCOS ya instalado que cuenta con
Maacutequinas maestras (1 3 o 5 a seleccionar por el usuario) configuradascomo un conjunto de disponibilidad esto eso Azure da ciertas garantiacuteasde que al menos una maacutequina estaraacute en funcionamiento
Maacutequinas agentes Por motivos de seguridad se distinguen dos roles
bull Nodos privados solo accesibles desde la red interna y configuradoscomo un conjunto de escala un recurso de Azure para gestionar ydesplegar maacutequinas con configuraciones ideacutenticas para permitir unraacutepido escalado
bull Un equipo conectado accesible desde Internet a travntildees de un balan-ceador de carga puacuteblico y situado en una subred externa
28
Dos balanceadores de carga
bull La interfaz puacuteblica del cluster que se conecta con el cliente puacuteblicobull Acceso a los equipos maestros para el administrador que soacutelo permiteconexioacuten mediante SSH y credenciales
Almacenamiento para todas las maacutequinas
Configuraciones necesarias de red y seguridad
En la figura 18 se observa un diagrama de la infraestructura
Figura 18 Infraestructura en Azure
El primer obstaacuteculo es la persistencia de estado de la aplicacioacuten que seconsigue gracias a una base de datos no relacional basada en MongoDB asiacutecomo el almacenamiento de las canciones Para implementarla tenemos variasposibilidades
Montar un sistema externo de almacenamiento conectado en red en todoslos agentes donde se ejecuten las tareas de esta manera si una tarea pasade un nodo a otro por cualquier motivo puede tener acceso a los mismosficheros (opcioacuten del caso de uso original)
Implementar un sistema de ficheros distribuidos en los agentes
Usar los servicios de almacenamiento de las nubes puacuteblicas
Aprovechar el sistema de voluacutemenes persistentes de Apache Mesos Eacutestepermite reservar recursos de un agente de forma que al arrancar una tarease crea un volumen independiente del ciclo de vida de eacutesta con ello esosrecursos donde se ha almacenado la informacioacuten pueden volver a ofrecerseal mismo entorno de tal manera que otra tarea pueda acceder a ella
DCOS aprovecha este sistema de voluacutemenes persistentes y permite instalarbases de datos distribuidas como ArangoDB o Apache Cassandra sin embargoesto implicariacutea modificar todo el coacutedigo referente al modelo de la base de datos
29
Por motivos de eficiencia y latencia asiacute como de una mayor gobernabilidadde los datos la mejor opcioacuten es usar el recurso de voluacutemenes persistentes queofrece Apache Mesos ya que de esta manera se gestionariacutea la aplicacioacuten completamediante una uacutenica herramienta Sin embargo esto implica que la informacioacutense encuentra exclusivamente en el agente donde se haya ejecutado la tarea y porlo tanto se sigue requiriendo de software externo para distribuir la informacioacutenpara que se accesible para todos los agentes A la hora de realizar este proyectose encontraba en desarrollo Flocker una solucioacuten desarrollada por ClusterHQque permite compartir los voluacutemenes de Docker a traveacutes de un cluster quesi bien es compatible con el planificador de Mesos el proyecto se encontrabatodaviacutea en fases tempranas de desarrollo y los sistemas de almacenamiento quesoporta quedaban fuera del aacutembito de este trabajo
Por todo ello dado que las maacutequinas se han desplegado en la nube puacuteblicade Azure se decidioacute usar su servicio de almacenamiento de objetos para lascanciones y otra maacutequina para desplegar MongoDB y asiacute mantener el modelode datos original de la aplicacioacuten La diferencia del almacenamiento de obje-tos con respecto a nivel de fichero es que el primero no tiene jerarquiacutea paraorganizar los archivos eacutestos se guardan como objetos (con sus metadatos) enun mismo espacio soacutelo diferenciaacutendose por un identificador uacutenico esto implicaentre otras cosas que se puede acceder a un fichero dado uacutenicamente su IDindependientemente de la localizacioacuten fiacutesica de eacuteste facilitando pues la gestioacuteny el desarrollo
El coacutedigo del proyecto se ha modificado en los siguientes apartados
Las direcciones de la base de datos y los balanceadores de carga asiacute comosus puertos estaban originalmente fijos Se han configurado como variablesde entorno para facilitar el descubrimiento del servicio y hacer transpa-rente la aplicacioacuten al entorno de despliegue
La API REST se ha adaptado al almacenamiento en Azure en vez de enlocal
Estas modificaciones no suponen un cambio sustancial pero permiten separala persistencia de las tareas ejecutadas por DCOS lo que facilita en granmedida su ejecucioacuten al ser totalmente sin estado y ademaacutes implican tenerlos datos bajo un mayor control
Para la orquestacioacuten de contenedores se va a usar el entorno Marathondesarrollado tambieacuten por Mesosphere Eacuteste se puede usar a traveacutes de una interfazgraacutefica la interfaz de liacutenea de comandos (en lo que sigue CLI por sus siglas eningleacutes) de DCOS o con su API HTTP
Primero se han publicado la imaacutegenes de los contenedores que encapsulanla interfaz web y la api de la aplicacioacuten en el repositorio puacuteblico DockerHub
Los despliegues en este entorno se describen mediante ficheros JSON en losque se detalla entre otras opciones la imagen del contenedor los puertos a usar
30
los recursos que debe ocupar en un nodo o las instrucciones de monitorizacioacuten
Para el servicio de descubrimiento DCOS ofrece la posibilidad de asignardirecciones IP virtuales (VIP por sus siglas en ingleacutes) a tareas que se compartenen todos los nodos DCOS lleva integrado un balanceador de carga a nivel TCP(el componente denominado Minuteman) que balancea entre las direccionesvirtuales de las tareas y todas las instancias de eacutestas a lo largo del cluster Estoes necesario por dos motivos equilibrar la carga de los equipos con el fin deevitar un punto de uacutenico fallo mediante redundancia y evitar la contienda dedirecciones al ejecutar las tareas en puertos aleatorios
Este balanceador de carga estaacute basado en el trabajo de Michael Mitzenma-cher The Power of Two Choices in Randomized Load Balancing18 A grandesrasgos el algoritmo mantiene una media moacutevil exponencial de latencias paracada destino (backend) ademaacutes de las caiacutedas consecutivas Si un destino noresponde a una negociacioacuten en tres pasos (three way handshake) de forma con-secutiva en un periodo inferior a 5 ms se considera caiacutedo El algoritmo iterasobre los destinos disponibles en base a su histoacuterico de fallos y escoge dos deforma aleatoria de los cuales coge el de mejor meacutetrica
Las direcciones virtuales soacutelo se pueden resolver dentro del cluster porello para implementar la interfaz puacuteblica de la aplicacioacuten esto es el balancea-dor de carga de la interfaz web usaremos un paquete de DCOS denominadomarathon-lb un balanceador basado en HAProxy y adaptado por MesosphereEn este caso equilibra la carga de todas instancias de las tareas ejecutadas porel entorno Marathon por sus etiquetas y permite ademaacutes definir como puntode entrada muacuteltiples hosts virtuales definidos por sus nombres completos dedominio (FQDN por sus siglas en ingleacutes) en nuestro caso la interfaz puacuteblicadel balanceador de Azure para los agentes
Por motivos de seguridad todas las tareas se ejecutan en los agentes privadoses decir los que son exclusivamente accesibles desde la red interna Por su partemarathon-lb se ejecuta en el agente puacuteblico que cuenta con IP puacuteblica y lospuertos 80 (HTTP) y 8080 abiertos de forma que la aplicacioacuten sea accesibledesde Internet Esto es posible debido a que Apache Mesos permite reservarrecursos mediante roles asignados a nodos para un uso especiacutefico De esta formala arquitectura vista desde la aplicacioacuten quedariacutea como en la figura 19
18httpswwweecsharvardedu~michaelmpostscriptstpds2001pdf
31
Figura 19 Arquitectura de la aplicacioacuten web en DCOS
Ejecucioacuten
A la hora de desplegar la aplicacioacuten DCOS puede gestionarse medianteuna interfaz graacutefica o una interfaz de liacutenea de comandos La primera se accedea traveacutes de un navegador web en el puerto 80 (HTTP) y permite instalar losentornos disponibles observar el estado de los nodos y las tareas que se estaacutenejecutando y los ficheros de registros que eacutestas generan
La CLI permite el control desde un nodo o una maacutequina remota (suponiendoque los maestros tienen IP puacuteblica y el puerto 80 abierto) ya que DCOS tieneun sistema de autorizacioacuten que permite tener una interfaz puacuteblica con ciertasgarantiacuteas de seguridad
Por su parte cada entorno de trabajo puede ser controlado por la CLI peroademaacutes cuenta con sus propias interfaces Marathon expone una API HTTPen el puerto 8080 de la direccioacuten puacuteblica de los maestros del cluster asiacute comootra interfaz graacutefica Para desplegar un contenedor se podriacutea usar la CLI
$ dcos marathon app add lt f i l e j songt
O la API HTTP
$ cu r l minusX POST http lt ip_maestro gt8080v2apps minusd ltf i l e jsongt minusH Contentminustype app l i c a t i o n j son
32
612 Nomad
La arquitectura de Nomad es maacutes sencilla ya que solo requiere de un ficheroejecutable en todos los nodos para funcionar Si DCOS es la base de instala-cioacuten de entornos de terceros Nomad integra todas las funcionalidades baacutesicasesto es gestor de recursos planificador y ejecutor en los nodos cliente Estaherramienta cuenta con un menor tiempo de desarrollo y en el momento deescribir este documento cuenta exclusivamente con los siguientes controladoresen comparacioacuten con los entornos de DCOS
Motor Docker es decir funcioacuten de orquestacioacuten de contenedores
Ejecucioacuten de archivos binarios como comandos de Shell
Ejecucioacuten de aplicaciones Java
Virtualizacioacuten de maacutequinas mediante tecnologiacutea QEMU
Todos ellos necesitan que la tecnologiacutea subyacente esteacute instalada en las maacute-quinas clientes (Docker Java QEMU) Actualmente no permite el registro decontroladores por parte de terceros aunque estaacute planificado en un futuro ofreceruna interfaz para su desarrollo
Nomad no cuenta con el servicio de descubrimiento sin embargo puede inte-grarse con la herramienta Consul desarrollada por la misma empresa Por otrolado para el balanceo de carga usaremos un contenedor Docker con HAProxyuna herramienta de coacutedigo abierto que ofrece tanto servicios de proxy como debalanceador y cuyos ficheros de configuracioacuten completaremos con el proyectoConsul Template19
Consul
Consul sigue la misma arquitectura que Nomad es decir un nodo servidorque orquesta un conjunto de maacutequinas clientes y permite a los procesos que seejecutan en los equipos definirlos como servicios ofreciendo diversas caracteriacutes-ticas entorno a estos de los cuales vamos a usar dos
Descubrimiento de servicio Las maacutequinas clientes publican en el cataacutelogode servicios las tareas en ejecucioacuten y Consul les asigna nombres de dominioaccesibles por todos los miembros del cluster a traveacutes de la interfaz DNSincluida en esta herramientaConsul se integra con Nomad de forma que todas las tareas que se ejecu-ten en la segunda son automaacuteticamente publicados como servicios de laprimera de esta manera no hace falta conocer la direccioacuten de la maacutequinacliente donde se esteacute ejecutando el proceso ya que se puede acceder a eacutela traveacutes de su nombre de dominio de forma transparente Por ejemplo si
19[httpsgithubcomhashicorpconsul-template]
33
ejecutamos una tarea con ID web en el puerto 8080 se puede acceder aella en la direccioacuten webserviceconsul8080Para que las direcciones propias de Consul las resuelva su propio DNS y noel que esteacute asignado por defecto en la maacutequina usaremos la herramientadnsmasq20 que permite especificar la direccioacuten de un servidor DNS paraconsultas de direcciones especiacuteficas
Monitorizacioacuten Permite realizar comprobaciones del servicio y seguir su esta-do Aprovecharemos esta funcionalidad tanto para definir el propio procesode Nomad como servicio de Consul como las tareas desplegadas
HAProxy + Consul Template
HAProxy es una solucioacuten versaacutetil de coacutedigo abierto que ofrece solucionesde balanceo de carga y proxy Existen otras herramientas en el mercado comoNGINX o ldirectord sin embargo HAProxy suponiacutea una solucioacuten sencilla deconfigurar para mostrar el caso de uso
El uso de estas herramientas se debe a dos motivos para que no existacontienda con respecto a los puertos de los clientes usados por las tareas eacutestos sevan a asignar de forma dinaacutemica lo que en principio implicariacutea que la aplicacioacutendeberiacutea realizar consultas DNS de tipo SRV (que incluye puertos) a la interfazde Consul y balancear la carga entre tareas por redundancia y capacidad
Como la direccioacuten IP y puerto son variables cada vez que las tareas seactualicen o se reasignen es necesario volver a configurar HAProxy de formamanual Por ello HashiCorp ha desarrollado un programa denominado Con-sul Template que realiza peticiones sucesivas a la interfaz HTTP de Consul delas direcciones fiacutesicas de un servicio y reinicia automaacuteticamente el proceso deHAProxy Asiacute definiendo estas tareas como servicios Consul podremos tantomonitorizarlas como escalar las tareas dinaacutemicamente sin necesidad de cambiarel balanceador A partir del contenedor Docker oficial de HAProxy se ha desa-rrollado otro con la configuracioacuten baacutesica y con Consul Template para desplegarlocomo una tarea en Nomad
Despliegue
Se ha usado el mismo coacutedigo que en el apartado anterior con la persistenciaen el servicio de almacenamiento de Azure Desde la perspectiva del hardwarese implementaraacute la misma infraestructura que en el caso de DCOS (figura 18)estos es definiremos dos tipos de maacutequinas clientes un agente que se conectaraacutecon el balanceador de carga con nombre de dominio puacuteblico y donde se desple-garaacute el balanceador de carga de la vista web y agentes privados no accesiblesdesde fuera del cluster y donde se ejecutaraacuten el resto de tareas en la red inter-na La principal diferencia radica en las tareas que ejecutan HAproxy y ConsulTemplate que sustituye a las direcciones IP virtuales que ofrece DCOS
20httpwwwthekelleysorgukdnsmasqdochtml
34
Figura 20 Despliegue en Azure de Nomad+Consul
Cabe matizar que los balanceadores basados en HAProxy se implementanpor necesidad de la aplicacioacuten para el descubrimiento del servicio a diferenciade los de Azure que se implementan por motivos de seguridad y escalabilidaddel cluster en siacute
Configuracioacuten Nomad
Los ficheros de configuracioacuten de las maacutequinas maacutester y cliente son similaresy comparten la mayoriacutea de las opciones como por ejemplo el nombre del nodoo la interfaz de red donde escucha Nomad las peticiones Sus opciones son engeneral auto-explicativas sin embargo existen dos detalles que matizar
El proceso de Nomad escucha las peticiones tanto de los protocolos deconsenso como del usuario a traveacutes de una interfaz de red que se debeindicar en el fichero de configuracioacuten
En el caso de los clientes se deben indicar las direcciones de los servidoresdel cluster sin embargo se trata de un sistema dinaacutemico en el que losnodos pueden sufrir errores y cambiar de direccioacuten Por ello se ha definidoNomad como un servicio de Consul y asiacute poder definir la direccioacuten de losservidores como un nombre de dominio no por su direccioacuten fiacutesica que elservidor DNS de Consul se encargaraacute de resolver
Por defecto Nomad usa los siguientes puertos
API HTTP 4646 Peticiones HTTP y recepcioacuten de oacuterdenes mediante laliacutenea de comandos
RPC 4647 Protocolo de consenso entre los nodos del cluster
Serf 4648 Protocolo de gossip entre los servidores de los centros de datosgobernados por Nomad
35
Los dos uacuteltimos deben ser interfaces alcanzables por otros nodos sin embargo laAPI HTTP por motivos de seguridad deberiacutea ser local ya que en caso contrariocualquier persona con acceso a ella tiene el control sobre la herramienta Eacutestasolo deberiacutea estar accesible en un servidor o gestionarlo mediante una terminalSSH por ejemplo En este trabajo al ser una prueba de concepto se ha abiertoen todos los nodos
Trabajos de Nomad
Las tareas se detallan en ficheros con formato HashiCorp Configuration Lan-guage un derivado del formato JSON creado por la empresa que le da nombrecompatible con eacuteste y que permite comentarios
En estos ficheros se puede definir
La regioacuten y el centro de datos donde se ejecutaraacute (Nomad permite lagestioacuten de centros de datos geograacuteficamente distribuidos en regiones)
La poliacutetica de actualizacioacuten de la tarea
Grupo de tareas esto es que se ejecutaraacuten en el mismo nodo
El nuacutemero de grupos a ejecutarescalar asiacute como los liacutemite que debencumplir los nodos asignados
La poliacutetica de reinicio ante fallo o error
Tareas El controlador su configuracioacuten los paraacutemetros del servicio aso-ciado a registrar en Consul asiacute como los recursos que consume (puertosmemoria)
En nuestro caso usamos sobre todo el controlador Docker esto eso orques-tacioacuten de contenedores en los nodos clientes y tres de sus opciones
Imagen del contenedor Se han subido todas las imaacutegenes del proyecto a Doc-ker Hub donde por defecto se busca la imagen
Puertos Los puertos a usar por el contenedor que pueden ser estaacuteticos asigna-dos por el usuario o dinaacutemicos siendo Nomad el que se encarga de mapearun puerto libre del nodo cliente al expuesto por el contenedor
Servidores DNS Como usamos la interfaz DNS de Consul como descubri-miento de servicio se debe configurar el contenedor para que use cualquiernodo del cluster como servidor DNS
Configuracioacuten Consul
Al ser desarrolladas por la misma empresa los ficheros de configuracioacuten deConsul y Nomad comparten muchas opciones Consul tambieacuten acepta peticionesa traveacutes de una interfaz de red siendo los puertos usados por defecto
36
RPC 8300 8400 Maneja la peticiones del resto de nodos y usuarios
Serf 8301 8302 Protocolo gossip
HTTP API 8500
HTTPS API Desactivada por defecto
Interfaz DNS 8600
Se debe asignar a los protocolos internos del cluster esto es RPC y Serf unainterfaz alcanzable por los nodos y por el contrarioasignar a los dos uacuteltimos ala interfaz de loopback por motivos de seguridad
Cabe destacar que Consul tambieacuten cuenta con una interfaz graacutefica que per-mite ver el estado de los equipos y los servicios registrados y que se encuentra enel mismo puerto que la API HTTP en la direccioacuten httpIP_EQUIPO8500ui
Ejecucioacuten
Tanto Nomad como Consul requieren de la ejecucioacuten de un fichero en todoslos nodos integrantes del cluster Como prueba de concepto se ha decidido usardos servidores para ambos aunque cabe matizar que es un nuacutemero ineficienteya que la caiacuteda de uno de ellos supondriacutea la peacuterdida del cuoacuterum y por tantodel consenso del cluster
En primer lugar se arrancan los servidores que son los encargados de ejecu-tar el protocolo de consenso y gestionar el cluster y a continuacioacuten los clientesque no tienen praacutecticamente estado y dependen de los servidores
En el caso de Consul se debe indicar el directorio donde se guardan losficheros que describen los servicios asiacute como el archivo que especifica el resto delas opciones
1 Se inicia el primer servidor en uno de los equipos
$ consu l agent minuscon f i gminusd i r e t c consu l d s e r v i c e s minuscon f i gminus f i l e consu l_server j son
2 Los siguientes equipos deben unirse al anterior por lo que antildeadimos elargumento join con la direccioacuten del primer servidor Para el caso de otrosservidores
$ consu l agent minuscon f i gminusd i r e t c consu l d s e r v i c e s minuscon f i gminus f i l e consu l_server j son minus j o i n ltIP_servidor1gt
37
Una vez los servidores han alcanzado el consenso y elegido un liacuteder en losclientes
$ consu l agent minuscon f i gminusd i r e t c consu l d s e r v i c e s minuscon f i gminus f i l e c on su l_c l i en t j son minus j o i n ltIP_cualquierServ idorgt
El proceso para iniciar Nomad es igual y los comandos similares sin embargoya no es necesario indicar una direccioacuten IP fija en los equipos sino el nombre dedominio del servicio de Nomad registrado por Consul En el primer servidor
$ nomad agent minusc on f i g nomad_server j son
Y el resto de equipos (con su fichero de configuracioacuten correspondiente)$ nomad agent minusc on f i g nomad_server j son minus j o i n nomad s e r v i c e consu l
Por uacuteltimo para desplegar la aplicacioacuten web se han escrito tres ficherosque detallan las tareas de la interfaz web API y los balanceadores de cargaMediante la CLI
$ nomad run minusaddress=http lt ip_c lus te r gt4646 lt f i l e hclgt
O mediante la API HTTP de Nomad$ cu r l minusX POST minusd ltf i l e hclgthttp lt ip_c lus te r gt4646 jobltjob_namegt
Ansible
Como se puede comprobar con el aumento del nuacutemero de equipos pasa aser inviable manejar todos los nodos a traveacutes de terminal Ademaacutes como seha comentado con anterioridad Nomad requiere que en los nodos clientes es-teacuten instalados las herramientas que soporten las tareas por ejemplo el motorde Docker Por ello para facilitar tanto el arranque como la instalacioacuten de lasdependencias vamos a usar Ansible una herramienta de coacutedigo abierto desarro-llada en Python que permite gestionar configuraciones aprovisionar recursosdespliegue de aplicaciones de forma automaacutetica
A grandes rasgos esta herramienta funciona mediante ficheros en formatoYAML denominados play-books que describen un conjunto de pasos a ejecutaren una lista de equipos remotos Estos pasos son ejecutados por moacutedulos inde-pendientes a traveacutes de SSH es decir en cualquier ordenador con conexioacuten a los
38
hosts dado su contrasentildea o clave puacuteblica puede arrancar el script y realizariacutealos pasos de forma remota gestionando el cluster desde un solo equipo
Se han desarrollado guiones para lo siguiente
Descarga de los binarios de Nomad y Consul en todos los nodos copiade los ficheros de configuracioacuten baacutesicos y modificarlos de acuerdo a cadanodo (nombre del equipo direccioacuten IP)
Instalacioacuten de las dependencias
Arranque de Nomad y Consul
Ansible extiende su funcionalidad a traveacutes de moacutedulos independientes que per-miten por ejemplo instalar paquetes mediante herramientas de gestioacuten de pa-quetes (APT yum) aprovisionar automaacuteticamente maacutequinas virtuales de Ama-zon EC2
Algunas opciones de los ficheros de configuracioacuten de Nomad y Consul sondependientes del nodo particular por ejemplo la interfaz de red Para estetrabajo se ha realizado un moacutedulo para modificar los ficheros de configuracioacutende forma automaacutetica En el repositorio del proyecto se encuentra una carpetadonde se encuentran todos los ficheros necesarios para desplegar un clustertotalmente funcional solo requiere de una liacutenea de terminal con Ansible
$ ans ib l eminusplaybook minus i hos t s minusk ltssh_passgt minusu ltnode_usergt s i t e yml
39
62 Servicio de integracioacuten continua
Se ha implementado un sistema de integracioacuten continua que permite ejecu-tar tareas de compilacioacuten y pruebas de forma distribuida aumentando asiacute elrendimiento de los equipos En primer lugar se detallaraacute los motivos por los quepuede resultar beneficioso para las empresas una implementacioacuten de este tipo alo que seguiraacute los detalles del despliegue
621 DevOps
Metodologiacutea que defiende la comunicacioacuten y colaboracioacuten entre desarrolla-dores de software y los profesionales de operaciones a lo largo de todo el ciclo devida de una aplicacioacuten Estaacute muy relacionado con el desarrollo aacutegil de softwareesto es un enfoque para los proyectos que defiende el desarrollo iterativo e in-cremental donde los requisitos y soluciones evolucionan con el tiempo seguacuten lanecesidad del proyecto DevOps extiende esta filosofiacutea a todas los componentesde un servicio incluyendo sistemas y operaciones
Se trata de un concepto que cada organizacioacuten o empresa adapta a suspropias necesidades y procesos de negocio en este proyecto nos vamos a centraren la integracioacuten continua una praacutectica fundamental tanto del desarrollo aacutegilcomo de esta filosofiacutea
622 Integracioacuten Continua
Se define como una praacutectica de desarrollo software donde los miembros delequipo ponen en comuacuten su trabajo frecuentemente al menos una vez al diacutea21Cada integracioacuten se verifica con una compilacioacuten automaacutetica que incluye laejecucioacuten de pruebas para detectar errores de integracioacuten tan pronto como seaposible
Desde el punto de vista operativo esto supone automatizar la configuracioacutende equipos o el despliegue de maacutequinas virtuales donde compilar el proyecto yejecutar las pruebas y posteriormente eliminarlas Este flujo de trabajo se vebeneficiado en entornos distribuidos ya que el objetivo del desarrollador es com-probar el resultado de las pruebas raacutepidamente sin preocuparse del despliegueo los propios equipos
Para esta prueba de concepto vamos a usar Jenkins un servidor de integra-cioacuten continua escrito en Java que nos permite definir trabajos que contendraacutenla descripcioacuten tanto del entorno como su ejecucioacuten
Este sigue una estructura maestro-esclavo muy similar al de los gestores declusters usados en este proyecto el maestro contiene toda la loacutegica del servicio
21httpmartinfowlercomarticlescontinuousIntegrationhtml
40
trabajos autenticacioacuten y los esclavos son los encargados de la ejecucioacuten ensiacute Jenkins tiene varias viacuteas para aprovisionar los uacuteltimos
Mediante SSH
Interfaz graacutefica
Desarrollar un script propio
Ejecucioacuten de un fichero java
La ventaja de usar planificadores es que el despliegue de esclavos es dinaacutemicoes decir no tener una maacutequina especiacuteficamente configurada para ello DCOS yNomad se encargaraacuten de configurar estos despliegues en sus maacutequinas y poste-riormente eliminarlos Para ello se ha usado la uacuteltima opcioacuten definiendo tareasque descarguen el fichero java Con todo ello se consigue un entorno de inte-gracioacuten continua eficiente que ademaacutes permite la ejecucioacuten de otros servicios deforma independiente
Jenkins permite la creacioacuten de plugins que extienden sus funcionalidadesTanto Nomad22 como Apache Mesos cuentan con uno que permite su integra-cioacuten
Para esta prueba se va a usar el mismo proyecto que para el caso de usode orquestacioacuten de contenedores la aplicacioacuten web al que se le ha antildeadido untest para comprobar que se conecta correctamente a la base de datos medianteMocha un framework de Nodejs Por otro lado se antildeade el plugin de git ya queel coacutedigo se obtiene de GitHub el repositorio remoto de control de versiones delproyecto
El proceso general de ejecucioacuten seriacutea como sigue
1 Se ejecuta el maestro de Jenkins como tarea Docker partiendo de la imagenoficial
2 Al arrancar un trabajo se manda una tarea a los planificadores que laasignaraacuten a un nodo cliente Esta tarea consiste en la descarga del ficherode configuracioacuten Java y arrancarlo configurando el equipo como un clientede Jenkins temporalmente
3 Jenkins ejecuta el trabajo en el nuevo cliente en este caso iniciar la apli-cacioacuten web iniciar las pruebas y generar un informe
4 Se elimina el cliente
A continuacioacuten se detallan los matices de cada herramienta a la hora de imple-mentar este servicio
22Desarrollado por Ivo Verberk httpwwwivoverberknl
41
623 Jenkins con Nomad
El plugin permite la ejecucioacuten del fichero Java mediante dos controladorescontenedores Docker y Java En este proyecto nos hemos decantado por el pri-mero ya que nos ahorra instalar la maacutequina virtual de java en todos los nodoscliente Por ello se ha construido un contenedor base con Java para la ejecucioacutendel fichero de configuracioacuten y Nodejs para lanzar la aplicacioacuten web
El plugin se configura con la direccioacuten IP del cluster y el contenedor queejecuta el esclavo Jenkins Por su parte el trabajo en Jenkins se define conel repositorio en GitHub donde se aloja el coacutedigo del proyecto a probar y loscomandos a ejecutar en este caso npm update y npm test
624 Jenkins con DCOS
En el caso de DCOS su sistema de paquetes incluye Jenkins por lo queal instalarlo ya se tiene la configuracioacuten de Mesos totalmente funcional Sinembargo para ejecutar la aplicacioacuten en particular y las pruebas se requiere deNodejs en los equipos esclavos por ello debemos antildeadir un plugin de Jenkinsque permite instalar este entorno antes de ejecutar el trabajo Una vez hechoesto soacutelo queda definir la tarea igual que en el caso anterior
Cabe destacar que Mesosphere tambieacuten ha desarrollado un plugin que per-mite hacer despliegues en Marathon de tal manera que permitiriacutea con cadacommit del coacutedigo compilar la imagen del contenedor Docker y desplegarlaautomaacuteticamente aunque en este proyecto no se ha hecho pruebas de esta fun-cionalidad
42
7 Escalando la infraestructura
Uno de los factores clave que se busca a la hora de implementar sistemasdistribuidos es el poder escalar la infraestructura de forma maacutes sencilla estoes detectar que las maacutequinas estaacuten alcanzando el liacutemite de su capacidad yaumentar eacutesta ya sea mejorando sus caracteriacutesticas teacutecnicas o antildeadiendo maacutesnodos al cluster
El coacutedigo y todos los ficheros de configuracioacuten de esta seccioacuten tambieacuten sepueden encontrar en el repositorio del proyecto en GitHub23
71 Disentildeo
Microsoft Azure permite organizar los servicios cloud de forma loacutegica a traveacutesde grupos de recursos y asiacute poder crear o eliminar eacutestos en conjunto parauna aplicacioacuten determinada (por ejemplo una aplicacioacuten web suele requerir demaacutequinas virtuales bases de datos almacenamiento) Ademaacutes dispone dela opcioacuten de crear plantillas en formato JSON que permite al desarrolladordefinir los recursos y su interrelacioacuten para desplegar de forma automaacutetica unainfraestructura TI en la nube
Azure tambieacuten ofrece la posibilidad de monitorizar el estado de las maacutequinasvirtuales a traveacutes de extensiones lo que permite configurar el escalado automaacute-tico al alcanzar cierto liacutemite definido por el operador Eacutesta es a priori la formaen que deberiacutea implementarse hablando en teacuterminos de eficiencia sin embargoesta aproximacioacuten es totalmente dependiente de la plataforma es decir no sepuede extrapolar a otro proveedor o sobre recursos propios sin realizar un nue-vo disentildeo En este proyecto las tareas que son ejecutadas por estos equipos notienen estado ya que todo lo relativo a la persistencia lo hemos asignado fueradel cluster esto permite escalar la plataforma a traveacutes de otra aproximaciones
Las plantillas aceptan una serie de variables a indicar por el usuario entreotras los conjuntos de escala para definir los nodos aceptan una variable quedefine el nuacutemero de maacutequinas que los componen Por otro lado Azure ofreceuna API REST y kits de desarrollo software (SDK por sus siglas en ingleacutes) quepermiten su despliegue de forma programaacutetica Aprovechando estas facilidadesen este proyecto se va a aproximar la escalabilidad con el sucesivo desplieguede la infraestructura de forma automaacutetica se monitorizan los equipos y si sedetecta una maacutequina excesivamente cargada se aumenta el nuacutemero de equiposen la plantilla y se vuelve a desplegar
23httpsgithubcomAntonioAlfrzCloud-Orchestrators
43
En este proyecto se han disentildeado las plantillas para desplegar la arquitec-tura necesaria tanto de Nomad como de DCOS En el caso de la primera eldespliegue es maacutes descriptivo ya que incluye maacutequinas virtuales grupos de se-guridad redes En el caso de DCOS Azure cuenta con un servicio especiacuteficopara clusters gobernados por DCOS denominado Azure Container Service queincluye los componentes necesarios y la instalacioacuten ya realizada
72 Implementacioacuten
En primer lugar para monitorizar el estado de los equipos se va a usar laherramienta Nagios un sistema que permite controlar el estado del hardwarey los servicios de un equipo Se trata de una herramienta muy completa de laque se va a usar su capacidad para ejecutar comandos (plugins) en los nodospara detectar picos de carga generar alertas y ejecutar programas para estoseventos
Se ha desplegado una maacutequina virtual con esta herramienta en ambos siste-mas y se ha instalado una extensioacuten de Nagios (Nagios Remote Plugin Executor)en todos los nodos que permite ejecutar comprobaciones remotamente en con-creto para esta prueba de concepto medir el nivel de saturacioacuten de la unidadcentral de procesamiento (CPU por sus siglas del ingleacutes) Cuando sucede uncambio de estado de una maacutequina esto es cuando este paraacutemetro supera el liacutemi-te definido por el operador Nagios permite actuar en consecuencia ejecutandoprogramas por ello se ha desarrollado un script que ejecuta lo siguiente
Un programa desarrollado en Python con el SDK de Azure que modificalas plantillas y despliega los recursos
Un guioacuten de Ansible para instalar todos los componentes necesarios en lasnuevas maacutequinas y arrancar de nuevo el cluster y las aplicaciones
44
8 Resultados y conclusiones
En este uacuteltimo apartado se da una visioacuten global del proyecto asiacute como a lasconclusiones maacutes importantes a las que se ha llegado y posibles temas futurosde desarrollo
81 Comparacioacuten
Ambas herramientas ofrecen las funcionalidades para gestionar los recursoseficientemente ofreciendo a los desarrolladores una plataforma donde desplegarsus aplicaciones de forma distribuida independientemente de los equipos fiacutesicosy el hardware que las soporten
DCOS es una herramienta que en un comienzo fue privativa pero cuyos res-ponsables la empresa Mesosphere decidieron publicar una versioacuten de coacutedigoEacutesta nos permite gestionar un cluster de una forma sencilla y usable ademaacutes decomplementarlo con otras herramientas como el balanceador de carga integradoo la autenticacioacuten de usuarios ademaacutes estaacute basada en Apache Mesos un pro-yecto de relativa madurez y con el soporte de la Apache Software FoundationDe forma resumida DCOS ofrece muchas posibilidades y servicios a cambiode una arquitectura e instalacioacuten maacutes compleja
Por su parte HashiCorp con menor tiempo de desarrollo ha conseguidouna herramienta muy sencilla de desplegar que ademaacutes cumple con todas lasfuncionalidades baacutesicas ejecutando un simple binario en cada nodo se puededesplegar un gestor de clusters totalmente funcional Sin embargo no cuentacon todas las posibilidades de Mesos (Nomad cuenta con menos controladoresque entornos posibles de Mesos) ni con los antildeadidos de DCOS lo que implicael uso de otras herramientas para complementar el servicio (Consul HAProxy)
De entre las dificultades encontradas al usar estas herramientas y desplegaraplicaciones sobre ellas se puede destacar la depuracioacuten en ocasiones se desco-noce si un error viene de la propia herramienta de la aplicacioacuten desplegada o delequipo fiacutesico si no se cuenta con un sistema de procesamiento de registro unose puede encontrar con muacuteltiples terminales abiertas inspeccionando numerososficheros de registro buscando posibles errores Ademaacutes no dejan de ser solucio-nes que para usar eficientemente se debe conocer parte de su funcionamientoy sintaxis a la hora de describir la tareas lo que supone un esfuerzo antildeadido yaque cada una tiene sus particularidades y liacutemites
45
82 Conclusiones
En una sociedad cada vez maacutes digital las empresas deben adaptarse a unmercado cuya demanda de contenido no deja de crecer Las nuevas arquitecturascomo microservicios asiacute como la gran cantidad de datos generada implica queuna mejor gestioacuten de los recursos y la rapidez para desplegar o escalar solucionesdando valor al cliente lo maacutes raacutepido posible es uno de los objetivos de todas lasempresas de base tecnoloacutegica
Las ventajas que ofrecen los planificadores con aplicaciones distribuidas sonnumerosas sin ir maacutes lejos empresas tan punteras como Google llevan maacutesde 10 antildeos orquestando contenedores24 Por un lado permiten aumentar elrendimiento de los equipos propios y por otro implementar un servicio comoplataforma para despliegues distribuidos sobre cualquier conjunto hardware deesta forma se provee un servicio similar al de la nube puacuteblica pero con laprincipal diferencia de que se elimina la independencia con el proveedor (vendorlock-in) esto es las aplicaciones no tienen limitaciones impuestas por eacuteste talescomo lenguaje de programacioacuten o herramientas y permite despliegues hiacutebridosentre recursos propios y la nube
83 Objetivos conseguidos
Implementacioacuten de los planificadores propuestos en la nube Se ha en-tendido y detallado el funcionamiento de estas herramientas y se hanimplementado en el servicio de infraestructura de Microsoft Azure
Despliegue de aplicaciones y servicios distribuidos Servicios que se usanactualmente en la industria del desarrollo software asiacute como una aplica-cioacuten web con una arquitectura moderna han sido desplegados de formadistribuida en los equipos cumpliendo con la funcionalidad esperada ade-maacutes de consiguiendo una alta disponibilidad
Aproximacioacuten de arquitectura escalable Se ha hecho una aproximacioacutende infraestructura escalable de forma que sea parcialmente extrapolable aotros proveedores
24httpwwwnextplatformcom20160322decade-container-control-google
46
84 Liacuteneas de investigacioacuten
Siguiendo con la materia de este proyecto se presentan posibles liacuteneas deinvestigacioacuten
Analizar el despliegue con estas herramientas de aplicaciones de Big Datay comparar la eficiencia con respecto a soluciones especializadas
Analizar el rendimiento de los algoritmos de planificacioacuten antes pruebasde estreacutes y situaciones de alta contienda
Comparar el uso de estas herramientas con las praacutecticas actuales de laindustria o implementacioacuten en un sistema de produccioacuten real
47
Referencias
[1] LA Barroso y U Houmllzle laquoThe Datacenter as a Computer An Introduc-tion to the Design of Warehouse-Scale Machinesraquo En Morgan amp ClaypoolPublishers ()
[2] Systems Research Group ndash NetOS (University of Cambridge) The evolu-tion of cluster scheduler architectures 2016 url httpswwwclcamacukresearchsrgnetoscamsasblog2016-03-09-scheduler-architectureshtml
[3] A Das I Gupta y A Motivala SWIM Scalable Weakly-consistent Infection-style Process Group Membership Protocol Inf teacutec Dept of ComputerScience Cornell University url https www cs cornell edu ~asdasresearchdsn02-swimpdf
[4] D Dubhashi y A Das Mastering Mesos PACKT Publishing mayo de2016
[5] The Apache Software Foundation Apache Mesos documentation urlhttpsmesosapacheorg
[6] David Greenberg Building Applications on Mesos OrsquoReilly Media 2016[7] Armand Grillet Comparison of Container Schedulers Inf teacutec Technische
Universitaumlt Berlin[8] HashiCorp Consul documentation url httpswwwconsulio[9] HashiCorp Nomad documentation url httpsdcosio[10] Dan C Marinescu Cloud computing theory and practice Morgan Kauf-
mann 2013[11] Mesosphere DCOS documentation url httpswwwnomadproject
io[12] Microsoft Azure documentation url httpsazuremicrosoftcom
es-esdocumentation[13] D Ongaro y J Ousterhout In Search of an Understandable Consensus
Algorithm Inf teacutec Stanford University url httpsraftgithubioraftpdf
[14] Fei Teng laquoRessource allocation and schelduling models for cloud compu-tingraquo Tesis de mtriacutea Ecole Centrale Paris 2011
[15] A Williams y col Automation and Orchestration with Docker and Contai-ners A Comprehensive Overview of the Docker and Container Ecosystem3 The New Stack 2016
48
- Resumen
- Summary
- Iacutendice de figuras
- Introduccioacuten y objetivos
-
- Contexto
- Objetivos
- Estructura del documento
-
- Cloud Computing
- Nuevas cargas de trabajo
- Gestioacuten de recursos Planificadores
-
- Sistemas distribuidos
-
- Clasificacioacuten
-
- Herramientas
-
- DCOS
-
- Apache Mesos
- Ejemplos de uso
-
- Nomad
-
- Protocolo de consenso Raft
- Protocolo gossip SWIM
- Planificacioacuten
-
- Casos de uso y despliegue
-
- Aplicacioacuten Web
-
- DCOS
- Nomad
-
- Servicio de integracioacuten continua
-
- DevOps
- Integracioacuten Continua
- Jenkins con Nomad
- Jenkins con DCOS
-
- Escalando la infraestructura
-
- Disentildeo
- Implementacioacuten
-
- Resultados y conclusiones
-
- Comparacioacuten
- Conclusiones
- Objetivos conseguidos
- Liacuteneas de investigacioacuten
-
Los programas que se implementan en entornos distribuidos se caracterizanpor ejecutarse de forma concurrente en equipos independientes estar conectadospor una red que introduce fallos aleatorios y no compartir memoria ni reloj Estoimplica entre otras cosas que
Los nodos soacutelo tienen un acceso raacutepido a su memoria local por lo quecualquier informacioacuten relativa al estado global puede ser potencialmenteerroacutenea
Las maacutequinas pueden sufrir caiacutedas de forma aleatoria
El intercambio de informacioacuten puede fallar ya sea por error en transmisioacuteno por caiacuteda de los nodos
Estas dificultades se ponen de manifiesto en el teorema de CAP en cienciasde la computacioacuten el teorema de CAP que lanzado inicialmente como conjetu-ra en el antildeo 2000 por Eric Brewer (motivo por el cual al teorema se le conoceformalmente como teorema de Brewer) y posteriormente demostrado en el antildeo20026 establece que es imposible para un sistema de coacutemputo distribuido ga-rantizar simultaacuteneamente dos de las tres propiedades siguientes
Consistencia (Consistency) es decir que todos los nodos vean la mismainformacioacuten al mismo tiempo Se busca que un cambio en el sistema soacutelose ejecute satisfactoriamente si y soacutelo si se efectuacutea a todos las maacutequinasde tal forma que los datos entre ellos nunca difieren y la respuesta a unapeticioacuten sea la misma independientemente del nodo que la atienda
Disponibilidad (Availability) esto es la garantiacutea de que toda peticioacuten debeobtener una respuesta (servicio funcional) aunque exista inconsistenciaentre nodos
Tolerancia al particionado (Partition Tolerance) es decir que el sistemasiga funcionado a pesar de un fallo en la comunicacioacuten entre los equipos
Por todo lo expresado anteriormente conseguir un sistema distribuido capazde ofrecer procesamiento de forma transparente implica una arquitectura TIcompleja Se requieren de subsistemas y herramientas que permitan la cohesioacutenentre todos los nodos
Gestor de los recursos de las diferentes maacutequinas
Monitorizacioacuten tanto de los servicios activos como de la funcionalidad delsistema ademaacutes de poliacuteticas para recuperacioacuten de fallo
Protocolos de consenso que permitan a los nodos ser consistentes con elestado global del cluster
6urlhttpsgroupscsailmitedutdspapersGilbertBrewer2pdf
9
Herramientas de descubrimiento de servicios que permita la comunicacioacutenentre tareas distribuidas
Planificadores Encargados de distribuir las tareas y procesos en las dife-rentes maacutequinas asignaacutendole parte de su capacidad
Los planificadores del ingleacutes cluster schedulers son un componente funda-mental por lo que vamos a entrar un poco maacutes en detalle en ellos
Planificadores (Cluster Schedulers)
Es el software encargado de monitorizar los recursos usados por cada maacute-quina perteneciente a un cluster y distribuir la carga de trabajo entre ellas deacuerdo a un poliacutetica o reglas
Este tipo de herramientas comparten cierta terminologiacutea que es relevantedefinir
Tarea Unidad de trabajo computacional comprendida por una secuenciade instrucciones datos de entrada y recursos asociados Por ejemplo laejecucioacuten de un comando o el arranque de una base de datos
Nodo Cualquier maacutequina integrante de un cluster En una arquitecturamaestro-esclavo se definen dos roles
bull Cliente Agente Esclavo Aquellos ordenadores que se encargan deejecutar las tareas
bull Maestro Servidor Su objetivo es mantener el estado del cluster ygestionar sus recursos
411 Clasificacioacuten
A lo largo de los uacuteltimos antildeos se han desarrollado diferentes tipos de plani-ficadores[2]
Monoliacutetico
Un solo planificador que se encarga de distribuir todas las tareas entran-tes La mayoriacutea de los planificadores en computacioacuten de alto rendimiento asiacutecomo Borg desarrollado por Google son de este tipo En la figura 3 se pue-de observar de forma graacutefica el procedimiento siendo las cajas grises maacutequinaspertenecientes al cluster y los ciacuterculos las tareas a asignar
10
Figura 3 Planificador monoliacuteticoFuente httpswwwclcamacuk
Planificacioacuten de dos niveles
La mayoriacutea de los clusters ejecutan aplicaciones con distintas necesidadesdesde procesos casi instantaacuteneos hasta servicios persistenteslo que implica dis-tintas necesidades de recursos
Por ello la planificacioacuten a dos niveles distingue dos funciones la gestioacutende recursos (gestor) y la disposicioacuten de las tareas (planificador) Cada serviciotiene su propio planificador de tal manera que el gestor les ldquoofertardquo recursosde acuerdo a una poliacutetica y los planificadores se encargan de escoger la maacutesadecuada Esto permite que el proceso de distribucioacuten sea maacutes acorde con lasnecesidades de los diferentes servicios Apache Mesos que detallaremos maacutesadelante sigue este esquema
Como desventaja cabriacutea sentildealar que esta programacioacuten implica que los pla-nificadores pierden la vista general de la infraestructura y las tareas soacutelo puedenejecutarse con los recursos que les son ofrecidos lo que dificulta la implementa-cioacuten de prioridades de ejecucioacuten de tareas entre otras
Figura 4 Planificador de dos niveles
11
Planificacioacuten de estado compartido
Muacuteltiples reacuteplicas del estado del cluster se actualizan independientementepara cada planificador como se observa en la figura 5 cuando sucede un cambiode forma local el planificador se encarga de informar al resto
Ejemplo de este tipo son Omega la evolucioacuten de Borg por parte de GoogleMicrosoft Apollo y Nomad que usaremos para los casos de uso
De entre las desventajas se puede destacar el hecho de que en general losnodos trabajan con informacioacuten desactualizada lo que conlleva una degradacioacutendel rendimiento en situaciones de alta contienda
Figura 5 Planificador de estado compartido
Planificacioacuten distribuida
En este caso no existe coordinacioacuten entre los distintos planificadores Cadauno de ellos funciona con su propia vista del cluster Las tareas pueden serorganizadas por cualquiera de ellos y desplegadas en cualquier parte del clusteren base a la aleatoriedad y multiplexacioacuten estadiacutestica de los flujos de trabajosin ninguacuten control central
Figura 6 Planificador distribuido
12
5 Herramientas
En la industria comienzan a aparecer soluciones software de coacutedigo abiertoque aglutinan los servicios necesarios para gestionar la infraestructura TI de ma-nera maacutes eficaz El objetivo es doble se busca facilitar la gestioacuten de los recursosde computacioacuten para organizaciones con instalaciones propias mediante su usocon un enfoque cloud esto es desplegar aplicaciones a traveacutes de un conjuntode ordenadores de forma transparente y sin tener en cuenta la infraestructurasubyacente o aprovechar el maacuteximo rendimiento de la infraestructura de losproveedores cloud puacuteblicos de forma que se tiene el maacuteximo control sobre eacutestapero no se depende de las soluciones propietarias permitiendo asiacute despliegueshiacutebridos
Entre estas herramientas se pueden destacar
OpenStack Proyecto desarrollado por la fundacioacuten del mismo nombre paraproporcionar servicios de infraestructuras (IaaS) basado en componentesque se comunican a traveacutes de APIs El componente Magnum incluye mo-tores de orquestacioacuten de contenedores
Kubernetes Sistema de orquestacioacuten de contenedores Docker creado por Goo-gle
CoreOs Sistema operativo basado en Linux disentildeado para despliegues distri-buidos sobre contenedores incluyendo mecanismos de descubrimiento deservicio y comparticioacuten de configuracioacuten
Docker Swarm Herramienta nativa de orquestacioacuten de contenedores Docker
YARN Entorno de gestioacuten de recursos y aplicaciones distribuidas de Hadoopuna libreriacutea software de procesamiento de grandes conjuntos de datos
Como podemos observar existe un gran rango de opciones para gestionar lainfraestructura desde un bajo nivel como puede ser OpenStack hasta Kuberne-tes o Docker Swarm que ofrecen exclusivamente orquestacioacuten de contenedores
En este trabajo se ha optado por Mesosphere DCOS y HashiCorp Nomadque se encuentran en el teacutermino medio su objetivo es proporcionar serviciosde plataforma que permitan la coexistencia dediferentes cargas de trabajo en elcluster
13
51 DCOS
DCOS es un proyecto de coacutedigo abierto7 creado y desarrollado por la empre-sa Mesosphere Se describe como un sistema operativo distribuido que abstraelos recursos de un cluster (capacidad de procesamiento memoria) permite lagestioacuten de muacuteltiples ordenadores de forma transparente y simplifica la instala-cioacuten de aplicaciones distribuidas
Su arquitectura se puede comparar a la de Linux en teacuterminos de nuacutecleo(kernel) y espacio de usuario El primero consta de recursos protegidos a losque no puede acceder el usuario e involucra operaciones de bajo nivel comoasignacioacuten de recursos o aislamiento de procesos En el espacio de usuario seejecutan las aplicaciones y servicios de maacutes alto nivel
Siguiendo con este siacutemil el nuacutecleo de DCOS estaacute basado en Apache Mesosque se explicaraacute en un apartado posterior y el espacio de usuario que estaacute com-prendido por los componentes del sistema esto es las diferentes herramientasque en conjunto conforman DCOS y los servicios encargados de planificar yejecutar las aplicaciones y tareas del usuario
Figura 7 Arquitectura DCOSFuente httpsdcosio
De entre los componentes que conforman DCOS destacan
Admin Router Balanceador de carga central basado en NGINX que dis-pone un proxy entre todos los servicios en el puerto 80 permitiendo sugestioacuten mediante la interfaz graacutefica Ademaacutes se encarga de la autenticacioacutenpara acceder al panel de administracioacuten
Cosmos Gestor de paquetes de las aplicaciones
Diagnostics Se ejecuta en todos los nodos y se encarga de monitorizar elestado de los daemons que sustentan DCOS
7Desde abril de 2016 httpsmesospherecomblog20160419open-source-dcos
14
Exhibitor Gestiona y automatiza el despliegue de ZooKeper la herra-mienta que provee de configuracioacuten centralizada y registro de nombres
Marathon Equivale al proceso init de los sistemas tipo Unix esto es elprimer proceso en ejecucioacuten tras la carga del kernel y que genera los demaacutesprocesos Se encarga de arrancar y monitorizar las aplicaciones y servicios
Mesos-DNS Servicio de DNS interno que define el dominio mesos pa-ra nodos y tareas en el cluster es decir permite resolver nombres conindependencia de la direccioacuten fiacutesica
Minuteman Balanceador de carga integrado a nivel TCPUDP disponiblepara las propias aplicaciones
Por otra parte se definen como servicios a las diferentes aplicaciones dis-tribuidas que DCOS permite instalar en el cluster y que pueden haber sidodesarrollados por la misma empresa Mesosphere o por terceros por ejemploApache Spark Jenkins o Apache Hadoop En la figura 8 se muestra un diagramade los servicios disponibles incluyendo algunos de las aplicaciones distribuidasque soporta DCOS
Figura 8 Servicios DCOSFuente httpsdcosio
511 Apache Mesos
El nuacutecleo de DCOS estaacute basado en Apache Mesos un proyecto de coacutedigoabierto creado por la Universidad de California Berkeley y desarrollado actual-mente por la fundacioacuten Apache Se trata de un administrador de clusters queabstrae los recursos y los dispone para diferentes aplicaciones y entornos de tra-bajo distribuidos (frameworks) mediante una interfaz comuacuten En el momento deredaccioacuten de este proyecto Apache Mesos soportaba una variedad de entornosque abarcaba desde Big Data (Apache Spark Hadoop) hasta bases de datos(Cassandra Hypertable)
15
Arquitectura
Mesos se basa en la asignacioacuten de dos roles diferentes a los nodos
Maestros (Masters) Se encargan de la gestioacuten y reparticioacuten de los recursospara los diferentes entornos de trabajo mediante ldquoofertas de recursosrdquo deacuerdo a los disponibles y a la poliacutetica de asignacioacuten (planificacioacuten en dosniveles)
Esclavos (Slaves) Ordenadores donde se ejecutaraacuten las aplicaciones y cu-yos recursos son ofertados por los maestros
En el caso de fallo del maestro las tareas pueden seguir ejecutaacutendose perono se podraacute asignar nuevos recursos ni tareas por ello pueden existir varios enel cluster para configuraciones de alta disponibilidad pero soacutelo uno orquesta alos esclavos
Para la eleccioacuten del master liacuteder Mesos usa Apache ZooKeeper un proyectode software desarrollado por la misma fundacioacuten cuyo objetivo es proveer deun servicio de configuracioacuten centralizado y registro de nombres8
Por otra parte los entornos de trabajo son los programas que deciden final-mente queacute recursos se van a usar y se encargan de que los esclavos ejecuten lastareas Eacutestos se ejecutan sobre Mesos y constan de dos componentes
Planificador (Scheduler) Optimiza y decide los recursos a utilizar de losofertados informando a los Masters
Procesador (Executor) Ejecuta las aplicaciones o servicios en los esclavos
El objetivo final es conseguir una interfaz liviana tolerante a fallos paracualquier tipo de entorno de trabajo de tal manera que en los esclavos del clusterpuedan ejecutarse simultaacuteneamente tareas con necesidades y duracioacuten diferentesPara ello se basa en dos conceptos asignacioacuten y aislamiento de recursos
Asignacioacuten de recursos
En el cluster pueden coexistir entornos de trabajo con tareas de larga dura-cioacuten y con gran consumo de recursos con tareas cortas que los ocupan y liberancon rapidez El maestro integra un moacutedulo de asignacioacuten de recursos (allocationmodule) que se encarga del algoritmo de distribucioacuten
En el momento de escribir este proyecto estaban desarrollados dos moacutedulosuno mediante el cual el usuario puede asignar prioridades y otro que implementa
8httpszookeeperapacheorg
16
el algoritmo Dominant Resource Fairness9 a grandes rasgos se determina entodos los esclavos la tarea en ejecucioacuten que necesita maacutes recursos y se calcula laproporcioacuten del recurso de mayor peso con respecto al total por ejemplo si unatarea ocupa 2 GB de memoria con respecto a 10 GB totales que tiene el clusterse le asigna un dominant share del 20 la tarea se asignaraacute al nodo con menordominant share
Aislamiento de recursos
Para conseguir que tareas de diferentes entornos de trabajo y con distin-ta naturaleza se ejecuten simultaacuteneamente en un mismo nodo Mesos usa loscontenedores Linux (descritos en la seccioacuten 3)
Funcionamiento
La figura 9 muestra el esquema de la arquitectura de Apache Mesos conalta disponibilidad (tres maestros) y con dos entornos de trabajo ejecutaacutendo-se Hadoop que permite el almacenamiento y procesamiento de gran cantidadde datos para proyectos de big data y un sistema que implementa la interfazsistema de paso de mensajes MPI
Como se puede observar el sistema ZooKeeper elige a un solo maestro comoliacuteder y eacuteste orquesta el cluster comunicando los esclavos con los planificadoresde los diferentes entornos de trabajo Tambieacuten se puede observar como las tareasde los distintos entornos estaacuten distribuidas entre los tres esclavos disponibles
Figura 9 Arquitectura de Apache MesosFuente httpsmesosapacheorg
El proceso de asignacioacuten se realiza como sigue en primer lugar un usuariosolicita la ejecucioacuten de una tarea mediante la interfaz de cada entorno de traba-jo (interfaz graacutefica API HTTP ) De forma paralela un esclavo informa almaestro de los recursos que tiene libres En consecuencia eacuteste se lo notifica almoacutedulo de asignacioacuten que en funcioacuten de su configuracioacuten decide cuaacutento ofertar
9httpspeopleeecsberkeleyedu~aligpapersdrfpdf
17
y a queacute entorno de trabajo y enviacutea la oferta a los planificadores Eacutestos respondenal maestro con queacute recursos ha decidido usar para cada tarea Finalmente lastareas son enviadas al esclavo seleccionado el cual asigna los recursos indicadosal procesador (executor) quien finalmente las ejecuta
Cabriacutea pensar que esta metodologiacutea puede conducir a situaciones en lasque un entorno podriacutea quedarse con tareas sin ejecutarse a la espera de unaoferta satisfactoria para ello Mesos implementa un sistema de filtros medianteel cual los entornos especifican los requisitos miacutenimos que debe cumplir unaoferta por ejemplo se puede especificar en queacute nodos debe desplegarse la tareaEste sistema estaacute disentildeado asiacute con el objetivo de mantener lo maacutes transparenteposible esta herramientas de forma que acepte entornos de trabajo de distintasnaturalezas
512 Ejemplos de uso
Grandes empresas estaacuten usando Apache Mesos con eficacia de acuerdo a susnecesidades e infraestructuras Caben destacar
Ebay En el modelo de implementacioacuten continua en esta empresa10 cadadesarrollador cuenta con su propia instancia que se ejecuta en una maacutequinavirtual dedicada lo que ha conllevado un uso de los recursos poco eficiente Enuna prueba de concepto consiguieron realizar una herramienta de integracioacutencontinua distribuida basada en un cluster con Apache mesos y con el entornoMarathon y Jenkins
Apple Anuncioacute que el motor de su famosa herramienta de asistencia per-sonal para iPhones Siri estaacute desplegada sobre Apache Mesos11 Para ello handesarrollado su propio entorno para facilitar a los ingenieros a desplegar los ser-vicios que la herramienta necesita para resolver las peticiones de los usuarios
Twitter Desarrolloacute su propio entorno denominado Aurora y actualmentegestionan sus recursos y miden el coste de las tareas que los empleados usancon el objetivo de que sean conscientes del gasto que puede suponer un usoinadecuado de la infraestructura12
10httpwwwebaytechblogcom20140404delivering-ebays-ci-solution-with-apache-mesos-part-i11httpwwwbusinessinsidercomapple-siri-uses-apache-mesos-2015-812httpswwwlinuxcomNEWS4-UNIQUE-WAYS-UBER-TWITTER-PAYPAL-AND-HUBSPOT-USE-APACHE-MESOS
18
52 Nomad
Herramienta de coacutedigo abierto de gestioacuten de clusters creada y desarrolladapor Hashicorp13 que permite el despliegue de aplicaciones y procesos de formadistribuida
Las principales diferencias con Apache Mesos a grandes rasgos son
Arquitectura maacutes ligera Nomad soacutelo requiere de un fichero para funcionarejecutaacutendolo con las correspondientes configuraciones en todos los nodosrealiza las funciones de gestioacuten del cluster eleccioacuten de liacuteder planificacioacutende recursos y ejecucioacuten de las tareas
Centro de datos y regiones muacuteltiples Su arquitectura estaacute orientada afacilitar la gestioacuten de diferentes centros de datos geograacuteficamente distri-buidos
Entorno de ejecucioacuten Las tareas se definen y son interpretadas mediantecontroladores integrados en Nomad que se valen de los recursos y herra-mientas de los nodos clientes para ejecutarlas Esta integracioacuten dificultael desarrollo de controladores por parte de terceros a diferencia de Mesosque delega dicha responsabilidad en los entornos de trabajo externos alproyecto
Usa un planificador de estado compartido con respecto a la planificacioacutenen dos niveles de Mesos
Antes de entrar en maacutes detalle en la arquitectura es importante definir lossiguientes teacuterminos
Controlador (Driver) Software que se encarga de interpretar las definicionesde las tareas y ejecutarlas semejante a los procesadores de los entornosde trabajo de Mesos A la hora de redactar este proyecto Nomad contabacon controladores para contenedores Docker virtualizacioacuten de maacutequinasmediante el emulador QEMU aplicaciones java y archivos binarios
Grupo de trabajo (Task Group) Conjunto de tareas que se ejecutan en elmismo nodo cliente
Trabajo (Job) Conjunto loacutegico de tareas y grupos de trabajo que se despliegana la vez
Asignacioacuten (Allocation) Relacioacuten entre un grupo de trabajo y el cliente don-de se ejecuta
Evaluacioacuten (Evaluation) Proceso mediante el cual Nomad planifica y ges-tiona el registro o actualizaciones de los trabajos
13httpswwwhashicorpcom
19
Nomad sigue una arquitectura maestro-esclavo similar a la de Apache Mesosmuacuteltiples servidores acuerdan entre siacute un liacuteder que gestiona la planificacioacuten detareas en los clientes que soacutelo conocen sus asignaciones y las ejecutan
Todos los servidores participan paralelamente en tareas de planificacioacuten derecursos y asignacioacuten de tareas y ademaacutes entre ellos eligen un liacuteder que seencarga de la coordinacioacuten de la suscripcioacuten de los clientes al cluster y de lagestioacuten de las peticiones
Los clientes estaacuten configurados para comunicarse con el servidor usando lla-madas a procedimiento remoto (RPC por sus siglas en ingleacutes) que permite unordenador ejecutar coacutedigo en otra maacutequina Mediante esta tecnologiacutea los nodosclientes avisan de su estado e informa de sus asignaciones recursos y controla-dores disponibles
Existe la posibilidad de gestionar varios centros de datos agrupados en regio-nes eacutestas son independientes pero permite definir tareas o comprobar el estadode todas ellas desde cualquier punto A continuacioacuten se muestra una figura dela arquitectura a alto nivel de esta configuracioacuten
Figura 10 Arquitectura multi-regioacuten en NomadFuente httpswwwnomadprojectio
La herramienta se sustenta sobre tres protocolos fundamentales un protocolode consenso entre los servidores para compartir informacioacuten sobre su estado yel liacuteder un protocolo Gossip para la gestioacuten entre regiones y el planificador detareas
521 Protocolo de consenso Raft
El objetivo es obtener consistencia en un conjunto de nodos que comparteninformacioacuten es decir si un cliente realiza un cambio que todos los nodos veanla misma informacioacuten a la vez y ademaacutes sea tolerante a fallos Para ello se basaen el algoritmo Raft[13] que se detalla brevemente a continuacioacuten
20
Los nodos participantes en el algoritmo pueden estar en tres estados
Liacuteder (Leader) Todos los cambios que realicen en el cluster pasan por eacutel pri-mero
Seguidor (Follower) Nodo pasivo cuya responsabilidad es responder a laspeticiones del nodo liacuteder
Candidato (Candidate) Maacutequina que no ha encontrado liacuteder y solicita sueleccioacuten
Supongamos que tenemos cinco equipos que acaban de arrancar el protocoloEn la figura 11 se observan los nodos y sus respectivos registros a la derecha
Figura 11 Equipos sin consenso ejecutando el protocolo RAFTFuente httpsgithubcomongardieraftscope
Al comenzar todos los nodos son seguidores esperando recibir comunicacioacutende un nodo que actuacutee como liacuteder Cada nodo tiene un tiempo de espera aleatoriodespueacutes del cual si no es informado por un liacuteder pasa a estado candidato y pideel ldquovotordquo al resto de los participantes El algoritmo divide el tiempo en plazos uncandidato pasa a liacuteder si recibe la mayoriacutea de los votos en un plazo determinadoSe define mayoriacutea o cuoacuterum (quorum) comolceil
N2rceil
+ 1 (1)
donde N representa el nuacutemero de nodos
Para el ejemplo propuesto de 5 equipos se requieren de 3 votos Soacutelo losnodos que se encuentren en estado seguidor pueden votar una uacutenica vez a laprimera solicitud que reciba dentro de un plazo
Supoacutengase que el nodo denotado con S1 ha cumplido su tiempo de espera yrealiza la peticioacuten de voto (figura 12) A partir de este momento se pueden dartres casos
La maacutequina gana la eleccioacuten y pasa a ser liacuteder informando al resto
Otro servidor se establece como liacuteder en el mismo momento
Varios nodos pasan a ser candidatos por lo que ninguno consigue los votos
21
Figura 12 Un equipo pasa a estado candidato (RAFT)
Si un candidato recibe un aviso de un liacuteder en el mismo plazo el primeropasa a ser seguidor y se acaba la eleccioacuten de liacuteder
Por otro lado si un equipo candidato no recibe los votos en el plazo y agotasu tiempo de espera avanza al siguiente plazo y repite el proceso de votacioacutenLa tercera posibilidad puede conllevar a un estado indefinido ya que varioscandidatos pueden agotar su tiempo de espera al mismo tiempo y repartir losvotos Para solventarlo el algoritmo establece tiempos de espera aleatorios paralos candidatos
Siguiendo con el ejemplo propuesto el servidor S1 pasa a ser el liacuteder Cadacierto tiempo eacuteste debe realizar avisos a los nodos seguidores para no agotar sutiempo de espera
En este momento el cluster de servidores estaacute en ldquoconsensordquo y la informacioacutenen todos los nodos estaacute actualizada Un cambio en la informacioacuten inicia unproceso de replicacioacuten el liacuteder registra el cambio lo pasa al resto de nodos yuna vez eacutestos responden el cambio se hace efectivo
Supoacutengase que se realiza un cambio en los datos en la figura 13 en la partederecha se observa el cambio en el registro del servidor S1 que informa a losnodos seguidores En consecuencia los nodos registran el cambio y responden aS1
Figura 13 Cambio en un registro (RAFT)
Una vez el cuoacuterum (en el ejemplo tres equipos) informa al liacuteder de que
22
ha registrado el cambio el liacuteder lo hace efectivo en su sistema y notifica a losnodos que hacen lo mismo En la figura 14 el enviacuteo todaviacutea no ha llegado ala maacutequina S3 y se observa que no ha hecho efectivo el cambio (en el registroaparece punteado)
Figura 14 Aprobacioacuten del resto de equipos (RAFT)
Este protocolo funcionaraacute correctamente mientras exista un nuacutemero de nodosen funcionamiento igual o superior al cuoacuterum en el ejemplo propuesto elcuoacuterum es tres por lo que el sistema puede tolerar la caiacuteda de dos de los equipos
522 Protocolo gossip SWIM
Nomad permite la gestioacuten simultaacutenea de varios centros de datos reparti-dos en regiones geograacuteficamente separadas requiriendo de un protocolo ligeroque mantenga a los miembros actualizados sobre los participantes del conjun-to Para ello usa una ligera variante del protocolo SWIM[3] (Scalable Weakly-consistent Infection-style Process Group Membership Protocol) desarrollada porHashiCorp Estaacute clasificado como un protocolo de tipo gossip que debe su nom-bre a la semejanza con coacutemo se distribuye un rumor en una red social
SWIM se sustenta en dos caracteriacutesticas fundamentales la deteccioacuten de fallosy la distribucioacuten de la informacioacuten relativa a los miembros A continuacioacuten sedetalla el funcionamiento de ambos componentes
Deteccioacuten de fallos
Este componente tiene dos paraacutemetros el periodo de protocolo T y el nuacutemerode subgrupos de deteccioacuten de fallos k en los que se dividen los nodos Paracomprobar la comunicacioacuten entre dos maacutequinas usa la utilidad ping basadaen el protocolo ICMP La deteccioacuten de caiacuteda de un servidor sigue el siguientealgoritmo
Durante el periodo T cada miembro Mi de un subgrupo elige otro al azar Mjdel mismo subgrupo y le enviacutea un mensaje ping para comprobar su estado Enel caso de que se cumpla un tiempo de espera determinado por una estimacioacuten
23
del tiempo de ida y vuelta (RTT por sus siglas en ingleacutes) de la red y no hayarespuesta Mi le vuelve a enviar un mensaje ping indirectamente a traveacutes deun nuacutemero k de miembros escogidos aleatoriamente De no recibir ninguna res-puesta Mi establece que Mj ha sufrido un fallo y lo etiqueta como ldquosospechosordquoinformando al componente de distribucioacuten
Figura 15 Diagrama de tiempo del protocolo SWIMFuente httpswwwcscornelledu
Componente de distribucioacuten
Se encarga de informar de cualquier cambio en los miembros a todo el con-junto Los eventos de nodo caiacutedo y la unioacuten o disociacioacuten de un miembro setransmiten a todos los servidores para que actualicen sus lista Para distribuirla informacioacuten a todos los nodos se podriacutea usar el meacutetodo de multicast perosuele estar deshabilitado Por ello se utiliza una teacutecnica de transmisioacuten denomi-nada Piggybacking mediante la cual se adjunta a los propios mensajes PINGy ACK del algoritmo la informacioacuten a distribuir reduciendo asiacute la congestioacutenen la red
523 Planificacioacuten
Proceso encargado de distribuir las tareas entre los nodos clientes de acuerdoa su estado
El planificador de Nomad estaacute basado en las publicaciones de Google sobresus herramientas de gestioacuten de clusters Borg y Omega14 y entiende los trabajosdescritos por el usuario como un estado deseado es decir su despliegue en unamaacutequina cliente de forma correcta y los clientes como el estado actual esto eslo que se encuentra en ejecucioacuten El registro actualizacioacuten o cancelacioacuten de un
14httpresearchgooglecompubspub43438html
24
trabajo asiacute como el fallo de un nodo cliente implican un cambio de estado atramitar por el sistema lo que se define como evaluacioacuten (evaluation) Esto uacutelti-mo supone comparar el estado actual (clientes) con el estado deseado (conjuntode trabajos registrados) y enviarlos a los planificadores correspondientes que seencargaraacuten de asignar las tareas a los nodos clientes
Figura 16 Procedimiento de asignacioacuten en NomadFuente httpswwwnomadprojectio
En la figura 16 se observa el flujo de trabajo en el que las distintas evalua-ciones se encolan en el evaluation broker que se ejecuta en el servidor liacuteder ygestiona las evaluaciones pendientes asignaacutendoles prioridades
A continuacioacuten los nodos servidores ejecutan los scheduling workers queprocesan las evaluaciones llamando a los distintos planificadores que generanun plan de asignacioacuten esto es un conjunto de relaciones entre las tareas y losnodos clientes donde se ejecutaraacuten Este proceso se divide en dos fases primerose descartan aquellos clientes que no cumplan los requisitos y posteriormentese asigna una calificacioacuten al resto Se selecciona el nodo con mayor puntuacioacuteny se encola el plan en el gestor que se ejecuta en el servidor liacuteder Existen tresplanificadores de acuerdo al tipo de trabajo
Service Incluye aquellos trabajos que estaacuten destinados a ejecutarse en un pe-riacuteodo largo de tiempo Para realizar las asignaciones el planificador evaluacuteala mayor parte de los nodos y usa una versioacuten del algoritmo Best fit in-fluenciada por el trabajo de Google en su herramienta Borg Se trata deun algoritmo de planificacioacuten que sacrifica tiempo a cambio de maximizarel rendimiento de los clientes asignando la tarea a la maacutequina que tengala mayor carga de trabajo con el objetivo de reducir equipos en funciona-
25
miento
Batch Tareas que incluyen listas de comandos en general de menor duracioacuteny que no requieren interaccioacuten con el usuario Se vale del algoritmo deSparrow desarrollado por la universidad de Berkeley15 para limitar losnodos clientes a evaluar
System Trabajos destinados a ejecutarse en todos los nodos incluso los que seunen al cluster posteriormente
Core Mantenimiento interno de Nomad
Una vez se ha realizado el proceso de planificacioacuten el nodo liacuteder lo registra enla cola de planes (plan queue) que se encarga de asignarles prioridad y manejarcondiciones de carrera es decir que no accedan a los recursos de los clientes sincontrol y evitar que eacutestos superen su capacidad
La maacutequina liacuteder del conjunto puede de este modo aceptar una asignacioacuteny ser ejecutada por los clientes o por el contrario rechazaacutersela al planificadorlo que implicariacutea realizar un plan parcial o totalmente nuevo
Finalmente el estado de las evaluaciones se actualizan y los clientes soninformados de las asignaciones ejecutaacutendose las tareas
15httppeopleeecsberkeleyedu~keopublicationssosp13-final17pdf
26
6 Casos de uso y despliegue
Con el objetivo de mostrar las posibles utilidades que este tipo de sistemaspueden tener en las infraestructuras TI actuales se han desplegado las dos he-rramientas en la nube Microsoft Azure usando su servicio cloud de instancias demaacutequinas virtuales Linux para simular un conjunto de ordenadores conectadosentre siacute por una red LAN Sobre ellas se ha implementado dos casos de usouna aplicacioacuten web con una arquitectura con cierta orientacioacuten a microserviciosy un sistema de integracioacuten continua
El coacutedigo y todos los ficheros de configuracioacuten se pueden encontrar en elrepositorio del proyecto en GitHub16
61 Aplicacioacuten Web
Se busca simular el proceso de adaptacioacuten de una solucioacuten web para su des-pliegue en un sistema distribuido con las herramientas anteriormente descritascon el objetivo de aumentar tanto su escalabilidad como disponibilidad medianteredundancia
Se ha partido de una aplicacioacuten ya existente17 un servicio de almacenamien-to y reproduccioacuten de canciones A grandes rasgos este servicio permite crearusuarios subir canciones con sus respectivas portadas tener playlists propias yescuchar las canciones a traveacutes de un navegador web
La solucioacuten estaacute dividida en 4 partes (figura 17)
Una vista web con la loacutegica
Un almacenamiento conectado en red (NAS por sus siglas en ingleacutes)
Una API REST para gestionar las peticiones al almacenamiento
Base de datos NoSQL basada en MongoDB
La nueva tendencia de los proyectos web es su implementacioacuten en contene-dores Docker ya que facilitan su portabilidad y ofrecen un procedimiento dedespliegue raacutepido sobre todo a la hora de desarrollar y realizar pruebas en en-tornos de produccioacuten simulados Por ello en este caso se va a hacer uso de los
16httpsgithubcomAntonioAlfrzCloud-Orchestrators17httpsgithubcomsonsoleslpCDPSfy
27
motores de orquestacioacuten de contenedores de ambas herramientas Marathon enDCOS y el controlador Docker en el caso de Nomad
Figura 17 Arquitectura aplicacioacuten web
A continuacioacuten vamos detallar el despliegue en ambas herramientas de es-ta solucioacuten y observar tanto queacute dificultades se encuentran como que ventajasofrecen El objetivo final es adaptar el proyecto modificaacutendolo lo menos posiblecon objeto de analizar la capacidad de estas herramientas para desplegar cual-quier aplicacioacuten sin que eso conlleve la modificacioacuten de la arquitectura de eacutestaes decir que no sea dependiente del entorno
611 DCOS
Se ha descrito DCOS como una herramienta que se despliega sobre un con-junto de ordenadores y que permite instalar gestionar el despliegue de sistemasdistribuidos
Microsoft Azure cuenta con una plantilla para desplegar en su servicio cloudun cluster de maacutequinas virtuales con DCOS ya instalado que cuenta con
Maacutequinas maestras (1 3 o 5 a seleccionar por el usuario) configuradascomo un conjunto de disponibilidad esto eso Azure da ciertas garantiacuteasde que al menos una maacutequina estaraacute en funcionamiento
Maacutequinas agentes Por motivos de seguridad se distinguen dos roles
bull Nodos privados solo accesibles desde la red interna y configuradoscomo un conjunto de escala un recurso de Azure para gestionar ydesplegar maacutequinas con configuraciones ideacutenticas para permitir unraacutepido escalado
bull Un equipo conectado accesible desde Internet a travntildees de un balan-ceador de carga puacuteblico y situado en una subred externa
28
Dos balanceadores de carga
bull La interfaz puacuteblica del cluster que se conecta con el cliente puacuteblicobull Acceso a los equipos maestros para el administrador que soacutelo permiteconexioacuten mediante SSH y credenciales
Almacenamiento para todas las maacutequinas
Configuraciones necesarias de red y seguridad
En la figura 18 se observa un diagrama de la infraestructura
Figura 18 Infraestructura en Azure
El primer obstaacuteculo es la persistencia de estado de la aplicacioacuten que seconsigue gracias a una base de datos no relacional basada en MongoDB asiacutecomo el almacenamiento de las canciones Para implementarla tenemos variasposibilidades
Montar un sistema externo de almacenamiento conectado en red en todoslos agentes donde se ejecuten las tareas de esta manera si una tarea pasade un nodo a otro por cualquier motivo puede tener acceso a los mismosficheros (opcioacuten del caso de uso original)
Implementar un sistema de ficheros distribuidos en los agentes
Usar los servicios de almacenamiento de las nubes puacuteblicas
Aprovechar el sistema de voluacutemenes persistentes de Apache Mesos Eacutestepermite reservar recursos de un agente de forma que al arrancar una tarease crea un volumen independiente del ciclo de vida de eacutesta con ello esosrecursos donde se ha almacenado la informacioacuten pueden volver a ofrecerseal mismo entorno de tal manera que otra tarea pueda acceder a ella
DCOS aprovecha este sistema de voluacutemenes persistentes y permite instalarbases de datos distribuidas como ArangoDB o Apache Cassandra sin embargoesto implicariacutea modificar todo el coacutedigo referente al modelo de la base de datos
29
Por motivos de eficiencia y latencia asiacute como de una mayor gobernabilidadde los datos la mejor opcioacuten es usar el recurso de voluacutemenes persistentes queofrece Apache Mesos ya que de esta manera se gestionariacutea la aplicacioacuten completamediante una uacutenica herramienta Sin embargo esto implica que la informacioacutense encuentra exclusivamente en el agente donde se haya ejecutado la tarea y porlo tanto se sigue requiriendo de software externo para distribuir la informacioacutenpara que se accesible para todos los agentes A la hora de realizar este proyectose encontraba en desarrollo Flocker una solucioacuten desarrollada por ClusterHQque permite compartir los voluacutemenes de Docker a traveacutes de un cluster quesi bien es compatible con el planificador de Mesos el proyecto se encontrabatodaviacutea en fases tempranas de desarrollo y los sistemas de almacenamiento quesoporta quedaban fuera del aacutembito de este trabajo
Por todo ello dado que las maacutequinas se han desplegado en la nube puacuteblicade Azure se decidioacute usar su servicio de almacenamiento de objetos para lascanciones y otra maacutequina para desplegar MongoDB y asiacute mantener el modelode datos original de la aplicacioacuten La diferencia del almacenamiento de obje-tos con respecto a nivel de fichero es que el primero no tiene jerarquiacutea paraorganizar los archivos eacutestos se guardan como objetos (con sus metadatos) enun mismo espacio soacutelo diferenciaacutendose por un identificador uacutenico esto implicaentre otras cosas que se puede acceder a un fichero dado uacutenicamente su IDindependientemente de la localizacioacuten fiacutesica de eacuteste facilitando pues la gestioacuteny el desarrollo
El coacutedigo del proyecto se ha modificado en los siguientes apartados
Las direcciones de la base de datos y los balanceadores de carga asiacute comosus puertos estaban originalmente fijos Se han configurado como variablesde entorno para facilitar el descubrimiento del servicio y hacer transpa-rente la aplicacioacuten al entorno de despliegue
La API REST se ha adaptado al almacenamiento en Azure en vez de enlocal
Estas modificaciones no suponen un cambio sustancial pero permiten separala persistencia de las tareas ejecutadas por DCOS lo que facilita en granmedida su ejecucioacuten al ser totalmente sin estado y ademaacutes implican tenerlos datos bajo un mayor control
Para la orquestacioacuten de contenedores se va a usar el entorno Marathondesarrollado tambieacuten por Mesosphere Eacuteste se puede usar a traveacutes de una interfazgraacutefica la interfaz de liacutenea de comandos (en lo que sigue CLI por sus siglas eningleacutes) de DCOS o con su API HTTP
Primero se han publicado la imaacutegenes de los contenedores que encapsulanla interfaz web y la api de la aplicacioacuten en el repositorio puacuteblico DockerHub
Los despliegues en este entorno se describen mediante ficheros JSON en losque se detalla entre otras opciones la imagen del contenedor los puertos a usar
30
los recursos que debe ocupar en un nodo o las instrucciones de monitorizacioacuten
Para el servicio de descubrimiento DCOS ofrece la posibilidad de asignardirecciones IP virtuales (VIP por sus siglas en ingleacutes) a tareas que se compartenen todos los nodos DCOS lleva integrado un balanceador de carga a nivel TCP(el componente denominado Minuteman) que balancea entre las direccionesvirtuales de las tareas y todas las instancias de eacutestas a lo largo del cluster Estoes necesario por dos motivos equilibrar la carga de los equipos con el fin deevitar un punto de uacutenico fallo mediante redundancia y evitar la contienda dedirecciones al ejecutar las tareas en puertos aleatorios
Este balanceador de carga estaacute basado en el trabajo de Michael Mitzenma-cher The Power of Two Choices in Randomized Load Balancing18 A grandesrasgos el algoritmo mantiene una media moacutevil exponencial de latencias paracada destino (backend) ademaacutes de las caiacutedas consecutivas Si un destino noresponde a una negociacioacuten en tres pasos (three way handshake) de forma con-secutiva en un periodo inferior a 5 ms se considera caiacutedo El algoritmo iterasobre los destinos disponibles en base a su histoacuterico de fallos y escoge dos deforma aleatoria de los cuales coge el de mejor meacutetrica
Las direcciones virtuales soacutelo se pueden resolver dentro del cluster porello para implementar la interfaz puacuteblica de la aplicacioacuten esto es el balancea-dor de carga de la interfaz web usaremos un paquete de DCOS denominadomarathon-lb un balanceador basado en HAProxy y adaptado por MesosphereEn este caso equilibra la carga de todas instancias de las tareas ejecutadas porel entorno Marathon por sus etiquetas y permite ademaacutes definir como puntode entrada muacuteltiples hosts virtuales definidos por sus nombres completos dedominio (FQDN por sus siglas en ingleacutes) en nuestro caso la interfaz puacuteblicadel balanceador de Azure para los agentes
Por motivos de seguridad todas las tareas se ejecutan en los agentes privadoses decir los que son exclusivamente accesibles desde la red interna Por su partemarathon-lb se ejecuta en el agente puacuteblico que cuenta con IP puacuteblica y lospuertos 80 (HTTP) y 8080 abiertos de forma que la aplicacioacuten sea accesibledesde Internet Esto es posible debido a que Apache Mesos permite reservarrecursos mediante roles asignados a nodos para un uso especiacutefico De esta formala arquitectura vista desde la aplicacioacuten quedariacutea como en la figura 19
18httpswwweecsharvardedu~michaelmpostscriptstpds2001pdf
31
Figura 19 Arquitectura de la aplicacioacuten web en DCOS
Ejecucioacuten
A la hora de desplegar la aplicacioacuten DCOS puede gestionarse medianteuna interfaz graacutefica o una interfaz de liacutenea de comandos La primera se accedea traveacutes de un navegador web en el puerto 80 (HTTP) y permite instalar losentornos disponibles observar el estado de los nodos y las tareas que se estaacutenejecutando y los ficheros de registros que eacutestas generan
La CLI permite el control desde un nodo o una maacutequina remota (suponiendoque los maestros tienen IP puacuteblica y el puerto 80 abierto) ya que DCOS tieneun sistema de autorizacioacuten que permite tener una interfaz puacuteblica con ciertasgarantiacuteas de seguridad
Por su parte cada entorno de trabajo puede ser controlado por la CLI peroademaacutes cuenta con sus propias interfaces Marathon expone una API HTTPen el puerto 8080 de la direccioacuten puacuteblica de los maestros del cluster asiacute comootra interfaz graacutefica Para desplegar un contenedor se podriacutea usar la CLI
$ dcos marathon app add lt f i l e j songt
O la API HTTP
$ cu r l minusX POST http lt ip_maestro gt8080v2apps minusd ltf i l e jsongt minusH Contentminustype app l i c a t i o n j son
32
612 Nomad
La arquitectura de Nomad es maacutes sencilla ya que solo requiere de un ficheroejecutable en todos los nodos para funcionar Si DCOS es la base de instala-cioacuten de entornos de terceros Nomad integra todas las funcionalidades baacutesicasesto es gestor de recursos planificador y ejecutor en los nodos cliente Estaherramienta cuenta con un menor tiempo de desarrollo y en el momento deescribir este documento cuenta exclusivamente con los siguientes controladoresen comparacioacuten con los entornos de DCOS
Motor Docker es decir funcioacuten de orquestacioacuten de contenedores
Ejecucioacuten de archivos binarios como comandos de Shell
Ejecucioacuten de aplicaciones Java
Virtualizacioacuten de maacutequinas mediante tecnologiacutea QEMU
Todos ellos necesitan que la tecnologiacutea subyacente esteacute instalada en las maacute-quinas clientes (Docker Java QEMU) Actualmente no permite el registro decontroladores por parte de terceros aunque estaacute planificado en un futuro ofreceruna interfaz para su desarrollo
Nomad no cuenta con el servicio de descubrimiento sin embargo puede inte-grarse con la herramienta Consul desarrollada por la misma empresa Por otrolado para el balanceo de carga usaremos un contenedor Docker con HAProxyuna herramienta de coacutedigo abierto que ofrece tanto servicios de proxy como debalanceador y cuyos ficheros de configuracioacuten completaremos con el proyectoConsul Template19
Consul
Consul sigue la misma arquitectura que Nomad es decir un nodo servidorque orquesta un conjunto de maacutequinas clientes y permite a los procesos que seejecutan en los equipos definirlos como servicios ofreciendo diversas caracteriacutes-ticas entorno a estos de los cuales vamos a usar dos
Descubrimiento de servicio Las maacutequinas clientes publican en el cataacutelogode servicios las tareas en ejecucioacuten y Consul les asigna nombres de dominioaccesibles por todos los miembros del cluster a traveacutes de la interfaz DNSincluida en esta herramientaConsul se integra con Nomad de forma que todas las tareas que se ejecu-ten en la segunda son automaacuteticamente publicados como servicios de laprimera de esta manera no hace falta conocer la direccioacuten de la maacutequinacliente donde se esteacute ejecutando el proceso ya que se puede acceder a eacutela traveacutes de su nombre de dominio de forma transparente Por ejemplo si
19[httpsgithubcomhashicorpconsul-template]
33
ejecutamos una tarea con ID web en el puerto 8080 se puede acceder aella en la direccioacuten webserviceconsul8080Para que las direcciones propias de Consul las resuelva su propio DNS y noel que esteacute asignado por defecto en la maacutequina usaremos la herramientadnsmasq20 que permite especificar la direccioacuten de un servidor DNS paraconsultas de direcciones especiacuteficas
Monitorizacioacuten Permite realizar comprobaciones del servicio y seguir su esta-do Aprovecharemos esta funcionalidad tanto para definir el propio procesode Nomad como servicio de Consul como las tareas desplegadas
HAProxy + Consul Template
HAProxy es una solucioacuten versaacutetil de coacutedigo abierto que ofrece solucionesde balanceo de carga y proxy Existen otras herramientas en el mercado comoNGINX o ldirectord sin embargo HAProxy suponiacutea una solucioacuten sencilla deconfigurar para mostrar el caso de uso
El uso de estas herramientas se debe a dos motivos para que no existacontienda con respecto a los puertos de los clientes usados por las tareas eacutestos sevan a asignar de forma dinaacutemica lo que en principio implicariacutea que la aplicacioacutendeberiacutea realizar consultas DNS de tipo SRV (que incluye puertos) a la interfazde Consul y balancear la carga entre tareas por redundancia y capacidad
Como la direccioacuten IP y puerto son variables cada vez que las tareas seactualicen o se reasignen es necesario volver a configurar HAProxy de formamanual Por ello HashiCorp ha desarrollado un programa denominado Con-sul Template que realiza peticiones sucesivas a la interfaz HTTP de Consul delas direcciones fiacutesicas de un servicio y reinicia automaacuteticamente el proceso deHAProxy Asiacute definiendo estas tareas como servicios Consul podremos tantomonitorizarlas como escalar las tareas dinaacutemicamente sin necesidad de cambiarel balanceador A partir del contenedor Docker oficial de HAProxy se ha desa-rrollado otro con la configuracioacuten baacutesica y con Consul Template para desplegarlocomo una tarea en Nomad
Despliegue
Se ha usado el mismo coacutedigo que en el apartado anterior con la persistenciaen el servicio de almacenamiento de Azure Desde la perspectiva del hardwarese implementaraacute la misma infraestructura que en el caso de DCOS (figura 18)estos es definiremos dos tipos de maacutequinas clientes un agente que se conectaraacutecon el balanceador de carga con nombre de dominio puacuteblico y donde se desple-garaacute el balanceador de carga de la vista web y agentes privados no accesiblesdesde fuera del cluster y donde se ejecutaraacuten el resto de tareas en la red inter-na La principal diferencia radica en las tareas que ejecutan HAproxy y ConsulTemplate que sustituye a las direcciones IP virtuales que ofrece DCOS
20httpwwwthekelleysorgukdnsmasqdochtml
34
Figura 20 Despliegue en Azure de Nomad+Consul
Cabe matizar que los balanceadores basados en HAProxy se implementanpor necesidad de la aplicacioacuten para el descubrimiento del servicio a diferenciade los de Azure que se implementan por motivos de seguridad y escalabilidaddel cluster en siacute
Configuracioacuten Nomad
Los ficheros de configuracioacuten de las maacutequinas maacutester y cliente son similaresy comparten la mayoriacutea de las opciones como por ejemplo el nombre del nodoo la interfaz de red donde escucha Nomad las peticiones Sus opciones son engeneral auto-explicativas sin embargo existen dos detalles que matizar
El proceso de Nomad escucha las peticiones tanto de los protocolos deconsenso como del usuario a traveacutes de una interfaz de red que se debeindicar en el fichero de configuracioacuten
En el caso de los clientes se deben indicar las direcciones de los servidoresdel cluster sin embargo se trata de un sistema dinaacutemico en el que losnodos pueden sufrir errores y cambiar de direccioacuten Por ello se ha definidoNomad como un servicio de Consul y asiacute poder definir la direccioacuten de losservidores como un nombre de dominio no por su direccioacuten fiacutesica que elservidor DNS de Consul se encargaraacute de resolver
Por defecto Nomad usa los siguientes puertos
API HTTP 4646 Peticiones HTTP y recepcioacuten de oacuterdenes mediante laliacutenea de comandos
RPC 4647 Protocolo de consenso entre los nodos del cluster
Serf 4648 Protocolo de gossip entre los servidores de los centros de datosgobernados por Nomad
35
Los dos uacuteltimos deben ser interfaces alcanzables por otros nodos sin embargo laAPI HTTP por motivos de seguridad deberiacutea ser local ya que en caso contrariocualquier persona con acceso a ella tiene el control sobre la herramienta Eacutestasolo deberiacutea estar accesible en un servidor o gestionarlo mediante una terminalSSH por ejemplo En este trabajo al ser una prueba de concepto se ha abiertoen todos los nodos
Trabajos de Nomad
Las tareas se detallan en ficheros con formato HashiCorp Configuration Lan-guage un derivado del formato JSON creado por la empresa que le da nombrecompatible con eacuteste y que permite comentarios
En estos ficheros se puede definir
La regioacuten y el centro de datos donde se ejecutaraacute (Nomad permite lagestioacuten de centros de datos geograacuteficamente distribuidos en regiones)
La poliacutetica de actualizacioacuten de la tarea
Grupo de tareas esto es que se ejecutaraacuten en el mismo nodo
El nuacutemero de grupos a ejecutarescalar asiacute como los liacutemite que debencumplir los nodos asignados
La poliacutetica de reinicio ante fallo o error
Tareas El controlador su configuracioacuten los paraacutemetros del servicio aso-ciado a registrar en Consul asiacute como los recursos que consume (puertosmemoria)
En nuestro caso usamos sobre todo el controlador Docker esto eso orques-tacioacuten de contenedores en los nodos clientes y tres de sus opciones
Imagen del contenedor Se han subido todas las imaacutegenes del proyecto a Doc-ker Hub donde por defecto se busca la imagen
Puertos Los puertos a usar por el contenedor que pueden ser estaacuteticos asigna-dos por el usuario o dinaacutemicos siendo Nomad el que se encarga de mapearun puerto libre del nodo cliente al expuesto por el contenedor
Servidores DNS Como usamos la interfaz DNS de Consul como descubri-miento de servicio se debe configurar el contenedor para que use cualquiernodo del cluster como servidor DNS
Configuracioacuten Consul
Al ser desarrolladas por la misma empresa los ficheros de configuracioacuten deConsul y Nomad comparten muchas opciones Consul tambieacuten acepta peticionesa traveacutes de una interfaz de red siendo los puertos usados por defecto
36
RPC 8300 8400 Maneja la peticiones del resto de nodos y usuarios
Serf 8301 8302 Protocolo gossip
HTTP API 8500
HTTPS API Desactivada por defecto
Interfaz DNS 8600
Se debe asignar a los protocolos internos del cluster esto es RPC y Serf unainterfaz alcanzable por los nodos y por el contrarioasignar a los dos uacuteltimos ala interfaz de loopback por motivos de seguridad
Cabe destacar que Consul tambieacuten cuenta con una interfaz graacutefica que per-mite ver el estado de los equipos y los servicios registrados y que se encuentra enel mismo puerto que la API HTTP en la direccioacuten httpIP_EQUIPO8500ui
Ejecucioacuten
Tanto Nomad como Consul requieren de la ejecucioacuten de un fichero en todoslos nodos integrantes del cluster Como prueba de concepto se ha decidido usardos servidores para ambos aunque cabe matizar que es un nuacutemero ineficienteya que la caiacuteda de uno de ellos supondriacutea la peacuterdida del cuoacuterum y por tantodel consenso del cluster
En primer lugar se arrancan los servidores que son los encargados de ejecu-tar el protocolo de consenso y gestionar el cluster y a continuacioacuten los clientesque no tienen praacutecticamente estado y dependen de los servidores
En el caso de Consul se debe indicar el directorio donde se guardan losficheros que describen los servicios asiacute como el archivo que especifica el resto delas opciones
1 Se inicia el primer servidor en uno de los equipos
$ consu l agent minuscon f i gminusd i r e t c consu l d s e r v i c e s minuscon f i gminus f i l e consu l_server j son
2 Los siguientes equipos deben unirse al anterior por lo que antildeadimos elargumento join con la direccioacuten del primer servidor Para el caso de otrosservidores
$ consu l agent minuscon f i gminusd i r e t c consu l d s e r v i c e s minuscon f i gminus f i l e consu l_server j son minus j o i n ltIP_servidor1gt
37
Una vez los servidores han alcanzado el consenso y elegido un liacuteder en losclientes
$ consu l agent minuscon f i gminusd i r e t c consu l d s e r v i c e s minuscon f i gminus f i l e c on su l_c l i en t j son minus j o i n ltIP_cualquierServ idorgt
El proceso para iniciar Nomad es igual y los comandos similares sin embargoya no es necesario indicar una direccioacuten IP fija en los equipos sino el nombre dedominio del servicio de Nomad registrado por Consul En el primer servidor
$ nomad agent minusc on f i g nomad_server j son
Y el resto de equipos (con su fichero de configuracioacuten correspondiente)$ nomad agent minusc on f i g nomad_server j son minus j o i n nomad s e r v i c e consu l
Por uacuteltimo para desplegar la aplicacioacuten web se han escrito tres ficherosque detallan las tareas de la interfaz web API y los balanceadores de cargaMediante la CLI
$ nomad run minusaddress=http lt ip_c lus te r gt4646 lt f i l e hclgt
O mediante la API HTTP de Nomad$ cu r l minusX POST minusd ltf i l e hclgthttp lt ip_c lus te r gt4646 jobltjob_namegt
Ansible
Como se puede comprobar con el aumento del nuacutemero de equipos pasa aser inviable manejar todos los nodos a traveacutes de terminal Ademaacutes como seha comentado con anterioridad Nomad requiere que en los nodos clientes es-teacuten instalados las herramientas que soporten las tareas por ejemplo el motorde Docker Por ello para facilitar tanto el arranque como la instalacioacuten de lasdependencias vamos a usar Ansible una herramienta de coacutedigo abierto desarro-llada en Python que permite gestionar configuraciones aprovisionar recursosdespliegue de aplicaciones de forma automaacutetica
A grandes rasgos esta herramienta funciona mediante ficheros en formatoYAML denominados play-books que describen un conjunto de pasos a ejecutaren una lista de equipos remotos Estos pasos son ejecutados por moacutedulos inde-pendientes a traveacutes de SSH es decir en cualquier ordenador con conexioacuten a los
38
hosts dado su contrasentildea o clave puacuteblica puede arrancar el script y realizariacutealos pasos de forma remota gestionando el cluster desde un solo equipo
Se han desarrollado guiones para lo siguiente
Descarga de los binarios de Nomad y Consul en todos los nodos copiade los ficheros de configuracioacuten baacutesicos y modificarlos de acuerdo a cadanodo (nombre del equipo direccioacuten IP)
Instalacioacuten de las dependencias
Arranque de Nomad y Consul
Ansible extiende su funcionalidad a traveacutes de moacutedulos independientes que per-miten por ejemplo instalar paquetes mediante herramientas de gestioacuten de pa-quetes (APT yum) aprovisionar automaacuteticamente maacutequinas virtuales de Ama-zon EC2
Algunas opciones de los ficheros de configuracioacuten de Nomad y Consul sondependientes del nodo particular por ejemplo la interfaz de red Para estetrabajo se ha realizado un moacutedulo para modificar los ficheros de configuracioacutende forma automaacutetica En el repositorio del proyecto se encuentra una carpetadonde se encuentran todos los ficheros necesarios para desplegar un clustertotalmente funcional solo requiere de una liacutenea de terminal con Ansible
$ ans ib l eminusplaybook minus i hos t s minusk ltssh_passgt minusu ltnode_usergt s i t e yml
39
62 Servicio de integracioacuten continua
Se ha implementado un sistema de integracioacuten continua que permite ejecu-tar tareas de compilacioacuten y pruebas de forma distribuida aumentando asiacute elrendimiento de los equipos En primer lugar se detallaraacute los motivos por los quepuede resultar beneficioso para las empresas una implementacioacuten de este tipo alo que seguiraacute los detalles del despliegue
621 DevOps
Metodologiacutea que defiende la comunicacioacuten y colaboracioacuten entre desarrolla-dores de software y los profesionales de operaciones a lo largo de todo el ciclo devida de una aplicacioacuten Estaacute muy relacionado con el desarrollo aacutegil de softwareesto es un enfoque para los proyectos que defiende el desarrollo iterativo e in-cremental donde los requisitos y soluciones evolucionan con el tiempo seguacuten lanecesidad del proyecto DevOps extiende esta filosofiacutea a todas los componentesde un servicio incluyendo sistemas y operaciones
Se trata de un concepto que cada organizacioacuten o empresa adapta a suspropias necesidades y procesos de negocio en este proyecto nos vamos a centraren la integracioacuten continua una praacutectica fundamental tanto del desarrollo aacutegilcomo de esta filosofiacutea
622 Integracioacuten Continua
Se define como una praacutectica de desarrollo software donde los miembros delequipo ponen en comuacuten su trabajo frecuentemente al menos una vez al diacutea21Cada integracioacuten se verifica con una compilacioacuten automaacutetica que incluye laejecucioacuten de pruebas para detectar errores de integracioacuten tan pronto como seaposible
Desde el punto de vista operativo esto supone automatizar la configuracioacutende equipos o el despliegue de maacutequinas virtuales donde compilar el proyecto yejecutar las pruebas y posteriormente eliminarlas Este flujo de trabajo se vebeneficiado en entornos distribuidos ya que el objetivo del desarrollador es com-probar el resultado de las pruebas raacutepidamente sin preocuparse del despliegueo los propios equipos
Para esta prueba de concepto vamos a usar Jenkins un servidor de integra-cioacuten continua escrito en Java que nos permite definir trabajos que contendraacutenla descripcioacuten tanto del entorno como su ejecucioacuten
Este sigue una estructura maestro-esclavo muy similar al de los gestores declusters usados en este proyecto el maestro contiene toda la loacutegica del servicio
21httpmartinfowlercomarticlescontinuousIntegrationhtml
40
trabajos autenticacioacuten y los esclavos son los encargados de la ejecucioacuten ensiacute Jenkins tiene varias viacuteas para aprovisionar los uacuteltimos
Mediante SSH
Interfaz graacutefica
Desarrollar un script propio
Ejecucioacuten de un fichero java
La ventaja de usar planificadores es que el despliegue de esclavos es dinaacutemicoes decir no tener una maacutequina especiacuteficamente configurada para ello DCOS yNomad se encargaraacuten de configurar estos despliegues en sus maacutequinas y poste-riormente eliminarlos Para ello se ha usado la uacuteltima opcioacuten definiendo tareasque descarguen el fichero java Con todo ello se consigue un entorno de inte-gracioacuten continua eficiente que ademaacutes permite la ejecucioacuten de otros servicios deforma independiente
Jenkins permite la creacioacuten de plugins que extienden sus funcionalidadesTanto Nomad22 como Apache Mesos cuentan con uno que permite su integra-cioacuten
Para esta prueba se va a usar el mismo proyecto que para el caso de usode orquestacioacuten de contenedores la aplicacioacuten web al que se le ha antildeadido untest para comprobar que se conecta correctamente a la base de datos medianteMocha un framework de Nodejs Por otro lado se antildeade el plugin de git ya queel coacutedigo se obtiene de GitHub el repositorio remoto de control de versiones delproyecto
El proceso general de ejecucioacuten seriacutea como sigue
1 Se ejecuta el maestro de Jenkins como tarea Docker partiendo de la imagenoficial
2 Al arrancar un trabajo se manda una tarea a los planificadores que laasignaraacuten a un nodo cliente Esta tarea consiste en la descarga del ficherode configuracioacuten Java y arrancarlo configurando el equipo como un clientede Jenkins temporalmente
3 Jenkins ejecuta el trabajo en el nuevo cliente en este caso iniciar la apli-cacioacuten web iniciar las pruebas y generar un informe
4 Se elimina el cliente
A continuacioacuten se detallan los matices de cada herramienta a la hora de imple-mentar este servicio
22Desarrollado por Ivo Verberk httpwwwivoverberknl
41
623 Jenkins con Nomad
El plugin permite la ejecucioacuten del fichero Java mediante dos controladorescontenedores Docker y Java En este proyecto nos hemos decantado por el pri-mero ya que nos ahorra instalar la maacutequina virtual de java en todos los nodoscliente Por ello se ha construido un contenedor base con Java para la ejecucioacutendel fichero de configuracioacuten y Nodejs para lanzar la aplicacioacuten web
El plugin se configura con la direccioacuten IP del cluster y el contenedor queejecuta el esclavo Jenkins Por su parte el trabajo en Jenkins se define conel repositorio en GitHub donde se aloja el coacutedigo del proyecto a probar y loscomandos a ejecutar en este caso npm update y npm test
624 Jenkins con DCOS
En el caso de DCOS su sistema de paquetes incluye Jenkins por lo queal instalarlo ya se tiene la configuracioacuten de Mesos totalmente funcional Sinembargo para ejecutar la aplicacioacuten en particular y las pruebas se requiere deNodejs en los equipos esclavos por ello debemos antildeadir un plugin de Jenkinsque permite instalar este entorno antes de ejecutar el trabajo Una vez hechoesto soacutelo queda definir la tarea igual que en el caso anterior
Cabe destacar que Mesosphere tambieacuten ha desarrollado un plugin que per-mite hacer despliegues en Marathon de tal manera que permitiriacutea con cadacommit del coacutedigo compilar la imagen del contenedor Docker y desplegarlaautomaacuteticamente aunque en este proyecto no se ha hecho pruebas de esta fun-cionalidad
42
7 Escalando la infraestructura
Uno de los factores clave que se busca a la hora de implementar sistemasdistribuidos es el poder escalar la infraestructura de forma maacutes sencilla estoes detectar que las maacutequinas estaacuten alcanzando el liacutemite de su capacidad yaumentar eacutesta ya sea mejorando sus caracteriacutesticas teacutecnicas o antildeadiendo maacutesnodos al cluster
El coacutedigo y todos los ficheros de configuracioacuten de esta seccioacuten tambieacuten sepueden encontrar en el repositorio del proyecto en GitHub23
71 Disentildeo
Microsoft Azure permite organizar los servicios cloud de forma loacutegica a traveacutesde grupos de recursos y asiacute poder crear o eliminar eacutestos en conjunto parauna aplicacioacuten determinada (por ejemplo una aplicacioacuten web suele requerir demaacutequinas virtuales bases de datos almacenamiento) Ademaacutes dispone dela opcioacuten de crear plantillas en formato JSON que permite al desarrolladordefinir los recursos y su interrelacioacuten para desplegar de forma automaacutetica unainfraestructura TI en la nube
Azure tambieacuten ofrece la posibilidad de monitorizar el estado de las maacutequinasvirtuales a traveacutes de extensiones lo que permite configurar el escalado automaacute-tico al alcanzar cierto liacutemite definido por el operador Eacutesta es a priori la formaen que deberiacutea implementarse hablando en teacuterminos de eficiencia sin embargoesta aproximacioacuten es totalmente dependiente de la plataforma es decir no sepuede extrapolar a otro proveedor o sobre recursos propios sin realizar un nue-vo disentildeo En este proyecto las tareas que son ejecutadas por estos equipos notienen estado ya que todo lo relativo a la persistencia lo hemos asignado fueradel cluster esto permite escalar la plataforma a traveacutes de otra aproximaciones
Las plantillas aceptan una serie de variables a indicar por el usuario entreotras los conjuntos de escala para definir los nodos aceptan una variable quedefine el nuacutemero de maacutequinas que los componen Por otro lado Azure ofreceuna API REST y kits de desarrollo software (SDK por sus siglas en ingleacutes) quepermiten su despliegue de forma programaacutetica Aprovechando estas facilidadesen este proyecto se va a aproximar la escalabilidad con el sucesivo desplieguede la infraestructura de forma automaacutetica se monitorizan los equipos y si sedetecta una maacutequina excesivamente cargada se aumenta el nuacutemero de equiposen la plantilla y se vuelve a desplegar
23httpsgithubcomAntonioAlfrzCloud-Orchestrators
43
En este proyecto se han disentildeado las plantillas para desplegar la arquitec-tura necesaria tanto de Nomad como de DCOS En el caso de la primera eldespliegue es maacutes descriptivo ya que incluye maacutequinas virtuales grupos de se-guridad redes En el caso de DCOS Azure cuenta con un servicio especiacuteficopara clusters gobernados por DCOS denominado Azure Container Service queincluye los componentes necesarios y la instalacioacuten ya realizada
72 Implementacioacuten
En primer lugar para monitorizar el estado de los equipos se va a usar laherramienta Nagios un sistema que permite controlar el estado del hardwarey los servicios de un equipo Se trata de una herramienta muy completa de laque se va a usar su capacidad para ejecutar comandos (plugins) en los nodospara detectar picos de carga generar alertas y ejecutar programas para estoseventos
Se ha desplegado una maacutequina virtual con esta herramienta en ambos siste-mas y se ha instalado una extensioacuten de Nagios (Nagios Remote Plugin Executor)en todos los nodos que permite ejecutar comprobaciones remotamente en con-creto para esta prueba de concepto medir el nivel de saturacioacuten de la unidadcentral de procesamiento (CPU por sus siglas del ingleacutes) Cuando sucede uncambio de estado de una maacutequina esto es cuando este paraacutemetro supera el liacutemi-te definido por el operador Nagios permite actuar en consecuencia ejecutandoprogramas por ello se ha desarrollado un script que ejecuta lo siguiente
Un programa desarrollado en Python con el SDK de Azure que modificalas plantillas y despliega los recursos
Un guioacuten de Ansible para instalar todos los componentes necesarios en lasnuevas maacutequinas y arrancar de nuevo el cluster y las aplicaciones
44
8 Resultados y conclusiones
En este uacuteltimo apartado se da una visioacuten global del proyecto asiacute como a lasconclusiones maacutes importantes a las que se ha llegado y posibles temas futurosde desarrollo
81 Comparacioacuten
Ambas herramientas ofrecen las funcionalidades para gestionar los recursoseficientemente ofreciendo a los desarrolladores una plataforma donde desplegarsus aplicaciones de forma distribuida independientemente de los equipos fiacutesicosy el hardware que las soporten
DCOS es una herramienta que en un comienzo fue privativa pero cuyos res-ponsables la empresa Mesosphere decidieron publicar una versioacuten de coacutedigoEacutesta nos permite gestionar un cluster de una forma sencilla y usable ademaacutes decomplementarlo con otras herramientas como el balanceador de carga integradoo la autenticacioacuten de usuarios ademaacutes estaacute basada en Apache Mesos un pro-yecto de relativa madurez y con el soporte de la Apache Software FoundationDe forma resumida DCOS ofrece muchas posibilidades y servicios a cambiode una arquitectura e instalacioacuten maacutes compleja
Por su parte HashiCorp con menor tiempo de desarrollo ha conseguidouna herramienta muy sencilla de desplegar que ademaacutes cumple con todas lasfuncionalidades baacutesicas ejecutando un simple binario en cada nodo se puededesplegar un gestor de clusters totalmente funcional Sin embargo no cuentacon todas las posibilidades de Mesos (Nomad cuenta con menos controladoresque entornos posibles de Mesos) ni con los antildeadidos de DCOS lo que implicael uso de otras herramientas para complementar el servicio (Consul HAProxy)
De entre las dificultades encontradas al usar estas herramientas y desplegaraplicaciones sobre ellas se puede destacar la depuracioacuten en ocasiones se desco-noce si un error viene de la propia herramienta de la aplicacioacuten desplegada o delequipo fiacutesico si no se cuenta con un sistema de procesamiento de registro unose puede encontrar con muacuteltiples terminales abiertas inspeccionando numerososficheros de registro buscando posibles errores Ademaacutes no dejan de ser solucio-nes que para usar eficientemente se debe conocer parte de su funcionamientoy sintaxis a la hora de describir la tareas lo que supone un esfuerzo antildeadido yaque cada una tiene sus particularidades y liacutemites
45
82 Conclusiones
En una sociedad cada vez maacutes digital las empresas deben adaptarse a unmercado cuya demanda de contenido no deja de crecer Las nuevas arquitecturascomo microservicios asiacute como la gran cantidad de datos generada implica queuna mejor gestioacuten de los recursos y la rapidez para desplegar o escalar solucionesdando valor al cliente lo maacutes raacutepido posible es uno de los objetivos de todas lasempresas de base tecnoloacutegica
Las ventajas que ofrecen los planificadores con aplicaciones distribuidas sonnumerosas sin ir maacutes lejos empresas tan punteras como Google llevan maacutesde 10 antildeos orquestando contenedores24 Por un lado permiten aumentar elrendimiento de los equipos propios y por otro implementar un servicio comoplataforma para despliegues distribuidos sobre cualquier conjunto hardware deesta forma se provee un servicio similar al de la nube puacuteblica pero con laprincipal diferencia de que se elimina la independencia con el proveedor (vendorlock-in) esto es las aplicaciones no tienen limitaciones impuestas por eacuteste talescomo lenguaje de programacioacuten o herramientas y permite despliegues hiacutebridosentre recursos propios y la nube
83 Objetivos conseguidos
Implementacioacuten de los planificadores propuestos en la nube Se ha en-tendido y detallado el funcionamiento de estas herramientas y se hanimplementado en el servicio de infraestructura de Microsoft Azure
Despliegue de aplicaciones y servicios distribuidos Servicios que se usanactualmente en la industria del desarrollo software asiacute como una aplica-cioacuten web con una arquitectura moderna han sido desplegados de formadistribuida en los equipos cumpliendo con la funcionalidad esperada ade-maacutes de consiguiendo una alta disponibilidad
Aproximacioacuten de arquitectura escalable Se ha hecho una aproximacioacutende infraestructura escalable de forma que sea parcialmente extrapolable aotros proveedores
24httpwwwnextplatformcom20160322decade-container-control-google
46
84 Liacuteneas de investigacioacuten
Siguiendo con la materia de este proyecto se presentan posibles liacuteneas deinvestigacioacuten
Analizar el despliegue con estas herramientas de aplicaciones de Big Datay comparar la eficiencia con respecto a soluciones especializadas
Analizar el rendimiento de los algoritmos de planificacioacuten antes pruebasde estreacutes y situaciones de alta contienda
Comparar el uso de estas herramientas con las praacutecticas actuales de laindustria o implementacioacuten en un sistema de produccioacuten real
47
Referencias
[1] LA Barroso y U Houmllzle laquoThe Datacenter as a Computer An Introduc-tion to the Design of Warehouse-Scale Machinesraquo En Morgan amp ClaypoolPublishers ()
[2] Systems Research Group ndash NetOS (University of Cambridge) The evolu-tion of cluster scheduler architectures 2016 url httpswwwclcamacukresearchsrgnetoscamsasblog2016-03-09-scheduler-architectureshtml
[3] A Das I Gupta y A Motivala SWIM Scalable Weakly-consistent Infection-style Process Group Membership Protocol Inf teacutec Dept of ComputerScience Cornell University url https www cs cornell edu ~asdasresearchdsn02-swimpdf
[4] D Dubhashi y A Das Mastering Mesos PACKT Publishing mayo de2016
[5] The Apache Software Foundation Apache Mesos documentation urlhttpsmesosapacheorg
[6] David Greenberg Building Applications on Mesos OrsquoReilly Media 2016[7] Armand Grillet Comparison of Container Schedulers Inf teacutec Technische
Universitaumlt Berlin[8] HashiCorp Consul documentation url httpswwwconsulio[9] HashiCorp Nomad documentation url httpsdcosio[10] Dan C Marinescu Cloud computing theory and practice Morgan Kauf-
mann 2013[11] Mesosphere DCOS documentation url httpswwwnomadproject
io[12] Microsoft Azure documentation url httpsazuremicrosoftcom
es-esdocumentation[13] D Ongaro y J Ousterhout In Search of an Understandable Consensus
Algorithm Inf teacutec Stanford University url httpsraftgithubioraftpdf
[14] Fei Teng laquoRessource allocation and schelduling models for cloud compu-tingraquo Tesis de mtriacutea Ecole Centrale Paris 2011
[15] A Williams y col Automation and Orchestration with Docker and Contai-ners A Comprehensive Overview of the Docker and Container Ecosystem3 The New Stack 2016
48
- Resumen
- Summary
- Iacutendice de figuras
- Introduccioacuten y objetivos
-
- Contexto
- Objetivos
- Estructura del documento
-
- Cloud Computing
- Nuevas cargas de trabajo
- Gestioacuten de recursos Planificadores
-
- Sistemas distribuidos
-
- Clasificacioacuten
-
- Herramientas
-
- DCOS
-
- Apache Mesos
- Ejemplos de uso
-
- Nomad
-
- Protocolo de consenso Raft
- Protocolo gossip SWIM
- Planificacioacuten
-
- Casos de uso y despliegue
-
- Aplicacioacuten Web
-
- DCOS
- Nomad
-
- Servicio de integracioacuten continua
-
- DevOps
- Integracioacuten Continua
- Jenkins con Nomad
- Jenkins con DCOS
-
- Escalando la infraestructura
-
- Disentildeo
- Implementacioacuten
-
- Resultados y conclusiones
-
- Comparacioacuten
- Conclusiones
- Objetivos conseguidos
- Liacuteneas de investigacioacuten
-
Herramientas de descubrimiento de servicios que permita la comunicacioacutenentre tareas distribuidas
Planificadores Encargados de distribuir las tareas y procesos en las dife-rentes maacutequinas asignaacutendole parte de su capacidad
Los planificadores del ingleacutes cluster schedulers son un componente funda-mental por lo que vamos a entrar un poco maacutes en detalle en ellos
Planificadores (Cluster Schedulers)
Es el software encargado de monitorizar los recursos usados por cada maacute-quina perteneciente a un cluster y distribuir la carga de trabajo entre ellas deacuerdo a un poliacutetica o reglas
Este tipo de herramientas comparten cierta terminologiacutea que es relevantedefinir
Tarea Unidad de trabajo computacional comprendida por una secuenciade instrucciones datos de entrada y recursos asociados Por ejemplo laejecucioacuten de un comando o el arranque de una base de datos
Nodo Cualquier maacutequina integrante de un cluster En una arquitecturamaestro-esclavo se definen dos roles
bull Cliente Agente Esclavo Aquellos ordenadores que se encargan deejecutar las tareas
bull Maestro Servidor Su objetivo es mantener el estado del cluster ygestionar sus recursos
411 Clasificacioacuten
A lo largo de los uacuteltimos antildeos se han desarrollado diferentes tipos de plani-ficadores[2]
Monoliacutetico
Un solo planificador que se encarga de distribuir todas las tareas entran-tes La mayoriacutea de los planificadores en computacioacuten de alto rendimiento asiacutecomo Borg desarrollado por Google son de este tipo En la figura 3 se pue-de observar de forma graacutefica el procedimiento siendo las cajas grises maacutequinaspertenecientes al cluster y los ciacuterculos las tareas a asignar
10
Figura 3 Planificador monoliacuteticoFuente httpswwwclcamacuk
Planificacioacuten de dos niveles
La mayoriacutea de los clusters ejecutan aplicaciones con distintas necesidadesdesde procesos casi instantaacuteneos hasta servicios persistenteslo que implica dis-tintas necesidades de recursos
Por ello la planificacioacuten a dos niveles distingue dos funciones la gestioacutende recursos (gestor) y la disposicioacuten de las tareas (planificador) Cada serviciotiene su propio planificador de tal manera que el gestor les ldquoofertardquo recursosde acuerdo a una poliacutetica y los planificadores se encargan de escoger la maacutesadecuada Esto permite que el proceso de distribucioacuten sea maacutes acorde con lasnecesidades de los diferentes servicios Apache Mesos que detallaremos maacutesadelante sigue este esquema
Como desventaja cabriacutea sentildealar que esta programacioacuten implica que los pla-nificadores pierden la vista general de la infraestructura y las tareas soacutelo puedenejecutarse con los recursos que les son ofrecidos lo que dificulta la implementa-cioacuten de prioridades de ejecucioacuten de tareas entre otras
Figura 4 Planificador de dos niveles
11
Planificacioacuten de estado compartido
Muacuteltiples reacuteplicas del estado del cluster se actualizan independientementepara cada planificador como se observa en la figura 5 cuando sucede un cambiode forma local el planificador se encarga de informar al resto
Ejemplo de este tipo son Omega la evolucioacuten de Borg por parte de GoogleMicrosoft Apollo y Nomad que usaremos para los casos de uso
De entre las desventajas se puede destacar el hecho de que en general losnodos trabajan con informacioacuten desactualizada lo que conlleva una degradacioacutendel rendimiento en situaciones de alta contienda
Figura 5 Planificador de estado compartido
Planificacioacuten distribuida
En este caso no existe coordinacioacuten entre los distintos planificadores Cadauno de ellos funciona con su propia vista del cluster Las tareas pueden serorganizadas por cualquiera de ellos y desplegadas en cualquier parte del clusteren base a la aleatoriedad y multiplexacioacuten estadiacutestica de los flujos de trabajosin ninguacuten control central
Figura 6 Planificador distribuido
12
5 Herramientas
En la industria comienzan a aparecer soluciones software de coacutedigo abiertoque aglutinan los servicios necesarios para gestionar la infraestructura TI de ma-nera maacutes eficaz El objetivo es doble se busca facilitar la gestioacuten de los recursosde computacioacuten para organizaciones con instalaciones propias mediante su usocon un enfoque cloud esto es desplegar aplicaciones a traveacutes de un conjuntode ordenadores de forma transparente y sin tener en cuenta la infraestructurasubyacente o aprovechar el maacuteximo rendimiento de la infraestructura de losproveedores cloud puacuteblicos de forma que se tiene el maacuteximo control sobre eacutestapero no se depende de las soluciones propietarias permitiendo asiacute despliegueshiacutebridos
Entre estas herramientas se pueden destacar
OpenStack Proyecto desarrollado por la fundacioacuten del mismo nombre paraproporcionar servicios de infraestructuras (IaaS) basado en componentesque se comunican a traveacutes de APIs El componente Magnum incluye mo-tores de orquestacioacuten de contenedores
Kubernetes Sistema de orquestacioacuten de contenedores Docker creado por Goo-gle
CoreOs Sistema operativo basado en Linux disentildeado para despliegues distri-buidos sobre contenedores incluyendo mecanismos de descubrimiento deservicio y comparticioacuten de configuracioacuten
Docker Swarm Herramienta nativa de orquestacioacuten de contenedores Docker
YARN Entorno de gestioacuten de recursos y aplicaciones distribuidas de Hadoopuna libreriacutea software de procesamiento de grandes conjuntos de datos
Como podemos observar existe un gran rango de opciones para gestionar lainfraestructura desde un bajo nivel como puede ser OpenStack hasta Kuberne-tes o Docker Swarm que ofrecen exclusivamente orquestacioacuten de contenedores
En este trabajo se ha optado por Mesosphere DCOS y HashiCorp Nomadque se encuentran en el teacutermino medio su objetivo es proporcionar serviciosde plataforma que permitan la coexistencia dediferentes cargas de trabajo en elcluster
13
51 DCOS
DCOS es un proyecto de coacutedigo abierto7 creado y desarrollado por la empre-sa Mesosphere Se describe como un sistema operativo distribuido que abstraelos recursos de un cluster (capacidad de procesamiento memoria) permite lagestioacuten de muacuteltiples ordenadores de forma transparente y simplifica la instala-cioacuten de aplicaciones distribuidas
Su arquitectura se puede comparar a la de Linux en teacuterminos de nuacutecleo(kernel) y espacio de usuario El primero consta de recursos protegidos a losque no puede acceder el usuario e involucra operaciones de bajo nivel comoasignacioacuten de recursos o aislamiento de procesos En el espacio de usuario seejecutan las aplicaciones y servicios de maacutes alto nivel
Siguiendo con este siacutemil el nuacutecleo de DCOS estaacute basado en Apache Mesosque se explicaraacute en un apartado posterior y el espacio de usuario que estaacute com-prendido por los componentes del sistema esto es las diferentes herramientasque en conjunto conforman DCOS y los servicios encargados de planificar yejecutar las aplicaciones y tareas del usuario
Figura 7 Arquitectura DCOSFuente httpsdcosio
De entre los componentes que conforman DCOS destacan
Admin Router Balanceador de carga central basado en NGINX que dis-pone un proxy entre todos los servicios en el puerto 80 permitiendo sugestioacuten mediante la interfaz graacutefica Ademaacutes se encarga de la autenticacioacutenpara acceder al panel de administracioacuten
Cosmos Gestor de paquetes de las aplicaciones
Diagnostics Se ejecuta en todos los nodos y se encarga de monitorizar elestado de los daemons que sustentan DCOS
7Desde abril de 2016 httpsmesospherecomblog20160419open-source-dcos
14
Exhibitor Gestiona y automatiza el despliegue de ZooKeper la herra-mienta que provee de configuracioacuten centralizada y registro de nombres
Marathon Equivale al proceso init de los sistemas tipo Unix esto es elprimer proceso en ejecucioacuten tras la carga del kernel y que genera los demaacutesprocesos Se encarga de arrancar y monitorizar las aplicaciones y servicios
Mesos-DNS Servicio de DNS interno que define el dominio mesos pa-ra nodos y tareas en el cluster es decir permite resolver nombres conindependencia de la direccioacuten fiacutesica
Minuteman Balanceador de carga integrado a nivel TCPUDP disponiblepara las propias aplicaciones
Por otra parte se definen como servicios a las diferentes aplicaciones dis-tribuidas que DCOS permite instalar en el cluster y que pueden haber sidodesarrollados por la misma empresa Mesosphere o por terceros por ejemploApache Spark Jenkins o Apache Hadoop En la figura 8 se muestra un diagramade los servicios disponibles incluyendo algunos de las aplicaciones distribuidasque soporta DCOS
Figura 8 Servicios DCOSFuente httpsdcosio
511 Apache Mesos
El nuacutecleo de DCOS estaacute basado en Apache Mesos un proyecto de coacutedigoabierto creado por la Universidad de California Berkeley y desarrollado actual-mente por la fundacioacuten Apache Se trata de un administrador de clusters queabstrae los recursos y los dispone para diferentes aplicaciones y entornos de tra-bajo distribuidos (frameworks) mediante una interfaz comuacuten En el momento deredaccioacuten de este proyecto Apache Mesos soportaba una variedad de entornosque abarcaba desde Big Data (Apache Spark Hadoop) hasta bases de datos(Cassandra Hypertable)
15
Arquitectura
Mesos se basa en la asignacioacuten de dos roles diferentes a los nodos
Maestros (Masters) Se encargan de la gestioacuten y reparticioacuten de los recursospara los diferentes entornos de trabajo mediante ldquoofertas de recursosrdquo deacuerdo a los disponibles y a la poliacutetica de asignacioacuten (planificacioacuten en dosniveles)
Esclavos (Slaves) Ordenadores donde se ejecutaraacuten las aplicaciones y cu-yos recursos son ofertados por los maestros
En el caso de fallo del maestro las tareas pueden seguir ejecutaacutendose perono se podraacute asignar nuevos recursos ni tareas por ello pueden existir varios enel cluster para configuraciones de alta disponibilidad pero soacutelo uno orquesta alos esclavos
Para la eleccioacuten del master liacuteder Mesos usa Apache ZooKeeper un proyectode software desarrollado por la misma fundacioacuten cuyo objetivo es proveer deun servicio de configuracioacuten centralizado y registro de nombres8
Por otra parte los entornos de trabajo son los programas que deciden final-mente queacute recursos se van a usar y se encargan de que los esclavos ejecuten lastareas Eacutestos se ejecutan sobre Mesos y constan de dos componentes
Planificador (Scheduler) Optimiza y decide los recursos a utilizar de losofertados informando a los Masters
Procesador (Executor) Ejecuta las aplicaciones o servicios en los esclavos
El objetivo final es conseguir una interfaz liviana tolerante a fallos paracualquier tipo de entorno de trabajo de tal manera que en los esclavos del clusterpuedan ejecutarse simultaacuteneamente tareas con necesidades y duracioacuten diferentesPara ello se basa en dos conceptos asignacioacuten y aislamiento de recursos
Asignacioacuten de recursos
En el cluster pueden coexistir entornos de trabajo con tareas de larga dura-cioacuten y con gran consumo de recursos con tareas cortas que los ocupan y liberancon rapidez El maestro integra un moacutedulo de asignacioacuten de recursos (allocationmodule) que se encarga del algoritmo de distribucioacuten
En el momento de escribir este proyecto estaban desarrollados dos moacutedulosuno mediante el cual el usuario puede asignar prioridades y otro que implementa
8httpszookeeperapacheorg
16
el algoritmo Dominant Resource Fairness9 a grandes rasgos se determina entodos los esclavos la tarea en ejecucioacuten que necesita maacutes recursos y se calcula laproporcioacuten del recurso de mayor peso con respecto al total por ejemplo si unatarea ocupa 2 GB de memoria con respecto a 10 GB totales que tiene el clusterse le asigna un dominant share del 20 la tarea se asignaraacute al nodo con menordominant share
Aislamiento de recursos
Para conseguir que tareas de diferentes entornos de trabajo y con distin-ta naturaleza se ejecuten simultaacuteneamente en un mismo nodo Mesos usa loscontenedores Linux (descritos en la seccioacuten 3)
Funcionamiento
La figura 9 muestra el esquema de la arquitectura de Apache Mesos conalta disponibilidad (tres maestros) y con dos entornos de trabajo ejecutaacutendo-se Hadoop que permite el almacenamiento y procesamiento de gran cantidadde datos para proyectos de big data y un sistema que implementa la interfazsistema de paso de mensajes MPI
Como se puede observar el sistema ZooKeeper elige a un solo maestro comoliacuteder y eacuteste orquesta el cluster comunicando los esclavos con los planificadoresde los diferentes entornos de trabajo Tambieacuten se puede observar como las tareasde los distintos entornos estaacuten distribuidas entre los tres esclavos disponibles
Figura 9 Arquitectura de Apache MesosFuente httpsmesosapacheorg
El proceso de asignacioacuten se realiza como sigue en primer lugar un usuariosolicita la ejecucioacuten de una tarea mediante la interfaz de cada entorno de traba-jo (interfaz graacutefica API HTTP ) De forma paralela un esclavo informa almaestro de los recursos que tiene libres En consecuencia eacuteste se lo notifica almoacutedulo de asignacioacuten que en funcioacuten de su configuracioacuten decide cuaacutento ofertar
9httpspeopleeecsberkeleyedu~aligpapersdrfpdf
17
y a queacute entorno de trabajo y enviacutea la oferta a los planificadores Eacutestos respondenal maestro con queacute recursos ha decidido usar para cada tarea Finalmente lastareas son enviadas al esclavo seleccionado el cual asigna los recursos indicadosal procesador (executor) quien finalmente las ejecuta
Cabriacutea pensar que esta metodologiacutea puede conducir a situaciones en lasque un entorno podriacutea quedarse con tareas sin ejecutarse a la espera de unaoferta satisfactoria para ello Mesos implementa un sistema de filtros medianteel cual los entornos especifican los requisitos miacutenimos que debe cumplir unaoferta por ejemplo se puede especificar en queacute nodos debe desplegarse la tareaEste sistema estaacute disentildeado asiacute con el objetivo de mantener lo maacutes transparenteposible esta herramientas de forma que acepte entornos de trabajo de distintasnaturalezas
512 Ejemplos de uso
Grandes empresas estaacuten usando Apache Mesos con eficacia de acuerdo a susnecesidades e infraestructuras Caben destacar
Ebay En el modelo de implementacioacuten continua en esta empresa10 cadadesarrollador cuenta con su propia instancia que se ejecuta en una maacutequinavirtual dedicada lo que ha conllevado un uso de los recursos poco eficiente Enuna prueba de concepto consiguieron realizar una herramienta de integracioacutencontinua distribuida basada en un cluster con Apache mesos y con el entornoMarathon y Jenkins
Apple Anuncioacute que el motor de su famosa herramienta de asistencia per-sonal para iPhones Siri estaacute desplegada sobre Apache Mesos11 Para ello handesarrollado su propio entorno para facilitar a los ingenieros a desplegar los ser-vicios que la herramienta necesita para resolver las peticiones de los usuarios
Twitter Desarrolloacute su propio entorno denominado Aurora y actualmentegestionan sus recursos y miden el coste de las tareas que los empleados usancon el objetivo de que sean conscientes del gasto que puede suponer un usoinadecuado de la infraestructura12
10httpwwwebaytechblogcom20140404delivering-ebays-ci-solution-with-apache-mesos-part-i11httpwwwbusinessinsidercomapple-siri-uses-apache-mesos-2015-812httpswwwlinuxcomNEWS4-UNIQUE-WAYS-UBER-TWITTER-PAYPAL-AND-HUBSPOT-USE-APACHE-MESOS
18
52 Nomad
Herramienta de coacutedigo abierto de gestioacuten de clusters creada y desarrolladapor Hashicorp13 que permite el despliegue de aplicaciones y procesos de formadistribuida
Las principales diferencias con Apache Mesos a grandes rasgos son
Arquitectura maacutes ligera Nomad soacutelo requiere de un fichero para funcionarejecutaacutendolo con las correspondientes configuraciones en todos los nodosrealiza las funciones de gestioacuten del cluster eleccioacuten de liacuteder planificacioacutende recursos y ejecucioacuten de las tareas
Centro de datos y regiones muacuteltiples Su arquitectura estaacute orientada afacilitar la gestioacuten de diferentes centros de datos geograacuteficamente distri-buidos
Entorno de ejecucioacuten Las tareas se definen y son interpretadas mediantecontroladores integrados en Nomad que se valen de los recursos y herra-mientas de los nodos clientes para ejecutarlas Esta integracioacuten dificultael desarrollo de controladores por parte de terceros a diferencia de Mesosque delega dicha responsabilidad en los entornos de trabajo externos alproyecto
Usa un planificador de estado compartido con respecto a la planificacioacutenen dos niveles de Mesos
Antes de entrar en maacutes detalle en la arquitectura es importante definir lossiguientes teacuterminos
Controlador (Driver) Software que se encarga de interpretar las definicionesde las tareas y ejecutarlas semejante a los procesadores de los entornosde trabajo de Mesos A la hora de redactar este proyecto Nomad contabacon controladores para contenedores Docker virtualizacioacuten de maacutequinasmediante el emulador QEMU aplicaciones java y archivos binarios
Grupo de trabajo (Task Group) Conjunto de tareas que se ejecutan en elmismo nodo cliente
Trabajo (Job) Conjunto loacutegico de tareas y grupos de trabajo que se despliegana la vez
Asignacioacuten (Allocation) Relacioacuten entre un grupo de trabajo y el cliente don-de se ejecuta
Evaluacioacuten (Evaluation) Proceso mediante el cual Nomad planifica y ges-tiona el registro o actualizaciones de los trabajos
13httpswwwhashicorpcom
19
Nomad sigue una arquitectura maestro-esclavo similar a la de Apache Mesosmuacuteltiples servidores acuerdan entre siacute un liacuteder que gestiona la planificacioacuten detareas en los clientes que soacutelo conocen sus asignaciones y las ejecutan
Todos los servidores participan paralelamente en tareas de planificacioacuten derecursos y asignacioacuten de tareas y ademaacutes entre ellos eligen un liacuteder que seencarga de la coordinacioacuten de la suscripcioacuten de los clientes al cluster y de lagestioacuten de las peticiones
Los clientes estaacuten configurados para comunicarse con el servidor usando lla-madas a procedimiento remoto (RPC por sus siglas en ingleacutes) que permite unordenador ejecutar coacutedigo en otra maacutequina Mediante esta tecnologiacutea los nodosclientes avisan de su estado e informa de sus asignaciones recursos y controla-dores disponibles
Existe la posibilidad de gestionar varios centros de datos agrupados en regio-nes eacutestas son independientes pero permite definir tareas o comprobar el estadode todas ellas desde cualquier punto A continuacioacuten se muestra una figura dela arquitectura a alto nivel de esta configuracioacuten
Figura 10 Arquitectura multi-regioacuten en NomadFuente httpswwwnomadprojectio
La herramienta se sustenta sobre tres protocolos fundamentales un protocolode consenso entre los servidores para compartir informacioacuten sobre su estado yel liacuteder un protocolo Gossip para la gestioacuten entre regiones y el planificador detareas
521 Protocolo de consenso Raft
El objetivo es obtener consistencia en un conjunto de nodos que comparteninformacioacuten es decir si un cliente realiza un cambio que todos los nodos veanla misma informacioacuten a la vez y ademaacutes sea tolerante a fallos Para ello se basaen el algoritmo Raft[13] que se detalla brevemente a continuacioacuten
20
Los nodos participantes en el algoritmo pueden estar en tres estados
Liacuteder (Leader) Todos los cambios que realicen en el cluster pasan por eacutel pri-mero
Seguidor (Follower) Nodo pasivo cuya responsabilidad es responder a laspeticiones del nodo liacuteder
Candidato (Candidate) Maacutequina que no ha encontrado liacuteder y solicita sueleccioacuten
Supongamos que tenemos cinco equipos que acaban de arrancar el protocoloEn la figura 11 se observan los nodos y sus respectivos registros a la derecha
Figura 11 Equipos sin consenso ejecutando el protocolo RAFTFuente httpsgithubcomongardieraftscope
Al comenzar todos los nodos son seguidores esperando recibir comunicacioacutende un nodo que actuacutee como liacuteder Cada nodo tiene un tiempo de espera aleatoriodespueacutes del cual si no es informado por un liacuteder pasa a estado candidato y pideel ldquovotordquo al resto de los participantes El algoritmo divide el tiempo en plazos uncandidato pasa a liacuteder si recibe la mayoriacutea de los votos en un plazo determinadoSe define mayoriacutea o cuoacuterum (quorum) comolceil
N2rceil
+ 1 (1)
donde N representa el nuacutemero de nodos
Para el ejemplo propuesto de 5 equipos se requieren de 3 votos Soacutelo losnodos que se encuentren en estado seguidor pueden votar una uacutenica vez a laprimera solicitud que reciba dentro de un plazo
Supoacutengase que el nodo denotado con S1 ha cumplido su tiempo de espera yrealiza la peticioacuten de voto (figura 12) A partir de este momento se pueden dartres casos
La maacutequina gana la eleccioacuten y pasa a ser liacuteder informando al resto
Otro servidor se establece como liacuteder en el mismo momento
Varios nodos pasan a ser candidatos por lo que ninguno consigue los votos
21
Figura 12 Un equipo pasa a estado candidato (RAFT)
Si un candidato recibe un aviso de un liacuteder en el mismo plazo el primeropasa a ser seguidor y se acaba la eleccioacuten de liacuteder
Por otro lado si un equipo candidato no recibe los votos en el plazo y agotasu tiempo de espera avanza al siguiente plazo y repite el proceso de votacioacutenLa tercera posibilidad puede conllevar a un estado indefinido ya que varioscandidatos pueden agotar su tiempo de espera al mismo tiempo y repartir losvotos Para solventarlo el algoritmo establece tiempos de espera aleatorios paralos candidatos
Siguiendo con el ejemplo propuesto el servidor S1 pasa a ser el liacuteder Cadacierto tiempo eacuteste debe realizar avisos a los nodos seguidores para no agotar sutiempo de espera
En este momento el cluster de servidores estaacute en ldquoconsensordquo y la informacioacutenen todos los nodos estaacute actualizada Un cambio en la informacioacuten inicia unproceso de replicacioacuten el liacuteder registra el cambio lo pasa al resto de nodos yuna vez eacutestos responden el cambio se hace efectivo
Supoacutengase que se realiza un cambio en los datos en la figura 13 en la partederecha se observa el cambio en el registro del servidor S1 que informa a losnodos seguidores En consecuencia los nodos registran el cambio y responden aS1
Figura 13 Cambio en un registro (RAFT)
Una vez el cuoacuterum (en el ejemplo tres equipos) informa al liacuteder de que
22
ha registrado el cambio el liacuteder lo hace efectivo en su sistema y notifica a losnodos que hacen lo mismo En la figura 14 el enviacuteo todaviacutea no ha llegado ala maacutequina S3 y se observa que no ha hecho efectivo el cambio (en el registroaparece punteado)
Figura 14 Aprobacioacuten del resto de equipos (RAFT)
Este protocolo funcionaraacute correctamente mientras exista un nuacutemero de nodosen funcionamiento igual o superior al cuoacuterum en el ejemplo propuesto elcuoacuterum es tres por lo que el sistema puede tolerar la caiacuteda de dos de los equipos
522 Protocolo gossip SWIM
Nomad permite la gestioacuten simultaacutenea de varios centros de datos reparti-dos en regiones geograacuteficamente separadas requiriendo de un protocolo ligeroque mantenga a los miembros actualizados sobre los participantes del conjun-to Para ello usa una ligera variante del protocolo SWIM[3] (Scalable Weakly-consistent Infection-style Process Group Membership Protocol) desarrollada porHashiCorp Estaacute clasificado como un protocolo de tipo gossip que debe su nom-bre a la semejanza con coacutemo se distribuye un rumor en una red social
SWIM se sustenta en dos caracteriacutesticas fundamentales la deteccioacuten de fallosy la distribucioacuten de la informacioacuten relativa a los miembros A continuacioacuten sedetalla el funcionamiento de ambos componentes
Deteccioacuten de fallos
Este componente tiene dos paraacutemetros el periodo de protocolo T y el nuacutemerode subgrupos de deteccioacuten de fallos k en los que se dividen los nodos Paracomprobar la comunicacioacuten entre dos maacutequinas usa la utilidad ping basadaen el protocolo ICMP La deteccioacuten de caiacuteda de un servidor sigue el siguientealgoritmo
Durante el periodo T cada miembro Mi de un subgrupo elige otro al azar Mjdel mismo subgrupo y le enviacutea un mensaje ping para comprobar su estado Enel caso de que se cumpla un tiempo de espera determinado por una estimacioacuten
23
del tiempo de ida y vuelta (RTT por sus siglas en ingleacutes) de la red y no hayarespuesta Mi le vuelve a enviar un mensaje ping indirectamente a traveacutes deun nuacutemero k de miembros escogidos aleatoriamente De no recibir ninguna res-puesta Mi establece que Mj ha sufrido un fallo y lo etiqueta como ldquosospechosordquoinformando al componente de distribucioacuten
Figura 15 Diagrama de tiempo del protocolo SWIMFuente httpswwwcscornelledu
Componente de distribucioacuten
Se encarga de informar de cualquier cambio en los miembros a todo el con-junto Los eventos de nodo caiacutedo y la unioacuten o disociacioacuten de un miembro setransmiten a todos los servidores para que actualicen sus lista Para distribuirla informacioacuten a todos los nodos se podriacutea usar el meacutetodo de multicast perosuele estar deshabilitado Por ello se utiliza una teacutecnica de transmisioacuten denomi-nada Piggybacking mediante la cual se adjunta a los propios mensajes PINGy ACK del algoritmo la informacioacuten a distribuir reduciendo asiacute la congestioacutenen la red
523 Planificacioacuten
Proceso encargado de distribuir las tareas entre los nodos clientes de acuerdoa su estado
El planificador de Nomad estaacute basado en las publicaciones de Google sobresus herramientas de gestioacuten de clusters Borg y Omega14 y entiende los trabajosdescritos por el usuario como un estado deseado es decir su despliegue en unamaacutequina cliente de forma correcta y los clientes como el estado actual esto eslo que se encuentra en ejecucioacuten El registro actualizacioacuten o cancelacioacuten de un
14httpresearchgooglecompubspub43438html
24
trabajo asiacute como el fallo de un nodo cliente implican un cambio de estado atramitar por el sistema lo que se define como evaluacioacuten (evaluation) Esto uacutelti-mo supone comparar el estado actual (clientes) con el estado deseado (conjuntode trabajos registrados) y enviarlos a los planificadores correspondientes que seencargaraacuten de asignar las tareas a los nodos clientes
Figura 16 Procedimiento de asignacioacuten en NomadFuente httpswwwnomadprojectio
En la figura 16 se observa el flujo de trabajo en el que las distintas evalua-ciones se encolan en el evaluation broker que se ejecuta en el servidor liacuteder ygestiona las evaluaciones pendientes asignaacutendoles prioridades
A continuacioacuten los nodos servidores ejecutan los scheduling workers queprocesan las evaluaciones llamando a los distintos planificadores que generanun plan de asignacioacuten esto es un conjunto de relaciones entre las tareas y losnodos clientes donde se ejecutaraacuten Este proceso se divide en dos fases primerose descartan aquellos clientes que no cumplan los requisitos y posteriormentese asigna una calificacioacuten al resto Se selecciona el nodo con mayor puntuacioacuteny se encola el plan en el gestor que se ejecuta en el servidor liacuteder Existen tresplanificadores de acuerdo al tipo de trabajo
Service Incluye aquellos trabajos que estaacuten destinados a ejecutarse en un pe-riacuteodo largo de tiempo Para realizar las asignaciones el planificador evaluacuteala mayor parte de los nodos y usa una versioacuten del algoritmo Best fit in-fluenciada por el trabajo de Google en su herramienta Borg Se trata deun algoritmo de planificacioacuten que sacrifica tiempo a cambio de maximizarel rendimiento de los clientes asignando la tarea a la maacutequina que tengala mayor carga de trabajo con el objetivo de reducir equipos en funciona-
25
miento
Batch Tareas que incluyen listas de comandos en general de menor duracioacuteny que no requieren interaccioacuten con el usuario Se vale del algoritmo deSparrow desarrollado por la universidad de Berkeley15 para limitar losnodos clientes a evaluar
System Trabajos destinados a ejecutarse en todos los nodos incluso los que seunen al cluster posteriormente
Core Mantenimiento interno de Nomad
Una vez se ha realizado el proceso de planificacioacuten el nodo liacuteder lo registra enla cola de planes (plan queue) que se encarga de asignarles prioridad y manejarcondiciones de carrera es decir que no accedan a los recursos de los clientes sincontrol y evitar que eacutestos superen su capacidad
La maacutequina liacuteder del conjunto puede de este modo aceptar una asignacioacuteny ser ejecutada por los clientes o por el contrario rechazaacutersela al planificadorlo que implicariacutea realizar un plan parcial o totalmente nuevo
Finalmente el estado de las evaluaciones se actualizan y los clientes soninformados de las asignaciones ejecutaacutendose las tareas
15httppeopleeecsberkeleyedu~keopublicationssosp13-final17pdf
26
6 Casos de uso y despliegue
Con el objetivo de mostrar las posibles utilidades que este tipo de sistemaspueden tener en las infraestructuras TI actuales se han desplegado las dos he-rramientas en la nube Microsoft Azure usando su servicio cloud de instancias demaacutequinas virtuales Linux para simular un conjunto de ordenadores conectadosentre siacute por una red LAN Sobre ellas se ha implementado dos casos de usouna aplicacioacuten web con una arquitectura con cierta orientacioacuten a microserviciosy un sistema de integracioacuten continua
El coacutedigo y todos los ficheros de configuracioacuten se pueden encontrar en elrepositorio del proyecto en GitHub16
61 Aplicacioacuten Web
Se busca simular el proceso de adaptacioacuten de una solucioacuten web para su des-pliegue en un sistema distribuido con las herramientas anteriormente descritascon el objetivo de aumentar tanto su escalabilidad como disponibilidad medianteredundancia
Se ha partido de una aplicacioacuten ya existente17 un servicio de almacenamien-to y reproduccioacuten de canciones A grandes rasgos este servicio permite crearusuarios subir canciones con sus respectivas portadas tener playlists propias yescuchar las canciones a traveacutes de un navegador web
La solucioacuten estaacute dividida en 4 partes (figura 17)
Una vista web con la loacutegica
Un almacenamiento conectado en red (NAS por sus siglas en ingleacutes)
Una API REST para gestionar las peticiones al almacenamiento
Base de datos NoSQL basada en MongoDB
La nueva tendencia de los proyectos web es su implementacioacuten en contene-dores Docker ya que facilitan su portabilidad y ofrecen un procedimiento dedespliegue raacutepido sobre todo a la hora de desarrollar y realizar pruebas en en-tornos de produccioacuten simulados Por ello en este caso se va a hacer uso de los
16httpsgithubcomAntonioAlfrzCloud-Orchestrators17httpsgithubcomsonsoleslpCDPSfy
27
motores de orquestacioacuten de contenedores de ambas herramientas Marathon enDCOS y el controlador Docker en el caso de Nomad
Figura 17 Arquitectura aplicacioacuten web
A continuacioacuten vamos detallar el despliegue en ambas herramientas de es-ta solucioacuten y observar tanto queacute dificultades se encuentran como que ventajasofrecen El objetivo final es adaptar el proyecto modificaacutendolo lo menos posiblecon objeto de analizar la capacidad de estas herramientas para desplegar cual-quier aplicacioacuten sin que eso conlleve la modificacioacuten de la arquitectura de eacutestaes decir que no sea dependiente del entorno
611 DCOS
Se ha descrito DCOS como una herramienta que se despliega sobre un con-junto de ordenadores y que permite instalar gestionar el despliegue de sistemasdistribuidos
Microsoft Azure cuenta con una plantilla para desplegar en su servicio cloudun cluster de maacutequinas virtuales con DCOS ya instalado que cuenta con
Maacutequinas maestras (1 3 o 5 a seleccionar por el usuario) configuradascomo un conjunto de disponibilidad esto eso Azure da ciertas garantiacuteasde que al menos una maacutequina estaraacute en funcionamiento
Maacutequinas agentes Por motivos de seguridad se distinguen dos roles
bull Nodos privados solo accesibles desde la red interna y configuradoscomo un conjunto de escala un recurso de Azure para gestionar ydesplegar maacutequinas con configuraciones ideacutenticas para permitir unraacutepido escalado
bull Un equipo conectado accesible desde Internet a travntildees de un balan-ceador de carga puacuteblico y situado en una subred externa
28
Dos balanceadores de carga
bull La interfaz puacuteblica del cluster que se conecta con el cliente puacuteblicobull Acceso a los equipos maestros para el administrador que soacutelo permiteconexioacuten mediante SSH y credenciales
Almacenamiento para todas las maacutequinas
Configuraciones necesarias de red y seguridad
En la figura 18 se observa un diagrama de la infraestructura
Figura 18 Infraestructura en Azure
El primer obstaacuteculo es la persistencia de estado de la aplicacioacuten que seconsigue gracias a una base de datos no relacional basada en MongoDB asiacutecomo el almacenamiento de las canciones Para implementarla tenemos variasposibilidades
Montar un sistema externo de almacenamiento conectado en red en todoslos agentes donde se ejecuten las tareas de esta manera si una tarea pasade un nodo a otro por cualquier motivo puede tener acceso a los mismosficheros (opcioacuten del caso de uso original)
Implementar un sistema de ficheros distribuidos en los agentes
Usar los servicios de almacenamiento de las nubes puacuteblicas
Aprovechar el sistema de voluacutemenes persistentes de Apache Mesos Eacutestepermite reservar recursos de un agente de forma que al arrancar una tarease crea un volumen independiente del ciclo de vida de eacutesta con ello esosrecursos donde se ha almacenado la informacioacuten pueden volver a ofrecerseal mismo entorno de tal manera que otra tarea pueda acceder a ella
DCOS aprovecha este sistema de voluacutemenes persistentes y permite instalarbases de datos distribuidas como ArangoDB o Apache Cassandra sin embargoesto implicariacutea modificar todo el coacutedigo referente al modelo de la base de datos
29
Por motivos de eficiencia y latencia asiacute como de una mayor gobernabilidadde los datos la mejor opcioacuten es usar el recurso de voluacutemenes persistentes queofrece Apache Mesos ya que de esta manera se gestionariacutea la aplicacioacuten completamediante una uacutenica herramienta Sin embargo esto implica que la informacioacutense encuentra exclusivamente en el agente donde se haya ejecutado la tarea y porlo tanto se sigue requiriendo de software externo para distribuir la informacioacutenpara que se accesible para todos los agentes A la hora de realizar este proyectose encontraba en desarrollo Flocker una solucioacuten desarrollada por ClusterHQque permite compartir los voluacutemenes de Docker a traveacutes de un cluster quesi bien es compatible con el planificador de Mesos el proyecto se encontrabatodaviacutea en fases tempranas de desarrollo y los sistemas de almacenamiento quesoporta quedaban fuera del aacutembito de este trabajo
Por todo ello dado que las maacutequinas se han desplegado en la nube puacuteblicade Azure se decidioacute usar su servicio de almacenamiento de objetos para lascanciones y otra maacutequina para desplegar MongoDB y asiacute mantener el modelode datos original de la aplicacioacuten La diferencia del almacenamiento de obje-tos con respecto a nivel de fichero es que el primero no tiene jerarquiacutea paraorganizar los archivos eacutestos se guardan como objetos (con sus metadatos) enun mismo espacio soacutelo diferenciaacutendose por un identificador uacutenico esto implicaentre otras cosas que se puede acceder a un fichero dado uacutenicamente su IDindependientemente de la localizacioacuten fiacutesica de eacuteste facilitando pues la gestioacuteny el desarrollo
El coacutedigo del proyecto se ha modificado en los siguientes apartados
Las direcciones de la base de datos y los balanceadores de carga asiacute comosus puertos estaban originalmente fijos Se han configurado como variablesde entorno para facilitar el descubrimiento del servicio y hacer transpa-rente la aplicacioacuten al entorno de despliegue
La API REST se ha adaptado al almacenamiento en Azure en vez de enlocal
Estas modificaciones no suponen un cambio sustancial pero permiten separala persistencia de las tareas ejecutadas por DCOS lo que facilita en granmedida su ejecucioacuten al ser totalmente sin estado y ademaacutes implican tenerlos datos bajo un mayor control
Para la orquestacioacuten de contenedores se va a usar el entorno Marathondesarrollado tambieacuten por Mesosphere Eacuteste se puede usar a traveacutes de una interfazgraacutefica la interfaz de liacutenea de comandos (en lo que sigue CLI por sus siglas eningleacutes) de DCOS o con su API HTTP
Primero se han publicado la imaacutegenes de los contenedores que encapsulanla interfaz web y la api de la aplicacioacuten en el repositorio puacuteblico DockerHub
Los despliegues en este entorno se describen mediante ficheros JSON en losque se detalla entre otras opciones la imagen del contenedor los puertos a usar
30
los recursos que debe ocupar en un nodo o las instrucciones de monitorizacioacuten
Para el servicio de descubrimiento DCOS ofrece la posibilidad de asignardirecciones IP virtuales (VIP por sus siglas en ingleacutes) a tareas que se compartenen todos los nodos DCOS lleva integrado un balanceador de carga a nivel TCP(el componente denominado Minuteman) que balancea entre las direccionesvirtuales de las tareas y todas las instancias de eacutestas a lo largo del cluster Estoes necesario por dos motivos equilibrar la carga de los equipos con el fin deevitar un punto de uacutenico fallo mediante redundancia y evitar la contienda dedirecciones al ejecutar las tareas en puertos aleatorios
Este balanceador de carga estaacute basado en el trabajo de Michael Mitzenma-cher The Power of Two Choices in Randomized Load Balancing18 A grandesrasgos el algoritmo mantiene una media moacutevil exponencial de latencias paracada destino (backend) ademaacutes de las caiacutedas consecutivas Si un destino noresponde a una negociacioacuten en tres pasos (three way handshake) de forma con-secutiva en un periodo inferior a 5 ms se considera caiacutedo El algoritmo iterasobre los destinos disponibles en base a su histoacuterico de fallos y escoge dos deforma aleatoria de los cuales coge el de mejor meacutetrica
Las direcciones virtuales soacutelo se pueden resolver dentro del cluster porello para implementar la interfaz puacuteblica de la aplicacioacuten esto es el balancea-dor de carga de la interfaz web usaremos un paquete de DCOS denominadomarathon-lb un balanceador basado en HAProxy y adaptado por MesosphereEn este caso equilibra la carga de todas instancias de las tareas ejecutadas porel entorno Marathon por sus etiquetas y permite ademaacutes definir como puntode entrada muacuteltiples hosts virtuales definidos por sus nombres completos dedominio (FQDN por sus siglas en ingleacutes) en nuestro caso la interfaz puacuteblicadel balanceador de Azure para los agentes
Por motivos de seguridad todas las tareas se ejecutan en los agentes privadoses decir los que son exclusivamente accesibles desde la red interna Por su partemarathon-lb se ejecuta en el agente puacuteblico que cuenta con IP puacuteblica y lospuertos 80 (HTTP) y 8080 abiertos de forma que la aplicacioacuten sea accesibledesde Internet Esto es posible debido a que Apache Mesos permite reservarrecursos mediante roles asignados a nodos para un uso especiacutefico De esta formala arquitectura vista desde la aplicacioacuten quedariacutea como en la figura 19
18httpswwweecsharvardedu~michaelmpostscriptstpds2001pdf
31
Figura 19 Arquitectura de la aplicacioacuten web en DCOS
Ejecucioacuten
A la hora de desplegar la aplicacioacuten DCOS puede gestionarse medianteuna interfaz graacutefica o una interfaz de liacutenea de comandos La primera se accedea traveacutes de un navegador web en el puerto 80 (HTTP) y permite instalar losentornos disponibles observar el estado de los nodos y las tareas que se estaacutenejecutando y los ficheros de registros que eacutestas generan
La CLI permite el control desde un nodo o una maacutequina remota (suponiendoque los maestros tienen IP puacuteblica y el puerto 80 abierto) ya que DCOS tieneun sistema de autorizacioacuten que permite tener una interfaz puacuteblica con ciertasgarantiacuteas de seguridad
Por su parte cada entorno de trabajo puede ser controlado por la CLI peroademaacutes cuenta con sus propias interfaces Marathon expone una API HTTPen el puerto 8080 de la direccioacuten puacuteblica de los maestros del cluster asiacute comootra interfaz graacutefica Para desplegar un contenedor se podriacutea usar la CLI
$ dcos marathon app add lt f i l e j songt
O la API HTTP
$ cu r l minusX POST http lt ip_maestro gt8080v2apps minusd ltf i l e jsongt minusH Contentminustype app l i c a t i o n j son
32
612 Nomad
La arquitectura de Nomad es maacutes sencilla ya que solo requiere de un ficheroejecutable en todos los nodos para funcionar Si DCOS es la base de instala-cioacuten de entornos de terceros Nomad integra todas las funcionalidades baacutesicasesto es gestor de recursos planificador y ejecutor en los nodos cliente Estaherramienta cuenta con un menor tiempo de desarrollo y en el momento deescribir este documento cuenta exclusivamente con los siguientes controladoresen comparacioacuten con los entornos de DCOS
Motor Docker es decir funcioacuten de orquestacioacuten de contenedores
Ejecucioacuten de archivos binarios como comandos de Shell
Ejecucioacuten de aplicaciones Java
Virtualizacioacuten de maacutequinas mediante tecnologiacutea QEMU
Todos ellos necesitan que la tecnologiacutea subyacente esteacute instalada en las maacute-quinas clientes (Docker Java QEMU) Actualmente no permite el registro decontroladores por parte de terceros aunque estaacute planificado en un futuro ofreceruna interfaz para su desarrollo
Nomad no cuenta con el servicio de descubrimiento sin embargo puede inte-grarse con la herramienta Consul desarrollada por la misma empresa Por otrolado para el balanceo de carga usaremos un contenedor Docker con HAProxyuna herramienta de coacutedigo abierto que ofrece tanto servicios de proxy como debalanceador y cuyos ficheros de configuracioacuten completaremos con el proyectoConsul Template19
Consul
Consul sigue la misma arquitectura que Nomad es decir un nodo servidorque orquesta un conjunto de maacutequinas clientes y permite a los procesos que seejecutan en los equipos definirlos como servicios ofreciendo diversas caracteriacutes-ticas entorno a estos de los cuales vamos a usar dos
Descubrimiento de servicio Las maacutequinas clientes publican en el cataacutelogode servicios las tareas en ejecucioacuten y Consul les asigna nombres de dominioaccesibles por todos los miembros del cluster a traveacutes de la interfaz DNSincluida en esta herramientaConsul se integra con Nomad de forma que todas las tareas que se ejecu-ten en la segunda son automaacuteticamente publicados como servicios de laprimera de esta manera no hace falta conocer la direccioacuten de la maacutequinacliente donde se esteacute ejecutando el proceso ya que se puede acceder a eacutela traveacutes de su nombre de dominio de forma transparente Por ejemplo si
19[httpsgithubcomhashicorpconsul-template]
33
ejecutamos una tarea con ID web en el puerto 8080 se puede acceder aella en la direccioacuten webserviceconsul8080Para que las direcciones propias de Consul las resuelva su propio DNS y noel que esteacute asignado por defecto en la maacutequina usaremos la herramientadnsmasq20 que permite especificar la direccioacuten de un servidor DNS paraconsultas de direcciones especiacuteficas
Monitorizacioacuten Permite realizar comprobaciones del servicio y seguir su esta-do Aprovecharemos esta funcionalidad tanto para definir el propio procesode Nomad como servicio de Consul como las tareas desplegadas
HAProxy + Consul Template
HAProxy es una solucioacuten versaacutetil de coacutedigo abierto que ofrece solucionesde balanceo de carga y proxy Existen otras herramientas en el mercado comoNGINX o ldirectord sin embargo HAProxy suponiacutea una solucioacuten sencilla deconfigurar para mostrar el caso de uso
El uso de estas herramientas se debe a dos motivos para que no existacontienda con respecto a los puertos de los clientes usados por las tareas eacutestos sevan a asignar de forma dinaacutemica lo que en principio implicariacutea que la aplicacioacutendeberiacutea realizar consultas DNS de tipo SRV (que incluye puertos) a la interfazde Consul y balancear la carga entre tareas por redundancia y capacidad
Como la direccioacuten IP y puerto son variables cada vez que las tareas seactualicen o se reasignen es necesario volver a configurar HAProxy de formamanual Por ello HashiCorp ha desarrollado un programa denominado Con-sul Template que realiza peticiones sucesivas a la interfaz HTTP de Consul delas direcciones fiacutesicas de un servicio y reinicia automaacuteticamente el proceso deHAProxy Asiacute definiendo estas tareas como servicios Consul podremos tantomonitorizarlas como escalar las tareas dinaacutemicamente sin necesidad de cambiarel balanceador A partir del contenedor Docker oficial de HAProxy se ha desa-rrollado otro con la configuracioacuten baacutesica y con Consul Template para desplegarlocomo una tarea en Nomad
Despliegue
Se ha usado el mismo coacutedigo que en el apartado anterior con la persistenciaen el servicio de almacenamiento de Azure Desde la perspectiva del hardwarese implementaraacute la misma infraestructura que en el caso de DCOS (figura 18)estos es definiremos dos tipos de maacutequinas clientes un agente que se conectaraacutecon el balanceador de carga con nombre de dominio puacuteblico y donde se desple-garaacute el balanceador de carga de la vista web y agentes privados no accesiblesdesde fuera del cluster y donde se ejecutaraacuten el resto de tareas en la red inter-na La principal diferencia radica en las tareas que ejecutan HAproxy y ConsulTemplate que sustituye a las direcciones IP virtuales que ofrece DCOS
20httpwwwthekelleysorgukdnsmasqdochtml
34
Figura 20 Despliegue en Azure de Nomad+Consul
Cabe matizar que los balanceadores basados en HAProxy se implementanpor necesidad de la aplicacioacuten para el descubrimiento del servicio a diferenciade los de Azure que se implementan por motivos de seguridad y escalabilidaddel cluster en siacute
Configuracioacuten Nomad
Los ficheros de configuracioacuten de las maacutequinas maacutester y cliente son similaresy comparten la mayoriacutea de las opciones como por ejemplo el nombre del nodoo la interfaz de red donde escucha Nomad las peticiones Sus opciones son engeneral auto-explicativas sin embargo existen dos detalles que matizar
El proceso de Nomad escucha las peticiones tanto de los protocolos deconsenso como del usuario a traveacutes de una interfaz de red que se debeindicar en el fichero de configuracioacuten
En el caso de los clientes se deben indicar las direcciones de los servidoresdel cluster sin embargo se trata de un sistema dinaacutemico en el que losnodos pueden sufrir errores y cambiar de direccioacuten Por ello se ha definidoNomad como un servicio de Consul y asiacute poder definir la direccioacuten de losservidores como un nombre de dominio no por su direccioacuten fiacutesica que elservidor DNS de Consul se encargaraacute de resolver
Por defecto Nomad usa los siguientes puertos
API HTTP 4646 Peticiones HTTP y recepcioacuten de oacuterdenes mediante laliacutenea de comandos
RPC 4647 Protocolo de consenso entre los nodos del cluster
Serf 4648 Protocolo de gossip entre los servidores de los centros de datosgobernados por Nomad
35
Los dos uacuteltimos deben ser interfaces alcanzables por otros nodos sin embargo laAPI HTTP por motivos de seguridad deberiacutea ser local ya que en caso contrariocualquier persona con acceso a ella tiene el control sobre la herramienta Eacutestasolo deberiacutea estar accesible en un servidor o gestionarlo mediante una terminalSSH por ejemplo En este trabajo al ser una prueba de concepto se ha abiertoen todos los nodos
Trabajos de Nomad
Las tareas se detallan en ficheros con formato HashiCorp Configuration Lan-guage un derivado del formato JSON creado por la empresa que le da nombrecompatible con eacuteste y que permite comentarios
En estos ficheros se puede definir
La regioacuten y el centro de datos donde se ejecutaraacute (Nomad permite lagestioacuten de centros de datos geograacuteficamente distribuidos en regiones)
La poliacutetica de actualizacioacuten de la tarea
Grupo de tareas esto es que se ejecutaraacuten en el mismo nodo
El nuacutemero de grupos a ejecutarescalar asiacute como los liacutemite que debencumplir los nodos asignados
La poliacutetica de reinicio ante fallo o error
Tareas El controlador su configuracioacuten los paraacutemetros del servicio aso-ciado a registrar en Consul asiacute como los recursos que consume (puertosmemoria)
En nuestro caso usamos sobre todo el controlador Docker esto eso orques-tacioacuten de contenedores en los nodos clientes y tres de sus opciones
Imagen del contenedor Se han subido todas las imaacutegenes del proyecto a Doc-ker Hub donde por defecto se busca la imagen
Puertos Los puertos a usar por el contenedor que pueden ser estaacuteticos asigna-dos por el usuario o dinaacutemicos siendo Nomad el que se encarga de mapearun puerto libre del nodo cliente al expuesto por el contenedor
Servidores DNS Como usamos la interfaz DNS de Consul como descubri-miento de servicio se debe configurar el contenedor para que use cualquiernodo del cluster como servidor DNS
Configuracioacuten Consul
Al ser desarrolladas por la misma empresa los ficheros de configuracioacuten deConsul y Nomad comparten muchas opciones Consul tambieacuten acepta peticionesa traveacutes de una interfaz de red siendo los puertos usados por defecto
36
RPC 8300 8400 Maneja la peticiones del resto de nodos y usuarios
Serf 8301 8302 Protocolo gossip
HTTP API 8500
HTTPS API Desactivada por defecto
Interfaz DNS 8600
Se debe asignar a los protocolos internos del cluster esto es RPC y Serf unainterfaz alcanzable por los nodos y por el contrarioasignar a los dos uacuteltimos ala interfaz de loopback por motivos de seguridad
Cabe destacar que Consul tambieacuten cuenta con una interfaz graacutefica que per-mite ver el estado de los equipos y los servicios registrados y que se encuentra enel mismo puerto que la API HTTP en la direccioacuten httpIP_EQUIPO8500ui
Ejecucioacuten
Tanto Nomad como Consul requieren de la ejecucioacuten de un fichero en todoslos nodos integrantes del cluster Como prueba de concepto se ha decidido usardos servidores para ambos aunque cabe matizar que es un nuacutemero ineficienteya que la caiacuteda de uno de ellos supondriacutea la peacuterdida del cuoacuterum y por tantodel consenso del cluster
En primer lugar se arrancan los servidores que son los encargados de ejecu-tar el protocolo de consenso y gestionar el cluster y a continuacioacuten los clientesque no tienen praacutecticamente estado y dependen de los servidores
En el caso de Consul se debe indicar el directorio donde se guardan losficheros que describen los servicios asiacute como el archivo que especifica el resto delas opciones
1 Se inicia el primer servidor en uno de los equipos
$ consu l agent minuscon f i gminusd i r e t c consu l d s e r v i c e s minuscon f i gminus f i l e consu l_server j son
2 Los siguientes equipos deben unirse al anterior por lo que antildeadimos elargumento join con la direccioacuten del primer servidor Para el caso de otrosservidores
$ consu l agent minuscon f i gminusd i r e t c consu l d s e r v i c e s minuscon f i gminus f i l e consu l_server j son minus j o i n ltIP_servidor1gt
37
Una vez los servidores han alcanzado el consenso y elegido un liacuteder en losclientes
$ consu l agent minuscon f i gminusd i r e t c consu l d s e r v i c e s minuscon f i gminus f i l e c on su l_c l i en t j son minus j o i n ltIP_cualquierServ idorgt
El proceso para iniciar Nomad es igual y los comandos similares sin embargoya no es necesario indicar una direccioacuten IP fija en los equipos sino el nombre dedominio del servicio de Nomad registrado por Consul En el primer servidor
$ nomad agent minusc on f i g nomad_server j son
Y el resto de equipos (con su fichero de configuracioacuten correspondiente)$ nomad agent minusc on f i g nomad_server j son minus j o i n nomad s e r v i c e consu l
Por uacuteltimo para desplegar la aplicacioacuten web se han escrito tres ficherosque detallan las tareas de la interfaz web API y los balanceadores de cargaMediante la CLI
$ nomad run minusaddress=http lt ip_c lus te r gt4646 lt f i l e hclgt
O mediante la API HTTP de Nomad$ cu r l minusX POST minusd ltf i l e hclgthttp lt ip_c lus te r gt4646 jobltjob_namegt
Ansible
Como se puede comprobar con el aumento del nuacutemero de equipos pasa aser inviable manejar todos los nodos a traveacutes de terminal Ademaacutes como seha comentado con anterioridad Nomad requiere que en los nodos clientes es-teacuten instalados las herramientas que soporten las tareas por ejemplo el motorde Docker Por ello para facilitar tanto el arranque como la instalacioacuten de lasdependencias vamos a usar Ansible una herramienta de coacutedigo abierto desarro-llada en Python que permite gestionar configuraciones aprovisionar recursosdespliegue de aplicaciones de forma automaacutetica
A grandes rasgos esta herramienta funciona mediante ficheros en formatoYAML denominados play-books que describen un conjunto de pasos a ejecutaren una lista de equipos remotos Estos pasos son ejecutados por moacutedulos inde-pendientes a traveacutes de SSH es decir en cualquier ordenador con conexioacuten a los
38
hosts dado su contrasentildea o clave puacuteblica puede arrancar el script y realizariacutealos pasos de forma remota gestionando el cluster desde un solo equipo
Se han desarrollado guiones para lo siguiente
Descarga de los binarios de Nomad y Consul en todos los nodos copiade los ficheros de configuracioacuten baacutesicos y modificarlos de acuerdo a cadanodo (nombre del equipo direccioacuten IP)
Instalacioacuten de las dependencias
Arranque de Nomad y Consul
Ansible extiende su funcionalidad a traveacutes de moacutedulos independientes que per-miten por ejemplo instalar paquetes mediante herramientas de gestioacuten de pa-quetes (APT yum) aprovisionar automaacuteticamente maacutequinas virtuales de Ama-zon EC2
Algunas opciones de los ficheros de configuracioacuten de Nomad y Consul sondependientes del nodo particular por ejemplo la interfaz de red Para estetrabajo se ha realizado un moacutedulo para modificar los ficheros de configuracioacutende forma automaacutetica En el repositorio del proyecto se encuentra una carpetadonde se encuentran todos los ficheros necesarios para desplegar un clustertotalmente funcional solo requiere de una liacutenea de terminal con Ansible
$ ans ib l eminusplaybook minus i hos t s minusk ltssh_passgt minusu ltnode_usergt s i t e yml
39
62 Servicio de integracioacuten continua
Se ha implementado un sistema de integracioacuten continua que permite ejecu-tar tareas de compilacioacuten y pruebas de forma distribuida aumentando asiacute elrendimiento de los equipos En primer lugar se detallaraacute los motivos por los quepuede resultar beneficioso para las empresas una implementacioacuten de este tipo alo que seguiraacute los detalles del despliegue
621 DevOps
Metodologiacutea que defiende la comunicacioacuten y colaboracioacuten entre desarrolla-dores de software y los profesionales de operaciones a lo largo de todo el ciclo devida de una aplicacioacuten Estaacute muy relacionado con el desarrollo aacutegil de softwareesto es un enfoque para los proyectos que defiende el desarrollo iterativo e in-cremental donde los requisitos y soluciones evolucionan con el tiempo seguacuten lanecesidad del proyecto DevOps extiende esta filosofiacutea a todas los componentesde un servicio incluyendo sistemas y operaciones
Se trata de un concepto que cada organizacioacuten o empresa adapta a suspropias necesidades y procesos de negocio en este proyecto nos vamos a centraren la integracioacuten continua una praacutectica fundamental tanto del desarrollo aacutegilcomo de esta filosofiacutea
622 Integracioacuten Continua
Se define como una praacutectica de desarrollo software donde los miembros delequipo ponen en comuacuten su trabajo frecuentemente al menos una vez al diacutea21Cada integracioacuten se verifica con una compilacioacuten automaacutetica que incluye laejecucioacuten de pruebas para detectar errores de integracioacuten tan pronto como seaposible
Desde el punto de vista operativo esto supone automatizar la configuracioacutende equipos o el despliegue de maacutequinas virtuales donde compilar el proyecto yejecutar las pruebas y posteriormente eliminarlas Este flujo de trabajo se vebeneficiado en entornos distribuidos ya que el objetivo del desarrollador es com-probar el resultado de las pruebas raacutepidamente sin preocuparse del despliegueo los propios equipos
Para esta prueba de concepto vamos a usar Jenkins un servidor de integra-cioacuten continua escrito en Java que nos permite definir trabajos que contendraacutenla descripcioacuten tanto del entorno como su ejecucioacuten
Este sigue una estructura maestro-esclavo muy similar al de los gestores declusters usados en este proyecto el maestro contiene toda la loacutegica del servicio
21httpmartinfowlercomarticlescontinuousIntegrationhtml
40
trabajos autenticacioacuten y los esclavos son los encargados de la ejecucioacuten ensiacute Jenkins tiene varias viacuteas para aprovisionar los uacuteltimos
Mediante SSH
Interfaz graacutefica
Desarrollar un script propio
Ejecucioacuten de un fichero java
La ventaja de usar planificadores es que el despliegue de esclavos es dinaacutemicoes decir no tener una maacutequina especiacuteficamente configurada para ello DCOS yNomad se encargaraacuten de configurar estos despliegues en sus maacutequinas y poste-riormente eliminarlos Para ello se ha usado la uacuteltima opcioacuten definiendo tareasque descarguen el fichero java Con todo ello se consigue un entorno de inte-gracioacuten continua eficiente que ademaacutes permite la ejecucioacuten de otros servicios deforma independiente
Jenkins permite la creacioacuten de plugins que extienden sus funcionalidadesTanto Nomad22 como Apache Mesos cuentan con uno que permite su integra-cioacuten
Para esta prueba se va a usar el mismo proyecto que para el caso de usode orquestacioacuten de contenedores la aplicacioacuten web al que se le ha antildeadido untest para comprobar que se conecta correctamente a la base de datos medianteMocha un framework de Nodejs Por otro lado se antildeade el plugin de git ya queel coacutedigo se obtiene de GitHub el repositorio remoto de control de versiones delproyecto
El proceso general de ejecucioacuten seriacutea como sigue
1 Se ejecuta el maestro de Jenkins como tarea Docker partiendo de la imagenoficial
2 Al arrancar un trabajo se manda una tarea a los planificadores que laasignaraacuten a un nodo cliente Esta tarea consiste en la descarga del ficherode configuracioacuten Java y arrancarlo configurando el equipo como un clientede Jenkins temporalmente
3 Jenkins ejecuta el trabajo en el nuevo cliente en este caso iniciar la apli-cacioacuten web iniciar las pruebas y generar un informe
4 Se elimina el cliente
A continuacioacuten se detallan los matices de cada herramienta a la hora de imple-mentar este servicio
22Desarrollado por Ivo Verberk httpwwwivoverberknl
41
623 Jenkins con Nomad
El plugin permite la ejecucioacuten del fichero Java mediante dos controladorescontenedores Docker y Java En este proyecto nos hemos decantado por el pri-mero ya que nos ahorra instalar la maacutequina virtual de java en todos los nodoscliente Por ello se ha construido un contenedor base con Java para la ejecucioacutendel fichero de configuracioacuten y Nodejs para lanzar la aplicacioacuten web
El plugin se configura con la direccioacuten IP del cluster y el contenedor queejecuta el esclavo Jenkins Por su parte el trabajo en Jenkins se define conel repositorio en GitHub donde se aloja el coacutedigo del proyecto a probar y loscomandos a ejecutar en este caso npm update y npm test
624 Jenkins con DCOS
En el caso de DCOS su sistema de paquetes incluye Jenkins por lo queal instalarlo ya se tiene la configuracioacuten de Mesos totalmente funcional Sinembargo para ejecutar la aplicacioacuten en particular y las pruebas se requiere deNodejs en los equipos esclavos por ello debemos antildeadir un plugin de Jenkinsque permite instalar este entorno antes de ejecutar el trabajo Una vez hechoesto soacutelo queda definir la tarea igual que en el caso anterior
Cabe destacar que Mesosphere tambieacuten ha desarrollado un plugin que per-mite hacer despliegues en Marathon de tal manera que permitiriacutea con cadacommit del coacutedigo compilar la imagen del contenedor Docker y desplegarlaautomaacuteticamente aunque en este proyecto no se ha hecho pruebas de esta fun-cionalidad
42
7 Escalando la infraestructura
Uno de los factores clave que se busca a la hora de implementar sistemasdistribuidos es el poder escalar la infraestructura de forma maacutes sencilla estoes detectar que las maacutequinas estaacuten alcanzando el liacutemite de su capacidad yaumentar eacutesta ya sea mejorando sus caracteriacutesticas teacutecnicas o antildeadiendo maacutesnodos al cluster
El coacutedigo y todos los ficheros de configuracioacuten de esta seccioacuten tambieacuten sepueden encontrar en el repositorio del proyecto en GitHub23
71 Disentildeo
Microsoft Azure permite organizar los servicios cloud de forma loacutegica a traveacutesde grupos de recursos y asiacute poder crear o eliminar eacutestos en conjunto parauna aplicacioacuten determinada (por ejemplo una aplicacioacuten web suele requerir demaacutequinas virtuales bases de datos almacenamiento) Ademaacutes dispone dela opcioacuten de crear plantillas en formato JSON que permite al desarrolladordefinir los recursos y su interrelacioacuten para desplegar de forma automaacutetica unainfraestructura TI en la nube
Azure tambieacuten ofrece la posibilidad de monitorizar el estado de las maacutequinasvirtuales a traveacutes de extensiones lo que permite configurar el escalado automaacute-tico al alcanzar cierto liacutemite definido por el operador Eacutesta es a priori la formaen que deberiacutea implementarse hablando en teacuterminos de eficiencia sin embargoesta aproximacioacuten es totalmente dependiente de la plataforma es decir no sepuede extrapolar a otro proveedor o sobre recursos propios sin realizar un nue-vo disentildeo En este proyecto las tareas que son ejecutadas por estos equipos notienen estado ya que todo lo relativo a la persistencia lo hemos asignado fueradel cluster esto permite escalar la plataforma a traveacutes de otra aproximaciones
Las plantillas aceptan una serie de variables a indicar por el usuario entreotras los conjuntos de escala para definir los nodos aceptan una variable quedefine el nuacutemero de maacutequinas que los componen Por otro lado Azure ofreceuna API REST y kits de desarrollo software (SDK por sus siglas en ingleacutes) quepermiten su despliegue de forma programaacutetica Aprovechando estas facilidadesen este proyecto se va a aproximar la escalabilidad con el sucesivo desplieguede la infraestructura de forma automaacutetica se monitorizan los equipos y si sedetecta una maacutequina excesivamente cargada se aumenta el nuacutemero de equiposen la plantilla y se vuelve a desplegar
23httpsgithubcomAntonioAlfrzCloud-Orchestrators
43
En este proyecto se han disentildeado las plantillas para desplegar la arquitec-tura necesaria tanto de Nomad como de DCOS En el caso de la primera eldespliegue es maacutes descriptivo ya que incluye maacutequinas virtuales grupos de se-guridad redes En el caso de DCOS Azure cuenta con un servicio especiacuteficopara clusters gobernados por DCOS denominado Azure Container Service queincluye los componentes necesarios y la instalacioacuten ya realizada
72 Implementacioacuten
En primer lugar para monitorizar el estado de los equipos se va a usar laherramienta Nagios un sistema que permite controlar el estado del hardwarey los servicios de un equipo Se trata de una herramienta muy completa de laque se va a usar su capacidad para ejecutar comandos (plugins) en los nodospara detectar picos de carga generar alertas y ejecutar programas para estoseventos
Se ha desplegado una maacutequina virtual con esta herramienta en ambos siste-mas y se ha instalado una extensioacuten de Nagios (Nagios Remote Plugin Executor)en todos los nodos que permite ejecutar comprobaciones remotamente en con-creto para esta prueba de concepto medir el nivel de saturacioacuten de la unidadcentral de procesamiento (CPU por sus siglas del ingleacutes) Cuando sucede uncambio de estado de una maacutequina esto es cuando este paraacutemetro supera el liacutemi-te definido por el operador Nagios permite actuar en consecuencia ejecutandoprogramas por ello se ha desarrollado un script que ejecuta lo siguiente
Un programa desarrollado en Python con el SDK de Azure que modificalas plantillas y despliega los recursos
Un guioacuten de Ansible para instalar todos los componentes necesarios en lasnuevas maacutequinas y arrancar de nuevo el cluster y las aplicaciones
44
8 Resultados y conclusiones
En este uacuteltimo apartado se da una visioacuten global del proyecto asiacute como a lasconclusiones maacutes importantes a las que se ha llegado y posibles temas futurosde desarrollo
81 Comparacioacuten
Ambas herramientas ofrecen las funcionalidades para gestionar los recursoseficientemente ofreciendo a los desarrolladores una plataforma donde desplegarsus aplicaciones de forma distribuida independientemente de los equipos fiacutesicosy el hardware que las soporten
DCOS es una herramienta que en un comienzo fue privativa pero cuyos res-ponsables la empresa Mesosphere decidieron publicar una versioacuten de coacutedigoEacutesta nos permite gestionar un cluster de una forma sencilla y usable ademaacutes decomplementarlo con otras herramientas como el balanceador de carga integradoo la autenticacioacuten de usuarios ademaacutes estaacute basada en Apache Mesos un pro-yecto de relativa madurez y con el soporte de la Apache Software FoundationDe forma resumida DCOS ofrece muchas posibilidades y servicios a cambiode una arquitectura e instalacioacuten maacutes compleja
Por su parte HashiCorp con menor tiempo de desarrollo ha conseguidouna herramienta muy sencilla de desplegar que ademaacutes cumple con todas lasfuncionalidades baacutesicas ejecutando un simple binario en cada nodo se puededesplegar un gestor de clusters totalmente funcional Sin embargo no cuentacon todas las posibilidades de Mesos (Nomad cuenta con menos controladoresque entornos posibles de Mesos) ni con los antildeadidos de DCOS lo que implicael uso de otras herramientas para complementar el servicio (Consul HAProxy)
De entre las dificultades encontradas al usar estas herramientas y desplegaraplicaciones sobre ellas se puede destacar la depuracioacuten en ocasiones se desco-noce si un error viene de la propia herramienta de la aplicacioacuten desplegada o delequipo fiacutesico si no se cuenta con un sistema de procesamiento de registro unose puede encontrar con muacuteltiples terminales abiertas inspeccionando numerososficheros de registro buscando posibles errores Ademaacutes no dejan de ser solucio-nes que para usar eficientemente se debe conocer parte de su funcionamientoy sintaxis a la hora de describir la tareas lo que supone un esfuerzo antildeadido yaque cada una tiene sus particularidades y liacutemites
45
82 Conclusiones
En una sociedad cada vez maacutes digital las empresas deben adaptarse a unmercado cuya demanda de contenido no deja de crecer Las nuevas arquitecturascomo microservicios asiacute como la gran cantidad de datos generada implica queuna mejor gestioacuten de los recursos y la rapidez para desplegar o escalar solucionesdando valor al cliente lo maacutes raacutepido posible es uno de los objetivos de todas lasempresas de base tecnoloacutegica
Las ventajas que ofrecen los planificadores con aplicaciones distribuidas sonnumerosas sin ir maacutes lejos empresas tan punteras como Google llevan maacutesde 10 antildeos orquestando contenedores24 Por un lado permiten aumentar elrendimiento de los equipos propios y por otro implementar un servicio comoplataforma para despliegues distribuidos sobre cualquier conjunto hardware deesta forma se provee un servicio similar al de la nube puacuteblica pero con laprincipal diferencia de que se elimina la independencia con el proveedor (vendorlock-in) esto es las aplicaciones no tienen limitaciones impuestas por eacuteste talescomo lenguaje de programacioacuten o herramientas y permite despliegues hiacutebridosentre recursos propios y la nube
83 Objetivos conseguidos
Implementacioacuten de los planificadores propuestos en la nube Se ha en-tendido y detallado el funcionamiento de estas herramientas y se hanimplementado en el servicio de infraestructura de Microsoft Azure
Despliegue de aplicaciones y servicios distribuidos Servicios que se usanactualmente en la industria del desarrollo software asiacute como una aplica-cioacuten web con una arquitectura moderna han sido desplegados de formadistribuida en los equipos cumpliendo con la funcionalidad esperada ade-maacutes de consiguiendo una alta disponibilidad
Aproximacioacuten de arquitectura escalable Se ha hecho una aproximacioacutende infraestructura escalable de forma que sea parcialmente extrapolable aotros proveedores
24httpwwwnextplatformcom20160322decade-container-control-google
46
84 Liacuteneas de investigacioacuten
Siguiendo con la materia de este proyecto se presentan posibles liacuteneas deinvestigacioacuten
Analizar el despliegue con estas herramientas de aplicaciones de Big Datay comparar la eficiencia con respecto a soluciones especializadas
Analizar el rendimiento de los algoritmos de planificacioacuten antes pruebasde estreacutes y situaciones de alta contienda
Comparar el uso de estas herramientas con las praacutecticas actuales de laindustria o implementacioacuten en un sistema de produccioacuten real
47
Referencias
[1] LA Barroso y U Houmllzle laquoThe Datacenter as a Computer An Introduc-tion to the Design of Warehouse-Scale Machinesraquo En Morgan amp ClaypoolPublishers ()
[2] Systems Research Group ndash NetOS (University of Cambridge) The evolu-tion of cluster scheduler architectures 2016 url httpswwwclcamacukresearchsrgnetoscamsasblog2016-03-09-scheduler-architectureshtml
[3] A Das I Gupta y A Motivala SWIM Scalable Weakly-consistent Infection-style Process Group Membership Protocol Inf teacutec Dept of ComputerScience Cornell University url https www cs cornell edu ~asdasresearchdsn02-swimpdf
[4] D Dubhashi y A Das Mastering Mesos PACKT Publishing mayo de2016
[5] The Apache Software Foundation Apache Mesos documentation urlhttpsmesosapacheorg
[6] David Greenberg Building Applications on Mesos OrsquoReilly Media 2016[7] Armand Grillet Comparison of Container Schedulers Inf teacutec Technische
Universitaumlt Berlin[8] HashiCorp Consul documentation url httpswwwconsulio[9] HashiCorp Nomad documentation url httpsdcosio[10] Dan C Marinescu Cloud computing theory and practice Morgan Kauf-
mann 2013[11] Mesosphere DCOS documentation url httpswwwnomadproject
io[12] Microsoft Azure documentation url httpsazuremicrosoftcom
es-esdocumentation[13] D Ongaro y J Ousterhout In Search of an Understandable Consensus
Algorithm Inf teacutec Stanford University url httpsraftgithubioraftpdf
[14] Fei Teng laquoRessource allocation and schelduling models for cloud compu-tingraquo Tesis de mtriacutea Ecole Centrale Paris 2011
[15] A Williams y col Automation and Orchestration with Docker and Contai-ners A Comprehensive Overview of the Docker and Container Ecosystem3 The New Stack 2016
48
- Resumen
- Summary
- Iacutendice de figuras
- Introduccioacuten y objetivos
-
- Contexto
- Objetivos
- Estructura del documento
-
- Cloud Computing
- Nuevas cargas de trabajo
- Gestioacuten de recursos Planificadores
-
- Sistemas distribuidos
-
- Clasificacioacuten
-
- Herramientas
-
- DCOS
-
- Apache Mesos
- Ejemplos de uso
-
- Nomad
-
- Protocolo de consenso Raft
- Protocolo gossip SWIM
- Planificacioacuten
-
- Casos de uso y despliegue
-
- Aplicacioacuten Web
-
- DCOS
- Nomad
-
- Servicio de integracioacuten continua
-
- DevOps
- Integracioacuten Continua
- Jenkins con Nomad
- Jenkins con DCOS
-
- Escalando la infraestructura
-
- Disentildeo
- Implementacioacuten
-
- Resultados y conclusiones
-
- Comparacioacuten
- Conclusiones
- Objetivos conseguidos
- Liacuteneas de investigacioacuten
-
Figura 3 Planificador monoliacuteticoFuente httpswwwclcamacuk
Planificacioacuten de dos niveles
La mayoriacutea de los clusters ejecutan aplicaciones con distintas necesidadesdesde procesos casi instantaacuteneos hasta servicios persistenteslo que implica dis-tintas necesidades de recursos
Por ello la planificacioacuten a dos niveles distingue dos funciones la gestioacutende recursos (gestor) y la disposicioacuten de las tareas (planificador) Cada serviciotiene su propio planificador de tal manera que el gestor les ldquoofertardquo recursosde acuerdo a una poliacutetica y los planificadores se encargan de escoger la maacutesadecuada Esto permite que el proceso de distribucioacuten sea maacutes acorde con lasnecesidades de los diferentes servicios Apache Mesos que detallaremos maacutesadelante sigue este esquema
Como desventaja cabriacutea sentildealar que esta programacioacuten implica que los pla-nificadores pierden la vista general de la infraestructura y las tareas soacutelo puedenejecutarse con los recursos que les son ofrecidos lo que dificulta la implementa-cioacuten de prioridades de ejecucioacuten de tareas entre otras
Figura 4 Planificador de dos niveles
11
Planificacioacuten de estado compartido
Muacuteltiples reacuteplicas del estado del cluster se actualizan independientementepara cada planificador como se observa en la figura 5 cuando sucede un cambiode forma local el planificador se encarga de informar al resto
Ejemplo de este tipo son Omega la evolucioacuten de Borg por parte de GoogleMicrosoft Apollo y Nomad que usaremos para los casos de uso
De entre las desventajas se puede destacar el hecho de que en general losnodos trabajan con informacioacuten desactualizada lo que conlleva una degradacioacutendel rendimiento en situaciones de alta contienda
Figura 5 Planificador de estado compartido
Planificacioacuten distribuida
En este caso no existe coordinacioacuten entre los distintos planificadores Cadauno de ellos funciona con su propia vista del cluster Las tareas pueden serorganizadas por cualquiera de ellos y desplegadas en cualquier parte del clusteren base a la aleatoriedad y multiplexacioacuten estadiacutestica de los flujos de trabajosin ninguacuten control central
Figura 6 Planificador distribuido
12
5 Herramientas
En la industria comienzan a aparecer soluciones software de coacutedigo abiertoque aglutinan los servicios necesarios para gestionar la infraestructura TI de ma-nera maacutes eficaz El objetivo es doble se busca facilitar la gestioacuten de los recursosde computacioacuten para organizaciones con instalaciones propias mediante su usocon un enfoque cloud esto es desplegar aplicaciones a traveacutes de un conjuntode ordenadores de forma transparente y sin tener en cuenta la infraestructurasubyacente o aprovechar el maacuteximo rendimiento de la infraestructura de losproveedores cloud puacuteblicos de forma que se tiene el maacuteximo control sobre eacutestapero no se depende de las soluciones propietarias permitiendo asiacute despliegueshiacutebridos
Entre estas herramientas se pueden destacar
OpenStack Proyecto desarrollado por la fundacioacuten del mismo nombre paraproporcionar servicios de infraestructuras (IaaS) basado en componentesque se comunican a traveacutes de APIs El componente Magnum incluye mo-tores de orquestacioacuten de contenedores
Kubernetes Sistema de orquestacioacuten de contenedores Docker creado por Goo-gle
CoreOs Sistema operativo basado en Linux disentildeado para despliegues distri-buidos sobre contenedores incluyendo mecanismos de descubrimiento deservicio y comparticioacuten de configuracioacuten
Docker Swarm Herramienta nativa de orquestacioacuten de contenedores Docker
YARN Entorno de gestioacuten de recursos y aplicaciones distribuidas de Hadoopuna libreriacutea software de procesamiento de grandes conjuntos de datos
Como podemos observar existe un gran rango de opciones para gestionar lainfraestructura desde un bajo nivel como puede ser OpenStack hasta Kuberne-tes o Docker Swarm que ofrecen exclusivamente orquestacioacuten de contenedores
En este trabajo se ha optado por Mesosphere DCOS y HashiCorp Nomadque se encuentran en el teacutermino medio su objetivo es proporcionar serviciosde plataforma que permitan la coexistencia dediferentes cargas de trabajo en elcluster
13
51 DCOS
DCOS es un proyecto de coacutedigo abierto7 creado y desarrollado por la empre-sa Mesosphere Se describe como un sistema operativo distribuido que abstraelos recursos de un cluster (capacidad de procesamiento memoria) permite lagestioacuten de muacuteltiples ordenadores de forma transparente y simplifica la instala-cioacuten de aplicaciones distribuidas
Su arquitectura se puede comparar a la de Linux en teacuterminos de nuacutecleo(kernel) y espacio de usuario El primero consta de recursos protegidos a losque no puede acceder el usuario e involucra operaciones de bajo nivel comoasignacioacuten de recursos o aislamiento de procesos En el espacio de usuario seejecutan las aplicaciones y servicios de maacutes alto nivel
Siguiendo con este siacutemil el nuacutecleo de DCOS estaacute basado en Apache Mesosque se explicaraacute en un apartado posterior y el espacio de usuario que estaacute com-prendido por los componentes del sistema esto es las diferentes herramientasque en conjunto conforman DCOS y los servicios encargados de planificar yejecutar las aplicaciones y tareas del usuario
Figura 7 Arquitectura DCOSFuente httpsdcosio
De entre los componentes que conforman DCOS destacan
Admin Router Balanceador de carga central basado en NGINX que dis-pone un proxy entre todos los servicios en el puerto 80 permitiendo sugestioacuten mediante la interfaz graacutefica Ademaacutes se encarga de la autenticacioacutenpara acceder al panel de administracioacuten
Cosmos Gestor de paquetes de las aplicaciones
Diagnostics Se ejecuta en todos los nodos y se encarga de monitorizar elestado de los daemons que sustentan DCOS
7Desde abril de 2016 httpsmesospherecomblog20160419open-source-dcos
14
Exhibitor Gestiona y automatiza el despliegue de ZooKeper la herra-mienta que provee de configuracioacuten centralizada y registro de nombres
Marathon Equivale al proceso init de los sistemas tipo Unix esto es elprimer proceso en ejecucioacuten tras la carga del kernel y que genera los demaacutesprocesos Se encarga de arrancar y monitorizar las aplicaciones y servicios
Mesos-DNS Servicio de DNS interno que define el dominio mesos pa-ra nodos y tareas en el cluster es decir permite resolver nombres conindependencia de la direccioacuten fiacutesica
Minuteman Balanceador de carga integrado a nivel TCPUDP disponiblepara las propias aplicaciones
Por otra parte se definen como servicios a las diferentes aplicaciones dis-tribuidas que DCOS permite instalar en el cluster y que pueden haber sidodesarrollados por la misma empresa Mesosphere o por terceros por ejemploApache Spark Jenkins o Apache Hadoop En la figura 8 se muestra un diagramade los servicios disponibles incluyendo algunos de las aplicaciones distribuidasque soporta DCOS
Figura 8 Servicios DCOSFuente httpsdcosio
511 Apache Mesos
El nuacutecleo de DCOS estaacute basado en Apache Mesos un proyecto de coacutedigoabierto creado por la Universidad de California Berkeley y desarrollado actual-mente por la fundacioacuten Apache Se trata de un administrador de clusters queabstrae los recursos y los dispone para diferentes aplicaciones y entornos de tra-bajo distribuidos (frameworks) mediante una interfaz comuacuten En el momento deredaccioacuten de este proyecto Apache Mesos soportaba una variedad de entornosque abarcaba desde Big Data (Apache Spark Hadoop) hasta bases de datos(Cassandra Hypertable)
15
Arquitectura
Mesos se basa en la asignacioacuten de dos roles diferentes a los nodos
Maestros (Masters) Se encargan de la gestioacuten y reparticioacuten de los recursospara los diferentes entornos de trabajo mediante ldquoofertas de recursosrdquo deacuerdo a los disponibles y a la poliacutetica de asignacioacuten (planificacioacuten en dosniveles)
Esclavos (Slaves) Ordenadores donde se ejecutaraacuten las aplicaciones y cu-yos recursos son ofertados por los maestros
En el caso de fallo del maestro las tareas pueden seguir ejecutaacutendose perono se podraacute asignar nuevos recursos ni tareas por ello pueden existir varios enel cluster para configuraciones de alta disponibilidad pero soacutelo uno orquesta alos esclavos
Para la eleccioacuten del master liacuteder Mesos usa Apache ZooKeeper un proyectode software desarrollado por la misma fundacioacuten cuyo objetivo es proveer deun servicio de configuracioacuten centralizado y registro de nombres8
Por otra parte los entornos de trabajo son los programas que deciden final-mente queacute recursos se van a usar y se encargan de que los esclavos ejecuten lastareas Eacutestos se ejecutan sobre Mesos y constan de dos componentes
Planificador (Scheduler) Optimiza y decide los recursos a utilizar de losofertados informando a los Masters
Procesador (Executor) Ejecuta las aplicaciones o servicios en los esclavos
El objetivo final es conseguir una interfaz liviana tolerante a fallos paracualquier tipo de entorno de trabajo de tal manera que en los esclavos del clusterpuedan ejecutarse simultaacuteneamente tareas con necesidades y duracioacuten diferentesPara ello se basa en dos conceptos asignacioacuten y aislamiento de recursos
Asignacioacuten de recursos
En el cluster pueden coexistir entornos de trabajo con tareas de larga dura-cioacuten y con gran consumo de recursos con tareas cortas que los ocupan y liberancon rapidez El maestro integra un moacutedulo de asignacioacuten de recursos (allocationmodule) que se encarga del algoritmo de distribucioacuten
En el momento de escribir este proyecto estaban desarrollados dos moacutedulosuno mediante el cual el usuario puede asignar prioridades y otro que implementa
8httpszookeeperapacheorg
16
el algoritmo Dominant Resource Fairness9 a grandes rasgos se determina entodos los esclavos la tarea en ejecucioacuten que necesita maacutes recursos y se calcula laproporcioacuten del recurso de mayor peso con respecto al total por ejemplo si unatarea ocupa 2 GB de memoria con respecto a 10 GB totales que tiene el clusterse le asigna un dominant share del 20 la tarea se asignaraacute al nodo con menordominant share
Aislamiento de recursos
Para conseguir que tareas de diferentes entornos de trabajo y con distin-ta naturaleza se ejecuten simultaacuteneamente en un mismo nodo Mesos usa loscontenedores Linux (descritos en la seccioacuten 3)
Funcionamiento
La figura 9 muestra el esquema de la arquitectura de Apache Mesos conalta disponibilidad (tres maestros) y con dos entornos de trabajo ejecutaacutendo-se Hadoop que permite el almacenamiento y procesamiento de gran cantidadde datos para proyectos de big data y un sistema que implementa la interfazsistema de paso de mensajes MPI
Como se puede observar el sistema ZooKeeper elige a un solo maestro comoliacuteder y eacuteste orquesta el cluster comunicando los esclavos con los planificadoresde los diferentes entornos de trabajo Tambieacuten se puede observar como las tareasde los distintos entornos estaacuten distribuidas entre los tres esclavos disponibles
Figura 9 Arquitectura de Apache MesosFuente httpsmesosapacheorg
El proceso de asignacioacuten se realiza como sigue en primer lugar un usuariosolicita la ejecucioacuten de una tarea mediante la interfaz de cada entorno de traba-jo (interfaz graacutefica API HTTP ) De forma paralela un esclavo informa almaestro de los recursos que tiene libres En consecuencia eacuteste se lo notifica almoacutedulo de asignacioacuten que en funcioacuten de su configuracioacuten decide cuaacutento ofertar
9httpspeopleeecsberkeleyedu~aligpapersdrfpdf
17
y a queacute entorno de trabajo y enviacutea la oferta a los planificadores Eacutestos respondenal maestro con queacute recursos ha decidido usar para cada tarea Finalmente lastareas son enviadas al esclavo seleccionado el cual asigna los recursos indicadosal procesador (executor) quien finalmente las ejecuta
Cabriacutea pensar que esta metodologiacutea puede conducir a situaciones en lasque un entorno podriacutea quedarse con tareas sin ejecutarse a la espera de unaoferta satisfactoria para ello Mesos implementa un sistema de filtros medianteel cual los entornos especifican los requisitos miacutenimos que debe cumplir unaoferta por ejemplo se puede especificar en queacute nodos debe desplegarse la tareaEste sistema estaacute disentildeado asiacute con el objetivo de mantener lo maacutes transparenteposible esta herramientas de forma que acepte entornos de trabajo de distintasnaturalezas
512 Ejemplos de uso
Grandes empresas estaacuten usando Apache Mesos con eficacia de acuerdo a susnecesidades e infraestructuras Caben destacar
Ebay En el modelo de implementacioacuten continua en esta empresa10 cadadesarrollador cuenta con su propia instancia que se ejecuta en una maacutequinavirtual dedicada lo que ha conllevado un uso de los recursos poco eficiente Enuna prueba de concepto consiguieron realizar una herramienta de integracioacutencontinua distribuida basada en un cluster con Apache mesos y con el entornoMarathon y Jenkins
Apple Anuncioacute que el motor de su famosa herramienta de asistencia per-sonal para iPhones Siri estaacute desplegada sobre Apache Mesos11 Para ello handesarrollado su propio entorno para facilitar a los ingenieros a desplegar los ser-vicios que la herramienta necesita para resolver las peticiones de los usuarios
Twitter Desarrolloacute su propio entorno denominado Aurora y actualmentegestionan sus recursos y miden el coste de las tareas que los empleados usancon el objetivo de que sean conscientes del gasto que puede suponer un usoinadecuado de la infraestructura12
10httpwwwebaytechblogcom20140404delivering-ebays-ci-solution-with-apache-mesos-part-i11httpwwwbusinessinsidercomapple-siri-uses-apache-mesos-2015-812httpswwwlinuxcomNEWS4-UNIQUE-WAYS-UBER-TWITTER-PAYPAL-AND-HUBSPOT-USE-APACHE-MESOS
18
52 Nomad
Herramienta de coacutedigo abierto de gestioacuten de clusters creada y desarrolladapor Hashicorp13 que permite el despliegue de aplicaciones y procesos de formadistribuida
Las principales diferencias con Apache Mesos a grandes rasgos son
Arquitectura maacutes ligera Nomad soacutelo requiere de un fichero para funcionarejecutaacutendolo con las correspondientes configuraciones en todos los nodosrealiza las funciones de gestioacuten del cluster eleccioacuten de liacuteder planificacioacutende recursos y ejecucioacuten de las tareas
Centro de datos y regiones muacuteltiples Su arquitectura estaacute orientada afacilitar la gestioacuten de diferentes centros de datos geograacuteficamente distri-buidos
Entorno de ejecucioacuten Las tareas se definen y son interpretadas mediantecontroladores integrados en Nomad que se valen de los recursos y herra-mientas de los nodos clientes para ejecutarlas Esta integracioacuten dificultael desarrollo de controladores por parte de terceros a diferencia de Mesosque delega dicha responsabilidad en los entornos de trabajo externos alproyecto
Usa un planificador de estado compartido con respecto a la planificacioacutenen dos niveles de Mesos
Antes de entrar en maacutes detalle en la arquitectura es importante definir lossiguientes teacuterminos
Controlador (Driver) Software que se encarga de interpretar las definicionesde las tareas y ejecutarlas semejante a los procesadores de los entornosde trabajo de Mesos A la hora de redactar este proyecto Nomad contabacon controladores para contenedores Docker virtualizacioacuten de maacutequinasmediante el emulador QEMU aplicaciones java y archivos binarios
Grupo de trabajo (Task Group) Conjunto de tareas que se ejecutan en elmismo nodo cliente
Trabajo (Job) Conjunto loacutegico de tareas y grupos de trabajo que se despliegana la vez
Asignacioacuten (Allocation) Relacioacuten entre un grupo de trabajo y el cliente don-de se ejecuta
Evaluacioacuten (Evaluation) Proceso mediante el cual Nomad planifica y ges-tiona el registro o actualizaciones de los trabajos
13httpswwwhashicorpcom
19
Nomad sigue una arquitectura maestro-esclavo similar a la de Apache Mesosmuacuteltiples servidores acuerdan entre siacute un liacuteder que gestiona la planificacioacuten detareas en los clientes que soacutelo conocen sus asignaciones y las ejecutan
Todos los servidores participan paralelamente en tareas de planificacioacuten derecursos y asignacioacuten de tareas y ademaacutes entre ellos eligen un liacuteder que seencarga de la coordinacioacuten de la suscripcioacuten de los clientes al cluster y de lagestioacuten de las peticiones
Los clientes estaacuten configurados para comunicarse con el servidor usando lla-madas a procedimiento remoto (RPC por sus siglas en ingleacutes) que permite unordenador ejecutar coacutedigo en otra maacutequina Mediante esta tecnologiacutea los nodosclientes avisan de su estado e informa de sus asignaciones recursos y controla-dores disponibles
Existe la posibilidad de gestionar varios centros de datos agrupados en regio-nes eacutestas son independientes pero permite definir tareas o comprobar el estadode todas ellas desde cualquier punto A continuacioacuten se muestra una figura dela arquitectura a alto nivel de esta configuracioacuten
Figura 10 Arquitectura multi-regioacuten en NomadFuente httpswwwnomadprojectio
La herramienta se sustenta sobre tres protocolos fundamentales un protocolode consenso entre los servidores para compartir informacioacuten sobre su estado yel liacuteder un protocolo Gossip para la gestioacuten entre regiones y el planificador detareas
521 Protocolo de consenso Raft
El objetivo es obtener consistencia en un conjunto de nodos que comparteninformacioacuten es decir si un cliente realiza un cambio que todos los nodos veanla misma informacioacuten a la vez y ademaacutes sea tolerante a fallos Para ello se basaen el algoritmo Raft[13] que se detalla brevemente a continuacioacuten
20
Los nodos participantes en el algoritmo pueden estar en tres estados
Liacuteder (Leader) Todos los cambios que realicen en el cluster pasan por eacutel pri-mero
Seguidor (Follower) Nodo pasivo cuya responsabilidad es responder a laspeticiones del nodo liacuteder
Candidato (Candidate) Maacutequina que no ha encontrado liacuteder y solicita sueleccioacuten
Supongamos que tenemos cinco equipos que acaban de arrancar el protocoloEn la figura 11 se observan los nodos y sus respectivos registros a la derecha
Figura 11 Equipos sin consenso ejecutando el protocolo RAFTFuente httpsgithubcomongardieraftscope
Al comenzar todos los nodos son seguidores esperando recibir comunicacioacutende un nodo que actuacutee como liacuteder Cada nodo tiene un tiempo de espera aleatoriodespueacutes del cual si no es informado por un liacuteder pasa a estado candidato y pideel ldquovotordquo al resto de los participantes El algoritmo divide el tiempo en plazos uncandidato pasa a liacuteder si recibe la mayoriacutea de los votos en un plazo determinadoSe define mayoriacutea o cuoacuterum (quorum) comolceil
N2rceil
+ 1 (1)
donde N representa el nuacutemero de nodos
Para el ejemplo propuesto de 5 equipos se requieren de 3 votos Soacutelo losnodos que se encuentren en estado seguidor pueden votar una uacutenica vez a laprimera solicitud que reciba dentro de un plazo
Supoacutengase que el nodo denotado con S1 ha cumplido su tiempo de espera yrealiza la peticioacuten de voto (figura 12) A partir de este momento se pueden dartres casos
La maacutequina gana la eleccioacuten y pasa a ser liacuteder informando al resto
Otro servidor se establece como liacuteder en el mismo momento
Varios nodos pasan a ser candidatos por lo que ninguno consigue los votos
21
Figura 12 Un equipo pasa a estado candidato (RAFT)
Si un candidato recibe un aviso de un liacuteder en el mismo plazo el primeropasa a ser seguidor y se acaba la eleccioacuten de liacuteder
Por otro lado si un equipo candidato no recibe los votos en el plazo y agotasu tiempo de espera avanza al siguiente plazo y repite el proceso de votacioacutenLa tercera posibilidad puede conllevar a un estado indefinido ya que varioscandidatos pueden agotar su tiempo de espera al mismo tiempo y repartir losvotos Para solventarlo el algoritmo establece tiempos de espera aleatorios paralos candidatos
Siguiendo con el ejemplo propuesto el servidor S1 pasa a ser el liacuteder Cadacierto tiempo eacuteste debe realizar avisos a los nodos seguidores para no agotar sutiempo de espera
En este momento el cluster de servidores estaacute en ldquoconsensordquo y la informacioacutenen todos los nodos estaacute actualizada Un cambio en la informacioacuten inicia unproceso de replicacioacuten el liacuteder registra el cambio lo pasa al resto de nodos yuna vez eacutestos responden el cambio se hace efectivo
Supoacutengase que se realiza un cambio en los datos en la figura 13 en la partederecha se observa el cambio en el registro del servidor S1 que informa a losnodos seguidores En consecuencia los nodos registran el cambio y responden aS1
Figura 13 Cambio en un registro (RAFT)
Una vez el cuoacuterum (en el ejemplo tres equipos) informa al liacuteder de que
22
ha registrado el cambio el liacuteder lo hace efectivo en su sistema y notifica a losnodos que hacen lo mismo En la figura 14 el enviacuteo todaviacutea no ha llegado ala maacutequina S3 y se observa que no ha hecho efectivo el cambio (en el registroaparece punteado)
Figura 14 Aprobacioacuten del resto de equipos (RAFT)
Este protocolo funcionaraacute correctamente mientras exista un nuacutemero de nodosen funcionamiento igual o superior al cuoacuterum en el ejemplo propuesto elcuoacuterum es tres por lo que el sistema puede tolerar la caiacuteda de dos de los equipos
522 Protocolo gossip SWIM
Nomad permite la gestioacuten simultaacutenea de varios centros de datos reparti-dos en regiones geograacuteficamente separadas requiriendo de un protocolo ligeroque mantenga a los miembros actualizados sobre los participantes del conjun-to Para ello usa una ligera variante del protocolo SWIM[3] (Scalable Weakly-consistent Infection-style Process Group Membership Protocol) desarrollada porHashiCorp Estaacute clasificado como un protocolo de tipo gossip que debe su nom-bre a la semejanza con coacutemo se distribuye un rumor en una red social
SWIM se sustenta en dos caracteriacutesticas fundamentales la deteccioacuten de fallosy la distribucioacuten de la informacioacuten relativa a los miembros A continuacioacuten sedetalla el funcionamiento de ambos componentes
Deteccioacuten de fallos
Este componente tiene dos paraacutemetros el periodo de protocolo T y el nuacutemerode subgrupos de deteccioacuten de fallos k en los que se dividen los nodos Paracomprobar la comunicacioacuten entre dos maacutequinas usa la utilidad ping basadaen el protocolo ICMP La deteccioacuten de caiacuteda de un servidor sigue el siguientealgoritmo
Durante el periodo T cada miembro Mi de un subgrupo elige otro al azar Mjdel mismo subgrupo y le enviacutea un mensaje ping para comprobar su estado Enel caso de que se cumpla un tiempo de espera determinado por una estimacioacuten
23
del tiempo de ida y vuelta (RTT por sus siglas en ingleacutes) de la red y no hayarespuesta Mi le vuelve a enviar un mensaje ping indirectamente a traveacutes deun nuacutemero k de miembros escogidos aleatoriamente De no recibir ninguna res-puesta Mi establece que Mj ha sufrido un fallo y lo etiqueta como ldquosospechosordquoinformando al componente de distribucioacuten
Figura 15 Diagrama de tiempo del protocolo SWIMFuente httpswwwcscornelledu
Componente de distribucioacuten
Se encarga de informar de cualquier cambio en los miembros a todo el con-junto Los eventos de nodo caiacutedo y la unioacuten o disociacioacuten de un miembro setransmiten a todos los servidores para que actualicen sus lista Para distribuirla informacioacuten a todos los nodos se podriacutea usar el meacutetodo de multicast perosuele estar deshabilitado Por ello se utiliza una teacutecnica de transmisioacuten denomi-nada Piggybacking mediante la cual se adjunta a los propios mensajes PINGy ACK del algoritmo la informacioacuten a distribuir reduciendo asiacute la congestioacutenen la red
523 Planificacioacuten
Proceso encargado de distribuir las tareas entre los nodos clientes de acuerdoa su estado
El planificador de Nomad estaacute basado en las publicaciones de Google sobresus herramientas de gestioacuten de clusters Borg y Omega14 y entiende los trabajosdescritos por el usuario como un estado deseado es decir su despliegue en unamaacutequina cliente de forma correcta y los clientes como el estado actual esto eslo que se encuentra en ejecucioacuten El registro actualizacioacuten o cancelacioacuten de un
14httpresearchgooglecompubspub43438html
24
trabajo asiacute como el fallo de un nodo cliente implican un cambio de estado atramitar por el sistema lo que se define como evaluacioacuten (evaluation) Esto uacutelti-mo supone comparar el estado actual (clientes) con el estado deseado (conjuntode trabajos registrados) y enviarlos a los planificadores correspondientes que seencargaraacuten de asignar las tareas a los nodos clientes
Figura 16 Procedimiento de asignacioacuten en NomadFuente httpswwwnomadprojectio
En la figura 16 se observa el flujo de trabajo en el que las distintas evalua-ciones se encolan en el evaluation broker que se ejecuta en el servidor liacuteder ygestiona las evaluaciones pendientes asignaacutendoles prioridades
A continuacioacuten los nodos servidores ejecutan los scheduling workers queprocesan las evaluaciones llamando a los distintos planificadores que generanun plan de asignacioacuten esto es un conjunto de relaciones entre las tareas y losnodos clientes donde se ejecutaraacuten Este proceso se divide en dos fases primerose descartan aquellos clientes que no cumplan los requisitos y posteriormentese asigna una calificacioacuten al resto Se selecciona el nodo con mayor puntuacioacuteny se encola el plan en el gestor que se ejecuta en el servidor liacuteder Existen tresplanificadores de acuerdo al tipo de trabajo
Service Incluye aquellos trabajos que estaacuten destinados a ejecutarse en un pe-riacuteodo largo de tiempo Para realizar las asignaciones el planificador evaluacuteala mayor parte de los nodos y usa una versioacuten del algoritmo Best fit in-fluenciada por el trabajo de Google en su herramienta Borg Se trata deun algoritmo de planificacioacuten que sacrifica tiempo a cambio de maximizarel rendimiento de los clientes asignando la tarea a la maacutequina que tengala mayor carga de trabajo con el objetivo de reducir equipos en funciona-
25
miento
Batch Tareas que incluyen listas de comandos en general de menor duracioacuteny que no requieren interaccioacuten con el usuario Se vale del algoritmo deSparrow desarrollado por la universidad de Berkeley15 para limitar losnodos clientes a evaluar
System Trabajos destinados a ejecutarse en todos los nodos incluso los que seunen al cluster posteriormente
Core Mantenimiento interno de Nomad
Una vez se ha realizado el proceso de planificacioacuten el nodo liacuteder lo registra enla cola de planes (plan queue) que se encarga de asignarles prioridad y manejarcondiciones de carrera es decir que no accedan a los recursos de los clientes sincontrol y evitar que eacutestos superen su capacidad
La maacutequina liacuteder del conjunto puede de este modo aceptar una asignacioacuteny ser ejecutada por los clientes o por el contrario rechazaacutersela al planificadorlo que implicariacutea realizar un plan parcial o totalmente nuevo
Finalmente el estado de las evaluaciones se actualizan y los clientes soninformados de las asignaciones ejecutaacutendose las tareas
15httppeopleeecsberkeleyedu~keopublicationssosp13-final17pdf
26
6 Casos de uso y despliegue
Con el objetivo de mostrar las posibles utilidades que este tipo de sistemaspueden tener en las infraestructuras TI actuales se han desplegado las dos he-rramientas en la nube Microsoft Azure usando su servicio cloud de instancias demaacutequinas virtuales Linux para simular un conjunto de ordenadores conectadosentre siacute por una red LAN Sobre ellas se ha implementado dos casos de usouna aplicacioacuten web con una arquitectura con cierta orientacioacuten a microserviciosy un sistema de integracioacuten continua
El coacutedigo y todos los ficheros de configuracioacuten se pueden encontrar en elrepositorio del proyecto en GitHub16
61 Aplicacioacuten Web
Se busca simular el proceso de adaptacioacuten de una solucioacuten web para su des-pliegue en un sistema distribuido con las herramientas anteriormente descritascon el objetivo de aumentar tanto su escalabilidad como disponibilidad medianteredundancia
Se ha partido de una aplicacioacuten ya existente17 un servicio de almacenamien-to y reproduccioacuten de canciones A grandes rasgos este servicio permite crearusuarios subir canciones con sus respectivas portadas tener playlists propias yescuchar las canciones a traveacutes de un navegador web
La solucioacuten estaacute dividida en 4 partes (figura 17)
Una vista web con la loacutegica
Un almacenamiento conectado en red (NAS por sus siglas en ingleacutes)
Una API REST para gestionar las peticiones al almacenamiento
Base de datos NoSQL basada en MongoDB
La nueva tendencia de los proyectos web es su implementacioacuten en contene-dores Docker ya que facilitan su portabilidad y ofrecen un procedimiento dedespliegue raacutepido sobre todo a la hora de desarrollar y realizar pruebas en en-tornos de produccioacuten simulados Por ello en este caso se va a hacer uso de los
16httpsgithubcomAntonioAlfrzCloud-Orchestrators17httpsgithubcomsonsoleslpCDPSfy
27
motores de orquestacioacuten de contenedores de ambas herramientas Marathon enDCOS y el controlador Docker en el caso de Nomad
Figura 17 Arquitectura aplicacioacuten web
A continuacioacuten vamos detallar el despliegue en ambas herramientas de es-ta solucioacuten y observar tanto queacute dificultades se encuentran como que ventajasofrecen El objetivo final es adaptar el proyecto modificaacutendolo lo menos posiblecon objeto de analizar la capacidad de estas herramientas para desplegar cual-quier aplicacioacuten sin que eso conlleve la modificacioacuten de la arquitectura de eacutestaes decir que no sea dependiente del entorno
611 DCOS
Se ha descrito DCOS como una herramienta que se despliega sobre un con-junto de ordenadores y que permite instalar gestionar el despliegue de sistemasdistribuidos
Microsoft Azure cuenta con una plantilla para desplegar en su servicio cloudun cluster de maacutequinas virtuales con DCOS ya instalado que cuenta con
Maacutequinas maestras (1 3 o 5 a seleccionar por el usuario) configuradascomo un conjunto de disponibilidad esto eso Azure da ciertas garantiacuteasde que al menos una maacutequina estaraacute en funcionamiento
Maacutequinas agentes Por motivos de seguridad se distinguen dos roles
bull Nodos privados solo accesibles desde la red interna y configuradoscomo un conjunto de escala un recurso de Azure para gestionar ydesplegar maacutequinas con configuraciones ideacutenticas para permitir unraacutepido escalado
bull Un equipo conectado accesible desde Internet a travntildees de un balan-ceador de carga puacuteblico y situado en una subred externa
28
Dos balanceadores de carga
bull La interfaz puacuteblica del cluster que se conecta con el cliente puacuteblicobull Acceso a los equipos maestros para el administrador que soacutelo permiteconexioacuten mediante SSH y credenciales
Almacenamiento para todas las maacutequinas
Configuraciones necesarias de red y seguridad
En la figura 18 se observa un diagrama de la infraestructura
Figura 18 Infraestructura en Azure
El primer obstaacuteculo es la persistencia de estado de la aplicacioacuten que seconsigue gracias a una base de datos no relacional basada en MongoDB asiacutecomo el almacenamiento de las canciones Para implementarla tenemos variasposibilidades
Montar un sistema externo de almacenamiento conectado en red en todoslos agentes donde se ejecuten las tareas de esta manera si una tarea pasade un nodo a otro por cualquier motivo puede tener acceso a los mismosficheros (opcioacuten del caso de uso original)
Implementar un sistema de ficheros distribuidos en los agentes
Usar los servicios de almacenamiento de las nubes puacuteblicas
Aprovechar el sistema de voluacutemenes persistentes de Apache Mesos Eacutestepermite reservar recursos de un agente de forma que al arrancar una tarease crea un volumen independiente del ciclo de vida de eacutesta con ello esosrecursos donde se ha almacenado la informacioacuten pueden volver a ofrecerseal mismo entorno de tal manera que otra tarea pueda acceder a ella
DCOS aprovecha este sistema de voluacutemenes persistentes y permite instalarbases de datos distribuidas como ArangoDB o Apache Cassandra sin embargoesto implicariacutea modificar todo el coacutedigo referente al modelo de la base de datos
29
Por motivos de eficiencia y latencia asiacute como de una mayor gobernabilidadde los datos la mejor opcioacuten es usar el recurso de voluacutemenes persistentes queofrece Apache Mesos ya que de esta manera se gestionariacutea la aplicacioacuten completamediante una uacutenica herramienta Sin embargo esto implica que la informacioacutense encuentra exclusivamente en el agente donde se haya ejecutado la tarea y porlo tanto se sigue requiriendo de software externo para distribuir la informacioacutenpara que se accesible para todos los agentes A la hora de realizar este proyectose encontraba en desarrollo Flocker una solucioacuten desarrollada por ClusterHQque permite compartir los voluacutemenes de Docker a traveacutes de un cluster quesi bien es compatible con el planificador de Mesos el proyecto se encontrabatodaviacutea en fases tempranas de desarrollo y los sistemas de almacenamiento quesoporta quedaban fuera del aacutembito de este trabajo
Por todo ello dado que las maacutequinas se han desplegado en la nube puacuteblicade Azure se decidioacute usar su servicio de almacenamiento de objetos para lascanciones y otra maacutequina para desplegar MongoDB y asiacute mantener el modelode datos original de la aplicacioacuten La diferencia del almacenamiento de obje-tos con respecto a nivel de fichero es que el primero no tiene jerarquiacutea paraorganizar los archivos eacutestos se guardan como objetos (con sus metadatos) enun mismo espacio soacutelo diferenciaacutendose por un identificador uacutenico esto implicaentre otras cosas que se puede acceder a un fichero dado uacutenicamente su IDindependientemente de la localizacioacuten fiacutesica de eacuteste facilitando pues la gestioacuteny el desarrollo
El coacutedigo del proyecto se ha modificado en los siguientes apartados
Las direcciones de la base de datos y los balanceadores de carga asiacute comosus puertos estaban originalmente fijos Se han configurado como variablesde entorno para facilitar el descubrimiento del servicio y hacer transpa-rente la aplicacioacuten al entorno de despliegue
La API REST se ha adaptado al almacenamiento en Azure en vez de enlocal
Estas modificaciones no suponen un cambio sustancial pero permiten separala persistencia de las tareas ejecutadas por DCOS lo que facilita en granmedida su ejecucioacuten al ser totalmente sin estado y ademaacutes implican tenerlos datos bajo un mayor control
Para la orquestacioacuten de contenedores se va a usar el entorno Marathondesarrollado tambieacuten por Mesosphere Eacuteste se puede usar a traveacutes de una interfazgraacutefica la interfaz de liacutenea de comandos (en lo que sigue CLI por sus siglas eningleacutes) de DCOS o con su API HTTP
Primero se han publicado la imaacutegenes de los contenedores que encapsulanla interfaz web y la api de la aplicacioacuten en el repositorio puacuteblico DockerHub
Los despliegues en este entorno se describen mediante ficheros JSON en losque se detalla entre otras opciones la imagen del contenedor los puertos a usar
30
los recursos que debe ocupar en un nodo o las instrucciones de monitorizacioacuten
Para el servicio de descubrimiento DCOS ofrece la posibilidad de asignardirecciones IP virtuales (VIP por sus siglas en ingleacutes) a tareas que se compartenen todos los nodos DCOS lleva integrado un balanceador de carga a nivel TCP(el componente denominado Minuteman) que balancea entre las direccionesvirtuales de las tareas y todas las instancias de eacutestas a lo largo del cluster Estoes necesario por dos motivos equilibrar la carga de los equipos con el fin deevitar un punto de uacutenico fallo mediante redundancia y evitar la contienda dedirecciones al ejecutar las tareas en puertos aleatorios
Este balanceador de carga estaacute basado en el trabajo de Michael Mitzenma-cher The Power of Two Choices in Randomized Load Balancing18 A grandesrasgos el algoritmo mantiene una media moacutevil exponencial de latencias paracada destino (backend) ademaacutes de las caiacutedas consecutivas Si un destino noresponde a una negociacioacuten en tres pasos (three way handshake) de forma con-secutiva en un periodo inferior a 5 ms se considera caiacutedo El algoritmo iterasobre los destinos disponibles en base a su histoacuterico de fallos y escoge dos deforma aleatoria de los cuales coge el de mejor meacutetrica
Las direcciones virtuales soacutelo se pueden resolver dentro del cluster porello para implementar la interfaz puacuteblica de la aplicacioacuten esto es el balancea-dor de carga de la interfaz web usaremos un paquete de DCOS denominadomarathon-lb un balanceador basado en HAProxy y adaptado por MesosphereEn este caso equilibra la carga de todas instancias de las tareas ejecutadas porel entorno Marathon por sus etiquetas y permite ademaacutes definir como puntode entrada muacuteltiples hosts virtuales definidos por sus nombres completos dedominio (FQDN por sus siglas en ingleacutes) en nuestro caso la interfaz puacuteblicadel balanceador de Azure para los agentes
Por motivos de seguridad todas las tareas se ejecutan en los agentes privadoses decir los que son exclusivamente accesibles desde la red interna Por su partemarathon-lb se ejecuta en el agente puacuteblico que cuenta con IP puacuteblica y lospuertos 80 (HTTP) y 8080 abiertos de forma que la aplicacioacuten sea accesibledesde Internet Esto es posible debido a que Apache Mesos permite reservarrecursos mediante roles asignados a nodos para un uso especiacutefico De esta formala arquitectura vista desde la aplicacioacuten quedariacutea como en la figura 19
18httpswwweecsharvardedu~michaelmpostscriptstpds2001pdf
31
Figura 19 Arquitectura de la aplicacioacuten web en DCOS
Ejecucioacuten
A la hora de desplegar la aplicacioacuten DCOS puede gestionarse medianteuna interfaz graacutefica o una interfaz de liacutenea de comandos La primera se accedea traveacutes de un navegador web en el puerto 80 (HTTP) y permite instalar losentornos disponibles observar el estado de los nodos y las tareas que se estaacutenejecutando y los ficheros de registros que eacutestas generan
La CLI permite el control desde un nodo o una maacutequina remota (suponiendoque los maestros tienen IP puacuteblica y el puerto 80 abierto) ya que DCOS tieneun sistema de autorizacioacuten que permite tener una interfaz puacuteblica con ciertasgarantiacuteas de seguridad
Por su parte cada entorno de trabajo puede ser controlado por la CLI peroademaacutes cuenta con sus propias interfaces Marathon expone una API HTTPen el puerto 8080 de la direccioacuten puacuteblica de los maestros del cluster asiacute comootra interfaz graacutefica Para desplegar un contenedor se podriacutea usar la CLI
$ dcos marathon app add lt f i l e j songt
O la API HTTP
$ cu r l minusX POST http lt ip_maestro gt8080v2apps minusd ltf i l e jsongt minusH Contentminustype app l i c a t i o n j son
32
612 Nomad
La arquitectura de Nomad es maacutes sencilla ya que solo requiere de un ficheroejecutable en todos los nodos para funcionar Si DCOS es la base de instala-cioacuten de entornos de terceros Nomad integra todas las funcionalidades baacutesicasesto es gestor de recursos planificador y ejecutor en los nodos cliente Estaherramienta cuenta con un menor tiempo de desarrollo y en el momento deescribir este documento cuenta exclusivamente con los siguientes controladoresen comparacioacuten con los entornos de DCOS
Motor Docker es decir funcioacuten de orquestacioacuten de contenedores
Ejecucioacuten de archivos binarios como comandos de Shell
Ejecucioacuten de aplicaciones Java
Virtualizacioacuten de maacutequinas mediante tecnologiacutea QEMU
Todos ellos necesitan que la tecnologiacutea subyacente esteacute instalada en las maacute-quinas clientes (Docker Java QEMU) Actualmente no permite el registro decontroladores por parte de terceros aunque estaacute planificado en un futuro ofreceruna interfaz para su desarrollo
Nomad no cuenta con el servicio de descubrimiento sin embargo puede inte-grarse con la herramienta Consul desarrollada por la misma empresa Por otrolado para el balanceo de carga usaremos un contenedor Docker con HAProxyuna herramienta de coacutedigo abierto que ofrece tanto servicios de proxy como debalanceador y cuyos ficheros de configuracioacuten completaremos con el proyectoConsul Template19
Consul
Consul sigue la misma arquitectura que Nomad es decir un nodo servidorque orquesta un conjunto de maacutequinas clientes y permite a los procesos que seejecutan en los equipos definirlos como servicios ofreciendo diversas caracteriacutes-ticas entorno a estos de los cuales vamos a usar dos
Descubrimiento de servicio Las maacutequinas clientes publican en el cataacutelogode servicios las tareas en ejecucioacuten y Consul les asigna nombres de dominioaccesibles por todos los miembros del cluster a traveacutes de la interfaz DNSincluida en esta herramientaConsul se integra con Nomad de forma que todas las tareas que se ejecu-ten en la segunda son automaacuteticamente publicados como servicios de laprimera de esta manera no hace falta conocer la direccioacuten de la maacutequinacliente donde se esteacute ejecutando el proceso ya que se puede acceder a eacutela traveacutes de su nombre de dominio de forma transparente Por ejemplo si
19[httpsgithubcomhashicorpconsul-template]
33
ejecutamos una tarea con ID web en el puerto 8080 se puede acceder aella en la direccioacuten webserviceconsul8080Para que las direcciones propias de Consul las resuelva su propio DNS y noel que esteacute asignado por defecto en la maacutequina usaremos la herramientadnsmasq20 que permite especificar la direccioacuten de un servidor DNS paraconsultas de direcciones especiacuteficas
Monitorizacioacuten Permite realizar comprobaciones del servicio y seguir su esta-do Aprovecharemos esta funcionalidad tanto para definir el propio procesode Nomad como servicio de Consul como las tareas desplegadas
HAProxy + Consul Template
HAProxy es una solucioacuten versaacutetil de coacutedigo abierto que ofrece solucionesde balanceo de carga y proxy Existen otras herramientas en el mercado comoNGINX o ldirectord sin embargo HAProxy suponiacutea una solucioacuten sencilla deconfigurar para mostrar el caso de uso
El uso de estas herramientas se debe a dos motivos para que no existacontienda con respecto a los puertos de los clientes usados por las tareas eacutestos sevan a asignar de forma dinaacutemica lo que en principio implicariacutea que la aplicacioacutendeberiacutea realizar consultas DNS de tipo SRV (que incluye puertos) a la interfazde Consul y balancear la carga entre tareas por redundancia y capacidad
Como la direccioacuten IP y puerto son variables cada vez que las tareas seactualicen o se reasignen es necesario volver a configurar HAProxy de formamanual Por ello HashiCorp ha desarrollado un programa denominado Con-sul Template que realiza peticiones sucesivas a la interfaz HTTP de Consul delas direcciones fiacutesicas de un servicio y reinicia automaacuteticamente el proceso deHAProxy Asiacute definiendo estas tareas como servicios Consul podremos tantomonitorizarlas como escalar las tareas dinaacutemicamente sin necesidad de cambiarel balanceador A partir del contenedor Docker oficial de HAProxy se ha desa-rrollado otro con la configuracioacuten baacutesica y con Consul Template para desplegarlocomo una tarea en Nomad
Despliegue
Se ha usado el mismo coacutedigo que en el apartado anterior con la persistenciaen el servicio de almacenamiento de Azure Desde la perspectiva del hardwarese implementaraacute la misma infraestructura que en el caso de DCOS (figura 18)estos es definiremos dos tipos de maacutequinas clientes un agente que se conectaraacutecon el balanceador de carga con nombre de dominio puacuteblico y donde se desple-garaacute el balanceador de carga de la vista web y agentes privados no accesiblesdesde fuera del cluster y donde se ejecutaraacuten el resto de tareas en la red inter-na La principal diferencia radica en las tareas que ejecutan HAproxy y ConsulTemplate que sustituye a las direcciones IP virtuales que ofrece DCOS
20httpwwwthekelleysorgukdnsmasqdochtml
34
Figura 20 Despliegue en Azure de Nomad+Consul
Cabe matizar que los balanceadores basados en HAProxy se implementanpor necesidad de la aplicacioacuten para el descubrimiento del servicio a diferenciade los de Azure que se implementan por motivos de seguridad y escalabilidaddel cluster en siacute
Configuracioacuten Nomad
Los ficheros de configuracioacuten de las maacutequinas maacutester y cliente son similaresy comparten la mayoriacutea de las opciones como por ejemplo el nombre del nodoo la interfaz de red donde escucha Nomad las peticiones Sus opciones son engeneral auto-explicativas sin embargo existen dos detalles que matizar
El proceso de Nomad escucha las peticiones tanto de los protocolos deconsenso como del usuario a traveacutes de una interfaz de red que se debeindicar en el fichero de configuracioacuten
En el caso de los clientes se deben indicar las direcciones de los servidoresdel cluster sin embargo se trata de un sistema dinaacutemico en el que losnodos pueden sufrir errores y cambiar de direccioacuten Por ello se ha definidoNomad como un servicio de Consul y asiacute poder definir la direccioacuten de losservidores como un nombre de dominio no por su direccioacuten fiacutesica que elservidor DNS de Consul se encargaraacute de resolver
Por defecto Nomad usa los siguientes puertos
API HTTP 4646 Peticiones HTTP y recepcioacuten de oacuterdenes mediante laliacutenea de comandos
RPC 4647 Protocolo de consenso entre los nodos del cluster
Serf 4648 Protocolo de gossip entre los servidores de los centros de datosgobernados por Nomad
35
Los dos uacuteltimos deben ser interfaces alcanzables por otros nodos sin embargo laAPI HTTP por motivos de seguridad deberiacutea ser local ya que en caso contrariocualquier persona con acceso a ella tiene el control sobre la herramienta Eacutestasolo deberiacutea estar accesible en un servidor o gestionarlo mediante una terminalSSH por ejemplo En este trabajo al ser una prueba de concepto se ha abiertoen todos los nodos
Trabajos de Nomad
Las tareas se detallan en ficheros con formato HashiCorp Configuration Lan-guage un derivado del formato JSON creado por la empresa que le da nombrecompatible con eacuteste y que permite comentarios
En estos ficheros se puede definir
La regioacuten y el centro de datos donde se ejecutaraacute (Nomad permite lagestioacuten de centros de datos geograacuteficamente distribuidos en regiones)
La poliacutetica de actualizacioacuten de la tarea
Grupo de tareas esto es que se ejecutaraacuten en el mismo nodo
El nuacutemero de grupos a ejecutarescalar asiacute como los liacutemite que debencumplir los nodos asignados
La poliacutetica de reinicio ante fallo o error
Tareas El controlador su configuracioacuten los paraacutemetros del servicio aso-ciado a registrar en Consul asiacute como los recursos que consume (puertosmemoria)
En nuestro caso usamos sobre todo el controlador Docker esto eso orques-tacioacuten de contenedores en los nodos clientes y tres de sus opciones
Imagen del contenedor Se han subido todas las imaacutegenes del proyecto a Doc-ker Hub donde por defecto se busca la imagen
Puertos Los puertos a usar por el contenedor que pueden ser estaacuteticos asigna-dos por el usuario o dinaacutemicos siendo Nomad el que se encarga de mapearun puerto libre del nodo cliente al expuesto por el contenedor
Servidores DNS Como usamos la interfaz DNS de Consul como descubri-miento de servicio se debe configurar el contenedor para que use cualquiernodo del cluster como servidor DNS
Configuracioacuten Consul
Al ser desarrolladas por la misma empresa los ficheros de configuracioacuten deConsul y Nomad comparten muchas opciones Consul tambieacuten acepta peticionesa traveacutes de una interfaz de red siendo los puertos usados por defecto
36
RPC 8300 8400 Maneja la peticiones del resto de nodos y usuarios
Serf 8301 8302 Protocolo gossip
HTTP API 8500
HTTPS API Desactivada por defecto
Interfaz DNS 8600
Se debe asignar a los protocolos internos del cluster esto es RPC y Serf unainterfaz alcanzable por los nodos y por el contrarioasignar a los dos uacuteltimos ala interfaz de loopback por motivos de seguridad
Cabe destacar que Consul tambieacuten cuenta con una interfaz graacutefica que per-mite ver el estado de los equipos y los servicios registrados y que se encuentra enel mismo puerto que la API HTTP en la direccioacuten httpIP_EQUIPO8500ui
Ejecucioacuten
Tanto Nomad como Consul requieren de la ejecucioacuten de un fichero en todoslos nodos integrantes del cluster Como prueba de concepto se ha decidido usardos servidores para ambos aunque cabe matizar que es un nuacutemero ineficienteya que la caiacuteda de uno de ellos supondriacutea la peacuterdida del cuoacuterum y por tantodel consenso del cluster
En primer lugar se arrancan los servidores que son los encargados de ejecu-tar el protocolo de consenso y gestionar el cluster y a continuacioacuten los clientesque no tienen praacutecticamente estado y dependen de los servidores
En el caso de Consul se debe indicar el directorio donde se guardan losficheros que describen los servicios asiacute como el archivo que especifica el resto delas opciones
1 Se inicia el primer servidor en uno de los equipos
$ consu l agent minuscon f i gminusd i r e t c consu l d s e r v i c e s minuscon f i gminus f i l e consu l_server j son
2 Los siguientes equipos deben unirse al anterior por lo que antildeadimos elargumento join con la direccioacuten del primer servidor Para el caso de otrosservidores
$ consu l agent minuscon f i gminusd i r e t c consu l d s e r v i c e s minuscon f i gminus f i l e consu l_server j son minus j o i n ltIP_servidor1gt
37
Una vez los servidores han alcanzado el consenso y elegido un liacuteder en losclientes
$ consu l agent minuscon f i gminusd i r e t c consu l d s e r v i c e s minuscon f i gminus f i l e c on su l_c l i en t j son minus j o i n ltIP_cualquierServ idorgt
El proceso para iniciar Nomad es igual y los comandos similares sin embargoya no es necesario indicar una direccioacuten IP fija en los equipos sino el nombre dedominio del servicio de Nomad registrado por Consul En el primer servidor
$ nomad agent minusc on f i g nomad_server j son
Y el resto de equipos (con su fichero de configuracioacuten correspondiente)$ nomad agent minusc on f i g nomad_server j son minus j o i n nomad s e r v i c e consu l
Por uacuteltimo para desplegar la aplicacioacuten web se han escrito tres ficherosque detallan las tareas de la interfaz web API y los balanceadores de cargaMediante la CLI
$ nomad run minusaddress=http lt ip_c lus te r gt4646 lt f i l e hclgt
O mediante la API HTTP de Nomad$ cu r l minusX POST minusd ltf i l e hclgthttp lt ip_c lus te r gt4646 jobltjob_namegt
Ansible
Como se puede comprobar con el aumento del nuacutemero de equipos pasa aser inviable manejar todos los nodos a traveacutes de terminal Ademaacutes como seha comentado con anterioridad Nomad requiere que en los nodos clientes es-teacuten instalados las herramientas que soporten las tareas por ejemplo el motorde Docker Por ello para facilitar tanto el arranque como la instalacioacuten de lasdependencias vamos a usar Ansible una herramienta de coacutedigo abierto desarro-llada en Python que permite gestionar configuraciones aprovisionar recursosdespliegue de aplicaciones de forma automaacutetica
A grandes rasgos esta herramienta funciona mediante ficheros en formatoYAML denominados play-books que describen un conjunto de pasos a ejecutaren una lista de equipos remotos Estos pasos son ejecutados por moacutedulos inde-pendientes a traveacutes de SSH es decir en cualquier ordenador con conexioacuten a los
38
hosts dado su contrasentildea o clave puacuteblica puede arrancar el script y realizariacutealos pasos de forma remota gestionando el cluster desde un solo equipo
Se han desarrollado guiones para lo siguiente
Descarga de los binarios de Nomad y Consul en todos los nodos copiade los ficheros de configuracioacuten baacutesicos y modificarlos de acuerdo a cadanodo (nombre del equipo direccioacuten IP)
Instalacioacuten de las dependencias
Arranque de Nomad y Consul
Ansible extiende su funcionalidad a traveacutes de moacutedulos independientes que per-miten por ejemplo instalar paquetes mediante herramientas de gestioacuten de pa-quetes (APT yum) aprovisionar automaacuteticamente maacutequinas virtuales de Ama-zon EC2
Algunas opciones de los ficheros de configuracioacuten de Nomad y Consul sondependientes del nodo particular por ejemplo la interfaz de red Para estetrabajo se ha realizado un moacutedulo para modificar los ficheros de configuracioacutende forma automaacutetica En el repositorio del proyecto se encuentra una carpetadonde se encuentran todos los ficheros necesarios para desplegar un clustertotalmente funcional solo requiere de una liacutenea de terminal con Ansible
$ ans ib l eminusplaybook minus i hos t s minusk ltssh_passgt minusu ltnode_usergt s i t e yml
39
62 Servicio de integracioacuten continua
Se ha implementado un sistema de integracioacuten continua que permite ejecu-tar tareas de compilacioacuten y pruebas de forma distribuida aumentando asiacute elrendimiento de los equipos En primer lugar se detallaraacute los motivos por los quepuede resultar beneficioso para las empresas una implementacioacuten de este tipo alo que seguiraacute los detalles del despliegue
621 DevOps
Metodologiacutea que defiende la comunicacioacuten y colaboracioacuten entre desarrolla-dores de software y los profesionales de operaciones a lo largo de todo el ciclo devida de una aplicacioacuten Estaacute muy relacionado con el desarrollo aacutegil de softwareesto es un enfoque para los proyectos que defiende el desarrollo iterativo e in-cremental donde los requisitos y soluciones evolucionan con el tiempo seguacuten lanecesidad del proyecto DevOps extiende esta filosofiacutea a todas los componentesde un servicio incluyendo sistemas y operaciones
Se trata de un concepto que cada organizacioacuten o empresa adapta a suspropias necesidades y procesos de negocio en este proyecto nos vamos a centraren la integracioacuten continua una praacutectica fundamental tanto del desarrollo aacutegilcomo de esta filosofiacutea
622 Integracioacuten Continua
Se define como una praacutectica de desarrollo software donde los miembros delequipo ponen en comuacuten su trabajo frecuentemente al menos una vez al diacutea21Cada integracioacuten se verifica con una compilacioacuten automaacutetica que incluye laejecucioacuten de pruebas para detectar errores de integracioacuten tan pronto como seaposible
Desde el punto de vista operativo esto supone automatizar la configuracioacutende equipos o el despliegue de maacutequinas virtuales donde compilar el proyecto yejecutar las pruebas y posteriormente eliminarlas Este flujo de trabajo se vebeneficiado en entornos distribuidos ya que el objetivo del desarrollador es com-probar el resultado de las pruebas raacutepidamente sin preocuparse del despliegueo los propios equipos
Para esta prueba de concepto vamos a usar Jenkins un servidor de integra-cioacuten continua escrito en Java que nos permite definir trabajos que contendraacutenla descripcioacuten tanto del entorno como su ejecucioacuten
Este sigue una estructura maestro-esclavo muy similar al de los gestores declusters usados en este proyecto el maestro contiene toda la loacutegica del servicio
21httpmartinfowlercomarticlescontinuousIntegrationhtml
40
trabajos autenticacioacuten y los esclavos son los encargados de la ejecucioacuten ensiacute Jenkins tiene varias viacuteas para aprovisionar los uacuteltimos
Mediante SSH
Interfaz graacutefica
Desarrollar un script propio
Ejecucioacuten de un fichero java
La ventaja de usar planificadores es que el despliegue de esclavos es dinaacutemicoes decir no tener una maacutequina especiacuteficamente configurada para ello DCOS yNomad se encargaraacuten de configurar estos despliegues en sus maacutequinas y poste-riormente eliminarlos Para ello se ha usado la uacuteltima opcioacuten definiendo tareasque descarguen el fichero java Con todo ello se consigue un entorno de inte-gracioacuten continua eficiente que ademaacutes permite la ejecucioacuten de otros servicios deforma independiente
Jenkins permite la creacioacuten de plugins que extienden sus funcionalidadesTanto Nomad22 como Apache Mesos cuentan con uno que permite su integra-cioacuten
Para esta prueba se va a usar el mismo proyecto que para el caso de usode orquestacioacuten de contenedores la aplicacioacuten web al que se le ha antildeadido untest para comprobar que se conecta correctamente a la base de datos medianteMocha un framework de Nodejs Por otro lado se antildeade el plugin de git ya queel coacutedigo se obtiene de GitHub el repositorio remoto de control de versiones delproyecto
El proceso general de ejecucioacuten seriacutea como sigue
1 Se ejecuta el maestro de Jenkins como tarea Docker partiendo de la imagenoficial
2 Al arrancar un trabajo se manda una tarea a los planificadores que laasignaraacuten a un nodo cliente Esta tarea consiste en la descarga del ficherode configuracioacuten Java y arrancarlo configurando el equipo como un clientede Jenkins temporalmente
3 Jenkins ejecuta el trabajo en el nuevo cliente en este caso iniciar la apli-cacioacuten web iniciar las pruebas y generar un informe
4 Se elimina el cliente
A continuacioacuten se detallan los matices de cada herramienta a la hora de imple-mentar este servicio
22Desarrollado por Ivo Verberk httpwwwivoverberknl
41
623 Jenkins con Nomad
El plugin permite la ejecucioacuten del fichero Java mediante dos controladorescontenedores Docker y Java En este proyecto nos hemos decantado por el pri-mero ya que nos ahorra instalar la maacutequina virtual de java en todos los nodoscliente Por ello se ha construido un contenedor base con Java para la ejecucioacutendel fichero de configuracioacuten y Nodejs para lanzar la aplicacioacuten web
El plugin se configura con la direccioacuten IP del cluster y el contenedor queejecuta el esclavo Jenkins Por su parte el trabajo en Jenkins se define conel repositorio en GitHub donde se aloja el coacutedigo del proyecto a probar y loscomandos a ejecutar en este caso npm update y npm test
624 Jenkins con DCOS
En el caso de DCOS su sistema de paquetes incluye Jenkins por lo queal instalarlo ya se tiene la configuracioacuten de Mesos totalmente funcional Sinembargo para ejecutar la aplicacioacuten en particular y las pruebas se requiere deNodejs en los equipos esclavos por ello debemos antildeadir un plugin de Jenkinsque permite instalar este entorno antes de ejecutar el trabajo Una vez hechoesto soacutelo queda definir la tarea igual que en el caso anterior
Cabe destacar que Mesosphere tambieacuten ha desarrollado un plugin que per-mite hacer despliegues en Marathon de tal manera que permitiriacutea con cadacommit del coacutedigo compilar la imagen del contenedor Docker y desplegarlaautomaacuteticamente aunque en este proyecto no se ha hecho pruebas de esta fun-cionalidad
42
7 Escalando la infraestructura
Uno de los factores clave que se busca a la hora de implementar sistemasdistribuidos es el poder escalar la infraestructura de forma maacutes sencilla estoes detectar que las maacutequinas estaacuten alcanzando el liacutemite de su capacidad yaumentar eacutesta ya sea mejorando sus caracteriacutesticas teacutecnicas o antildeadiendo maacutesnodos al cluster
El coacutedigo y todos los ficheros de configuracioacuten de esta seccioacuten tambieacuten sepueden encontrar en el repositorio del proyecto en GitHub23
71 Disentildeo
Microsoft Azure permite organizar los servicios cloud de forma loacutegica a traveacutesde grupos de recursos y asiacute poder crear o eliminar eacutestos en conjunto parauna aplicacioacuten determinada (por ejemplo una aplicacioacuten web suele requerir demaacutequinas virtuales bases de datos almacenamiento) Ademaacutes dispone dela opcioacuten de crear plantillas en formato JSON que permite al desarrolladordefinir los recursos y su interrelacioacuten para desplegar de forma automaacutetica unainfraestructura TI en la nube
Azure tambieacuten ofrece la posibilidad de monitorizar el estado de las maacutequinasvirtuales a traveacutes de extensiones lo que permite configurar el escalado automaacute-tico al alcanzar cierto liacutemite definido por el operador Eacutesta es a priori la formaen que deberiacutea implementarse hablando en teacuterminos de eficiencia sin embargoesta aproximacioacuten es totalmente dependiente de la plataforma es decir no sepuede extrapolar a otro proveedor o sobre recursos propios sin realizar un nue-vo disentildeo En este proyecto las tareas que son ejecutadas por estos equipos notienen estado ya que todo lo relativo a la persistencia lo hemos asignado fueradel cluster esto permite escalar la plataforma a traveacutes de otra aproximaciones
Las plantillas aceptan una serie de variables a indicar por el usuario entreotras los conjuntos de escala para definir los nodos aceptan una variable quedefine el nuacutemero de maacutequinas que los componen Por otro lado Azure ofreceuna API REST y kits de desarrollo software (SDK por sus siglas en ingleacutes) quepermiten su despliegue de forma programaacutetica Aprovechando estas facilidadesen este proyecto se va a aproximar la escalabilidad con el sucesivo desplieguede la infraestructura de forma automaacutetica se monitorizan los equipos y si sedetecta una maacutequina excesivamente cargada se aumenta el nuacutemero de equiposen la plantilla y se vuelve a desplegar
23httpsgithubcomAntonioAlfrzCloud-Orchestrators
43
En este proyecto se han disentildeado las plantillas para desplegar la arquitec-tura necesaria tanto de Nomad como de DCOS En el caso de la primera eldespliegue es maacutes descriptivo ya que incluye maacutequinas virtuales grupos de se-guridad redes En el caso de DCOS Azure cuenta con un servicio especiacuteficopara clusters gobernados por DCOS denominado Azure Container Service queincluye los componentes necesarios y la instalacioacuten ya realizada
72 Implementacioacuten
En primer lugar para monitorizar el estado de los equipos se va a usar laherramienta Nagios un sistema que permite controlar el estado del hardwarey los servicios de un equipo Se trata de una herramienta muy completa de laque se va a usar su capacidad para ejecutar comandos (plugins) en los nodospara detectar picos de carga generar alertas y ejecutar programas para estoseventos
Se ha desplegado una maacutequina virtual con esta herramienta en ambos siste-mas y se ha instalado una extensioacuten de Nagios (Nagios Remote Plugin Executor)en todos los nodos que permite ejecutar comprobaciones remotamente en con-creto para esta prueba de concepto medir el nivel de saturacioacuten de la unidadcentral de procesamiento (CPU por sus siglas del ingleacutes) Cuando sucede uncambio de estado de una maacutequina esto es cuando este paraacutemetro supera el liacutemi-te definido por el operador Nagios permite actuar en consecuencia ejecutandoprogramas por ello se ha desarrollado un script que ejecuta lo siguiente
Un programa desarrollado en Python con el SDK de Azure que modificalas plantillas y despliega los recursos
Un guioacuten de Ansible para instalar todos los componentes necesarios en lasnuevas maacutequinas y arrancar de nuevo el cluster y las aplicaciones
44
8 Resultados y conclusiones
En este uacuteltimo apartado se da una visioacuten global del proyecto asiacute como a lasconclusiones maacutes importantes a las que se ha llegado y posibles temas futurosde desarrollo
81 Comparacioacuten
Ambas herramientas ofrecen las funcionalidades para gestionar los recursoseficientemente ofreciendo a los desarrolladores una plataforma donde desplegarsus aplicaciones de forma distribuida independientemente de los equipos fiacutesicosy el hardware que las soporten
DCOS es una herramienta que en un comienzo fue privativa pero cuyos res-ponsables la empresa Mesosphere decidieron publicar una versioacuten de coacutedigoEacutesta nos permite gestionar un cluster de una forma sencilla y usable ademaacutes decomplementarlo con otras herramientas como el balanceador de carga integradoo la autenticacioacuten de usuarios ademaacutes estaacute basada en Apache Mesos un pro-yecto de relativa madurez y con el soporte de la Apache Software FoundationDe forma resumida DCOS ofrece muchas posibilidades y servicios a cambiode una arquitectura e instalacioacuten maacutes compleja
Por su parte HashiCorp con menor tiempo de desarrollo ha conseguidouna herramienta muy sencilla de desplegar que ademaacutes cumple con todas lasfuncionalidades baacutesicas ejecutando un simple binario en cada nodo se puededesplegar un gestor de clusters totalmente funcional Sin embargo no cuentacon todas las posibilidades de Mesos (Nomad cuenta con menos controladoresque entornos posibles de Mesos) ni con los antildeadidos de DCOS lo que implicael uso de otras herramientas para complementar el servicio (Consul HAProxy)
De entre las dificultades encontradas al usar estas herramientas y desplegaraplicaciones sobre ellas se puede destacar la depuracioacuten en ocasiones se desco-noce si un error viene de la propia herramienta de la aplicacioacuten desplegada o delequipo fiacutesico si no se cuenta con un sistema de procesamiento de registro unose puede encontrar con muacuteltiples terminales abiertas inspeccionando numerososficheros de registro buscando posibles errores Ademaacutes no dejan de ser solucio-nes que para usar eficientemente se debe conocer parte de su funcionamientoy sintaxis a la hora de describir la tareas lo que supone un esfuerzo antildeadido yaque cada una tiene sus particularidades y liacutemites
45
82 Conclusiones
En una sociedad cada vez maacutes digital las empresas deben adaptarse a unmercado cuya demanda de contenido no deja de crecer Las nuevas arquitecturascomo microservicios asiacute como la gran cantidad de datos generada implica queuna mejor gestioacuten de los recursos y la rapidez para desplegar o escalar solucionesdando valor al cliente lo maacutes raacutepido posible es uno de los objetivos de todas lasempresas de base tecnoloacutegica
Las ventajas que ofrecen los planificadores con aplicaciones distribuidas sonnumerosas sin ir maacutes lejos empresas tan punteras como Google llevan maacutesde 10 antildeos orquestando contenedores24 Por un lado permiten aumentar elrendimiento de los equipos propios y por otro implementar un servicio comoplataforma para despliegues distribuidos sobre cualquier conjunto hardware deesta forma se provee un servicio similar al de la nube puacuteblica pero con laprincipal diferencia de que se elimina la independencia con el proveedor (vendorlock-in) esto es las aplicaciones no tienen limitaciones impuestas por eacuteste talescomo lenguaje de programacioacuten o herramientas y permite despliegues hiacutebridosentre recursos propios y la nube
83 Objetivos conseguidos
Implementacioacuten de los planificadores propuestos en la nube Se ha en-tendido y detallado el funcionamiento de estas herramientas y se hanimplementado en el servicio de infraestructura de Microsoft Azure
Despliegue de aplicaciones y servicios distribuidos Servicios que se usanactualmente en la industria del desarrollo software asiacute como una aplica-cioacuten web con una arquitectura moderna han sido desplegados de formadistribuida en los equipos cumpliendo con la funcionalidad esperada ade-maacutes de consiguiendo una alta disponibilidad
Aproximacioacuten de arquitectura escalable Se ha hecho una aproximacioacutende infraestructura escalable de forma que sea parcialmente extrapolable aotros proveedores
24httpwwwnextplatformcom20160322decade-container-control-google
46
84 Liacuteneas de investigacioacuten
Siguiendo con la materia de este proyecto se presentan posibles liacuteneas deinvestigacioacuten
Analizar el despliegue con estas herramientas de aplicaciones de Big Datay comparar la eficiencia con respecto a soluciones especializadas
Analizar el rendimiento de los algoritmos de planificacioacuten antes pruebasde estreacutes y situaciones de alta contienda
Comparar el uso de estas herramientas con las praacutecticas actuales de laindustria o implementacioacuten en un sistema de produccioacuten real
47
Referencias
[1] LA Barroso y U Houmllzle laquoThe Datacenter as a Computer An Introduc-tion to the Design of Warehouse-Scale Machinesraquo En Morgan amp ClaypoolPublishers ()
[2] Systems Research Group ndash NetOS (University of Cambridge) The evolu-tion of cluster scheduler architectures 2016 url httpswwwclcamacukresearchsrgnetoscamsasblog2016-03-09-scheduler-architectureshtml
[3] A Das I Gupta y A Motivala SWIM Scalable Weakly-consistent Infection-style Process Group Membership Protocol Inf teacutec Dept of ComputerScience Cornell University url https www cs cornell edu ~asdasresearchdsn02-swimpdf
[4] D Dubhashi y A Das Mastering Mesos PACKT Publishing mayo de2016
[5] The Apache Software Foundation Apache Mesos documentation urlhttpsmesosapacheorg
[6] David Greenberg Building Applications on Mesos OrsquoReilly Media 2016[7] Armand Grillet Comparison of Container Schedulers Inf teacutec Technische
Universitaumlt Berlin[8] HashiCorp Consul documentation url httpswwwconsulio[9] HashiCorp Nomad documentation url httpsdcosio[10] Dan C Marinescu Cloud computing theory and practice Morgan Kauf-
mann 2013[11] Mesosphere DCOS documentation url httpswwwnomadproject
io[12] Microsoft Azure documentation url httpsazuremicrosoftcom
es-esdocumentation[13] D Ongaro y J Ousterhout In Search of an Understandable Consensus
Algorithm Inf teacutec Stanford University url httpsraftgithubioraftpdf
[14] Fei Teng laquoRessource allocation and schelduling models for cloud compu-tingraquo Tesis de mtriacutea Ecole Centrale Paris 2011
[15] A Williams y col Automation and Orchestration with Docker and Contai-ners A Comprehensive Overview of the Docker and Container Ecosystem3 The New Stack 2016
48
- Resumen
- Summary
- Iacutendice de figuras
- Introduccioacuten y objetivos
-
- Contexto
- Objetivos
- Estructura del documento
-
- Cloud Computing
- Nuevas cargas de trabajo
- Gestioacuten de recursos Planificadores
-
- Sistemas distribuidos
-
- Clasificacioacuten
-
- Herramientas
-
- DCOS
-
- Apache Mesos
- Ejemplos de uso
-
- Nomad
-
- Protocolo de consenso Raft
- Protocolo gossip SWIM
- Planificacioacuten
-
- Casos de uso y despliegue
-
- Aplicacioacuten Web
-
- DCOS
- Nomad
-
- Servicio de integracioacuten continua
-
- DevOps
- Integracioacuten Continua
- Jenkins con Nomad
- Jenkins con DCOS
-
- Escalando la infraestructura
-
- Disentildeo
- Implementacioacuten
-
- Resultados y conclusiones
-
- Comparacioacuten
- Conclusiones
- Objetivos conseguidos
- Liacuteneas de investigacioacuten
-
Planificacioacuten de estado compartido
Muacuteltiples reacuteplicas del estado del cluster se actualizan independientementepara cada planificador como se observa en la figura 5 cuando sucede un cambiode forma local el planificador se encarga de informar al resto
Ejemplo de este tipo son Omega la evolucioacuten de Borg por parte de GoogleMicrosoft Apollo y Nomad que usaremos para los casos de uso
De entre las desventajas se puede destacar el hecho de que en general losnodos trabajan con informacioacuten desactualizada lo que conlleva una degradacioacutendel rendimiento en situaciones de alta contienda
Figura 5 Planificador de estado compartido
Planificacioacuten distribuida
En este caso no existe coordinacioacuten entre los distintos planificadores Cadauno de ellos funciona con su propia vista del cluster Las tareas pueden serorganizadas por cualquiera de ellos y desplegadas en cualquier parte del clusteren base a la aleatoriedad y multiplexacioacuten estadiacutestica de los flujos de trabajosin ninguacuten control central
Figura 6 Planificador distribuido
12
5 Herramientas
En la industria comienzan a aparecer soluciones software de coacutedigo abiertoque aglutinan los servicios necesarios para gestionar la infraestructura TI de ma-nera maacutes eficaz El objetivo es doble se busca facilitar la gestioacuten de los recursosde computacioacuten para organizaciones con instalaciones propias mediante su usocon un enfoque cloud esto es desplegar aplicaciones a traveacutes de un conjuntode ordenadores de forma transparente y sin tener en cuenta la infraestructurasubyacente o aprovechar el maacuteximo rendimiento de la infraestructura de losproveedores cloud puacuteblicos de forma que se tiene el maacuteximo control sobre eacutestapero no se depende de las soluciones propietarias permitiendo asiacute despliegueshiacutebridos
Entre estas herramientas se pueden destacar
OpenStack Proyecto desarrollado por la fundacioacuten del mismo nombre paraproporcionar servicios de infraestructuras (IaaS) basado en componentesque se comunican a traveacutes de APIs El componente Magnum incluye mo-tores de orquestacioacuten de contenedores
Kubernetes Sistema de orquestacioacuten de contenedores Docker creado por Goo-gle
CoreOs Sistema operativo basado en Linux disentildeado para despliegues distri-buidos sobre contenedores incluyendo mecanismos de descubrimiento deservicio y comparticioacuten de configuracioacuten
Docker Swarm Herramienta nativa de orquestacioacuten de contenedores Docker
YARN Entorno de gestioacuten de recursos y aplicaciones distribuidas de Hadoopuna libreriacutea software de procesamiento de grandes conjuntos de datos
Como podemos observar existe un gran rango de opciones para gestionar lainfraestructura desde un bajo nivel como puede ser OpenStack hasta Kuberne-tes o Docker Swarm que ofrecen exclusivamente orquestacioacuten de contenedores
En este trabajo se ha optado por Mesosphere DCOS y HashiCorp Nomadque se encuentran en el teacutermino medio su objetivo es proporcionar serviciosde plataforma que permitan la coexistencia dediferentes cargas de trabajo en elcluster
13
51 DCOS
DCOS es un proyecto de coacutedigo abierto7 creado y desarrollado por la empre-sa Mesosphere Se describe como un sistema operativo distribuido que abstraelos recursos de un cluster (capacidad de procesamiento memoria) permite lagestioacuten de muacuteltiples ordenadores de forma transparente y simplifica la instala-cioacuten de aplicaciones distribuidas
Su arquitectura se puede comparar a la de Linux en teacuterminos de nuacutecleo(kernel) y espacio de usuario El primero consta de recursos protegidos a losque no puede acceder el usuario e involucra operaciones de bajo nivel comoasignacioacuten de recursos o aislamiento de procesos En el espacio de usuario seejecutan las aplicaciones y servicios de maacutes alto nivel
Siguiendo con este siacutemil el nuacutecleo de DCOS estaacute basado en Apache Mesosque se explicaraacute en un apartado posterior y el espacio de usuario que estaacute com-prendido por los componentes del sistema esto es las diferentes herramientasque en conjunto conforman DCOS y los servicios encargados de planificar yejecutar las aplicaciones y tareas del usuario
Figura 7 Arquitectura DCOSFuente httpsdcosio
De entre los componentes que conforman DCOS destacan
Admin Router Balanceador de carga central basado en NGINX que dis-pone un proxy entre todos los servicios en el puerto 80 permitiendo sugestioacuten mediante la interfaz graacutefica Ademaacutes se encarga de la autenticacioacutenpara acceder al panel de administracioacuten
Cosmos Gestor de paquetes de las aplicaciones
Diagnostics Se ejecuta en todos los nodos y se encarga de monitorizar elestado de los daemons que sustentan DCOS
7Desde abril de 2016 httpsmesospherecomblog20160419open-source-dcos
14
Exhibitor Gestiona y automatiza el despliegue de ZooKeper la herra-mienta que provee de configuracioacuten centralizada y registro de nombres
Marathon Equivale al proceso init de los sistemas tipo Unix esto es elprimer proceso en ejecucioacuten tras la carga del kernel y que genera los demaacutesprocesos Se encarga de arrancar y monitorizar las aplicaciones y servicios
Mesos-DNS Servicio de DNS interno que define el dominio mesos pa-ra nodos y tareas en el cluster es decir permite resolver nombres conindependencia de la direccioacuten fiacutesica
Minuteman Balanceador de carga integrado a nivel TCPUDP disponiblepara las propias aplicaciones
Por otra parte se definen como servicios a las diferentes aplicaciones dis-tribuidas que DCOS permite instalar en el cluster y que pueden haber sidodesarrollados por la misma empresa Mesosphere o por terceros por ejemploApache Spark Jenkins o Apache Hadoop En la figura 8 se muestra un diagramade los servicios disponibles incluyendo algunos de las aplicaciones distribuidasque soporta DCOS
Figura 8 Servicios DCOSFuente httpsdcosio
511 Apache Mesos
El nuacutecleo de DCOS estaacute basado en Apache Mesos un proyecto de coacutedigoabierto creado por la Universidad de California Berkeley y desarrollado actual-mente por la fundacioacuten Apache Se trata de un administrador de clusters queabstrae los recursos y los dispone para diferentes aplicaciones y entornos de tra-bajo distribuidos (frameworks) mediante una interfaz comuacuten En el momento deredaccioacuten de este proyecto Apache Mesos soportaba una variedad de entornosque abarcaba desde Big Data (Apache Spark Hadoop) hasta bases de datos(Cassandra Hypertable)
15
Arquitectura
Mesos se basa en la asignacioacuten de dos roles diferentes a los nodos
Maestros (Masters) Se encargan de la gestioacuten y reparticioacuten de los recursospara los diferentes entornos de trabajo mediante ldquoofertas de recursosrdquo deacuerdo a los disponibles y a la poliacutetica de asignacioacuten (planificacioacuten en dosniveles)
Esclavos (Slaves) Ordenadores donde se ejecutaraacuten las aplicaciones y cu-yos recursos son ofertados por los maestros
En el caso de fallo del maestro las tareas pueden seguir ejecutaacutendose perono se podraacute asignar nuevos recursos ni tareas por ello pueden existir varios enel cluster para configuraciones de alta disponibilidad pero soacutelo uno orquesta alos esclavos
Para la eleccioacuten del master liacuteder Mesos usa Apache ZooKeeper un proyectode software desarrollado por la misma fundacioacuten cuyo objetivo es proveer deun servicio de configuracioacuten centralizado y registro de nombres8
Por otra parte los entornos de trabajo son los programas que deciden final-mente queacute recursos se van a usar y se encargan de que los esclavos ejecuten lastareas Eacutestos se ejecutan sobre Mesos y constan de dos componentes
Planificador (Scheduler) Optimiza y decide los recursos a utilizar de losofertados informando a los Masters
Procesador (Executor) Ejecuta las aplicaciones o servicios en los esclavos
El objetivo final es conseguir una interfaz liviana tolerante a fallos paracualquier tipo de entorno de trabajo de tal manera que en los esclavos del clusterpuedan ejecutarse simultaacuteneamente tareas con necesidades y duracioacuten diferentesPara ello se basa en dos conceptos asignacioacuten y aislamiento de recursos
Asignacioacuten de recursos
En el cluster pueden coexistir entornos de trabajo con tareas de larga dura-cioacuten y con gran consumo de recursos con tareas cortas que los ocupan y liberancon rapidez El maestro integra un moacutedulo de asignacioacuten de recursos (allocationmodule) que se encarga del algoritmo de distribucioacuten
En el momento de escribir este proyecto estaban desarrollados dos moacutedulosuno mediante el cual el usuario puede asignar prioridades y otro que implementa
8httpszookeeperapacheorg
16
el algoritmo Dominant Resource Fairness9 a grandes rasgos se determina entodos los esclavos la tarea en ejecucioacuten que necesita maacutes recursos y se calcula laproporcioacuten del recurso de mayor peso con respecto al total por ejemplo si unatarea ocupa 2 GB de memoria con respecto a 10 GB totales que tiene el clusterse le asigna un dominant share del 20 la tarea se asignaraacute al nodo con menordominant share
Aislamiento de recursos
Para conseguir que tareas de diferentes entornos de trabajo y con distin-ta naturaleza se ejecuten simultaacuteneamente en un mismo nodo Mesos usa loscontenedores Linux (descritos en la seccioacuten 3)
Funcionamiento
La figura 9 muestra el esquema de la arquitectura de Apache Mesos conalta disponibilidad (tres maestros) y con dos entornos de trabajo ejecutaacutendo-se Hadoop que permite el almacenamiento y procesamiento de gran cantidadde datos para proyectos de big data y un sistema que implementa la interfazsistema de paso de mensajes MPI
Como se puede observar el sistema ZooKeeper elige a un solo maestro comoliacuteder y eacuteste orquesta el cluster comunicando los esclavos con los planificadoresde los diferentes entornos de trabajo Tambieacuten se puede observar como las tareasde los distintos entornos estaacuten distribuidas entre los tres esclavos disponibles
Figura 9 Arquitectura de Apache MesosFuente httpsmesosapacheorg
El proceso de asignacioacuten se realiza como sigue en primer lugar un usuariosolicita la ejecucioacuten de una tarea mediante la interfaz de cada entorno de traba-jo (interfaz graacutefica API HTTP ) De forma paralela un esclavo informa almaestro de los recursos que tiene libres En consecuencia eacuteste se lo notifica almoacutedulo de asignacioacuten que en funcioacuten de su configuracioacuten decide cuaacutento ofertar
9httpspeopleeecsberkeleyedu~aligpapersdrfpdf
17
y a queacute entorno de trabajo y enviacutea la oferta a los planificadores Eacutestos respondenal maestro con queacute recursos ha decidido usar para cada tarea Finalmente lastareas son enviadas al esclavo seleccionado el cual asigna los recursos indicadosal procesador (executor) quien finalmente las ejecuta
Cabriacutea pensar que esta metodologiacutea puede conducir a situaciones en lasque un entorno podriacutea quedarse con tareas sin ejecutarse a la espera de unaoferta satisfactoria para ello Mesos implementa un sistema de filtros medianteel cual los entornos especifican los requisitos miacutenimos que debe cumplir unaoferta por ejemplo se puede especificar en queacute nodos debe desplegarse la tareaEste sistema estaacute disentildeado asiacute con el objetivo de mantener lo maacutes transparenteposible esta herramientas de forma que acepte entornos de trabajo de distintasnaturalezas
512 Ejemplos de uso
Grandes empresas estaacuten usando Apache Mesos con eficacia de acuerdo a susnecesidades e infraestructuras Caben destacar
Ebay En el modelo de implementacioacuten continua en esta empresa10 cadadesarrollador cuenta con su propia instancia que se ejecuta en una maacutequinavirtual dedicada lo que ha conllevado un uso de los recursos poco eficiente Enuna prueba de concepto consiguieron realizar una herramienta de integracioacutencontinua distribuida basada en un cluster con Apache mesos y con el entornoMarathon y Jenkins
Apple Anuncioacute que el motor de su famosa herramienta de asistencia per-sonal para iPhones Siri estaacute desplegada sobre Apache Mesos11 Para ello handesarrollado su propio entorno para facilitar a los ingenieros a desplegar los ser-vicios que la herramienta necesita para resolver las peticiones de los usuarios
Twitter Desarrolloacute su propio entorno denominado Aurora y actualmentegestionan sus recursos y miden el coste de las tareas que los empleados usancon el objetivo de que sean conscientes del gasto que puede suponer un usoinadecuado de la infraestructura12
10httpwwwebaytechblogcom20140404delivering-ebays-ci-solution-with-apache-mesos-part-i11httpwwwbusinessinsidercomapple-siri-uses-apache-mesos-2015-812httpswwwlinuxcomNEWS4-UNIQUE-WAYS-UBER-TWITTER-PAYPAL-AND-HUBSPOT-USE-APACHE-MESOS
18
52 Nomad
Herramienta de coacutedigo abierto de gestioacuten de clusters creada y desarrolladapor Hashicorp13 que permite el despliegue de aplicaciones y procesos de formadistribuida
Las principales diferencias con Apache Mesos a grandes rasgos son
Arquitectura maacutes ligera Nomad soacutelo requiere de un fichero para funcionarejecutaacutendolo con las correspondientes configuraciones en todos los nodosrealiza las funciones de gestioacuten del cluster eleccioacuten de liacuteder planificacioacutende recursos y ejecucioacuten de las tareas
Centro de datos y regiones muacuteltiples Su arquitectura estaacute orientada afacilitar la gestioacuten de diferentes centros de datos geograacuteficamente distri-buidos
Entorno de ejecucioacuten Las tareas se definen y son interpretadas mediantecontroladores integrados en Nomad que se valen de los recursos y herra-mientas de los nodos clientes para ejecutarlas Esta integracioacuten dificultael desarrollo de controladores por parte de terceros a diferencia de Mesosque delega dicha responsabilidad en los entornos de trabajo externos alproyecto
Usa un planificador de estado compartido con respecto a la planificacioacutenen dos niveles de Mesos
Antes de entrar en maacutes detalle en la arquitectura es importante definir lossiguientes teacuterminos
Controlador (Driver) Software que se encarga de interpretar las definicionesde las tareas y ejecutarlas semejante a los procesadores de los entornosde trabajo de Mesos A la hora de redactar este proyecto Nomad contabacon controladores para contenedores Docker virtualizacioacuten de maacutequinasmediante el emulador QEMU aplicaciones java y archivos binarios
Grupo de trabajo (Task Group) Conjunto de tareas que se ejecutan en elmismo nodo cliente
Trabajo (Job) Conjunto loacutegico de tareas y grupos de trabajo que se despliegana la vez
Asignacioacuten (Allocation) Relacioacuten entre un grupo de trabajo y el cliente don-de se ejecuta
Evaluacioacuten (Evaluation) Proceso mediante el cual Nomad planifica y ges-tiona el registro o actualizaciones de los trabajos
13httpswwwhashicorpcom
19
Nomad sigue una arquitectura maestro-esclavo similar a la de Apache Mesosmuacuteltiples servidores acuerdan entre siacute un liacuteder que gestiona la planificacioacuten detareas en los clientes que soacutelo conocen sus asignaciones y las ejecutan
Todos los servidores participan paralelamente en tareas de planificacioacuten derecursos y asignacioacuten de tareas y ademaacutes entre ellos eligen un liacuteder que seencarga de la coordinacioacuten de la suscripcioacuten de los clientes al cluster y de lagestioacuten de las peticiones
Los clientes estaacuten configurados para comunicarse con el servidor usando lla-madas a procedimiento remoto (RPC por sus siglas en ingleacutes) que permite unordenador ejecutar coacutedigo en otra maacutequina Mediante esta tecnologiacutea los nodosclientes avisan de su estado e informa de sus asignaciones recursos y controla-dores disponibles
Existe la posibilidad de gestionar varios centros de datos agrupados en regio-nes eacutestas son independientes pero permite definir tareas o comprobar el estadode todas ellas desde cualquier punto A continuacioacuten se muestra una figura dela arquitectura a alto nivel de esta configuracioacuten
Figura 10 Arquitectura multi-regioacuten en NomadFuente httpswwwnomadprojectio
La herramienta se sustenta sobre tres protocolos fundamentales un protocolode consenso entre los servidores para compartir informacioacuten sobre su estado yel liacuteder un protocolo Gossip para la gestioacuten entre regiones y el planificador detareas
521 Protocolo de consenso Raft
El objetivo es obtener consistencia en un conjunto de nodos que comparteninformacioacuten es decir si un cliente realiza un cambio que todos los nodos veanla misma informacioacuten a la vez y ademaacutes sea tolerante a fallos Para ello se basaen el algoritmo Raft[13] que se detalla brevemente a continuacioacuten
20
Los nodos participantes en el algoritmo pueden estar en tres estados
Liacuteder (Leader) Todos los cambios que realicen en el cluster pasan por eacutel pri-mero
Seguidor (Follower) Nodo pasivo cuya responsabilidad es responder a laspeticiones del nodo liacuteder
Candidato (Candidate) Maacutequina que no ha encontrado liacuteder y solicita sueleccioacuten
Supongamos que tenemos cinco equipos que acaban de arrancar el protocoloEn la figura 11 se observan los nodos y sus respectivos registros a la derecha
Figura 11 Equipos sin consenso ejecutando el protocolo RAFTFuente httpsgithubcomongardieraftscope
Al comenzar todos los nodos son seguidores esperando recibir comunicacioacutende un nodo que actuacutee como liacuteder Cada nodo tiene un tiempo de espera aleatoriodespueacutes del cual si no es informado por un liacuteder pasa a estado candidato y pideel ldquovotordquo al resto de los participantes El algoritmo divide el tiempo en plazos uncandidato pasa a liacuteder si recibe la mayoriacutea de los votos en un plazo determinadoSe define mayoriacutea o cuoacuterum (quorum) comolceil
N2rceil
+ 1 (1)
donde N representa el nuacutemero de nodos
Para el ejemplo propuesto de 5 equipos se requieren de 3 votos Soacutelo losnodos que se encuentren en estado seguidor pueden votar una uacutenica vez a laprimera solicitud que reciba dentro de un plazo
Supoacutengase que el nodo denotado con S1 ha cumplido su tiempo de espera yrealiza la peticioacuten de voto (figura 12) A partir de este momento se pueden dartres casos
La maacutequina gana la eleccioacuten y pasa a ser liacuteder informando al resto
Otro servidor se establece como liacuteder en el mismo momento
Varios nodos pasan a ser candidatos por lo que ninguno consigue los votos
21
Figura 12 Un equipo pasa a estado candidato (RAFT)
Si un candidato recibe un aviso de un liacuteder en el mismo plazo el primeropasa a ser seguidor y se acaba la eleccioacuten de liacuteder
Por otro lado si un equipo candidato no recibe los votos en el plazo y agotasu tiempo de espera avanza al siguiente plazo y repite el proceso de votacioacutenLa tercera posibilidad puede conllevar a un estado indefinido ya que varioscandidatos pueden agotar su tiempo de espera al mismo tiempo y repartir losvotos Para solventarlo el algoritmo establece tiempos de espera aleatorios paralos candidatos
Siguiendo con el ejemplo propuesto el servidor S1 pasa a ser el liacuteder Cadacierto tiempo eacuteste debe realizar avisos a los nodos seguidores para no agotar sutiempo de espera
En este momento el cluster de servidores estaacute en ldquoconsensordquo y la informacioacutenen todos los nodos estaacute actualizada Un cambio en la informacioacuten inicia unproceso de replicacioacuten el liacuteder registra el cambio lo pasa al resto de nodos yuna vez eacutestos responden el cambio se hace efectivo
Supoacutengase que se realiza un cambio en los datos en la figura 13 en la partederecha se observa el cambio en el registro del servidor S1 que informa a losnodos seguidores En consecuencia los nodos registran el cambio y responden aS1
Figura 13 Cambio en un registro (RAFT)
Una vez el cuoacuterum (en el ejemplo tres equipos) informa al liacuteder de que
22
ha registrado el cambio el liacuteder lo hace efectivo en su sistema y notifica a losnodos que hacen lo mismo En la figura 14 el enviacuteo todaviacutea no ha llegado ala maacutequina S3 y se observa que no ha hecho efectivo el cambio (en el registroaparece punteado)
Figura 14 Aprobacioacuten del resto de equipos (RAFT)
Este protocolo funcionaraacute correctamente mientras exista un nuacutemero de nodosen funcionamiento igual o superior al cuoacuterum en el ejemplo propuesto elcuoacuterum es tres por lo que el sistema puede tolerar la caiacuteda de dos de los equipos
522 Protocolo gossip SWIM
Nomad permite la gestioacuten simultaacutenea de varios centros de datos reparti-dos en regiones geograacuteficamente separadas requiriendo de un protocolo ligeroque mantenga a los miembros actualizados sobre los participantes del conjun-to Para ello usa una ligera variante del protocolo SWIM[3] (Scalable Weakly-consistent Infection-style Process Group Membership Protocol) desarrollada porHashiCorp Estaacute clasificado como un protocolo de tipo gossip que debe su nom-bre a la semejanza con coacutemo se distribuye un rumor en una red social
SWIM se sustenta en dos caracteriacutesticas fundamentales la deteccioacuten de fallosy la distribucioacuten de la informacioacuten relativa a los miembros A continuacioacuten sedetalla el funcionamiento de ambos componentes
Deteccioacuten de fallos
Este componente tiene dos paraacutemetros el periodo de protocolo T y el nuacutemerode subgrupos de deteccioacuten de fallos k en los que se dividen los nodos Paracomprobar la comunicacioacuten entre dos maacutequinas usa la utilidad ping basadaen el protocolo ICMP La deteccioacuten de caiacuteda de un servidor sigue el siguientealgoritmo
Durante el periodo T cada miembro Mi de un subgrupo elige otro al azar Mjdel mismo subgrupo y le enviacutea un mensaje ping para comprobar su estado Enel caso de que se cumpla un tiempo de espera determinado por una estimacioacuten
23
del tiempo de ida y vuelta (RTT por sus siglas en ingleacutes) de la red y no hayarespuesta Mi le vuelve a enviar un mensaje ping indirectamente a traveacutes deun nuacutemero k de miembros escogidos aleatoriamente De no recibir ninguna res-puesta Mi establece que Mj ha sufrido un fallo y lo etiqueta como ldquosospechosordquoinformando al componente de distribucioacuten
Figura 15 Diagrama de tiempo del protocolo SWIMFuente httpswwwcscornelledu
Componente de distribucioacuten
Se encarga de informar de cualquier cambio en los miembros a todo el con-junto Los eventos de nodo caiacutedo y la unioacuten o disociacioacuten de un miembro setransmiten a todos los servidores para que actualicen sus lista Para distribuirla informacioacuten a todos los nodos se podriacutea usar el meacutetodo de multicast perosuele estar deshabilitado Por ello se utiliza una teacutecnica de transmisioacuten denomi-nada Piggybacking mediante la cual se adjunta a los propios mensajes PINGy ACK del algoritmo la informacioacuten a distribuir reduciendo asiacute la congestioacutenen la red
523 Planificacioacuten
Proceso encargado de distribuir las tareas entre los nodos clientes de acuerdoa su estado
El planificador de Nomad estaacute basado en las publicaciones de Google sobresus herramientas de gestioacuten de clusters Borg y Omega14 y entiende los trabajosdescritos por el usuario como un estado deseado es decir su despliegue en unamaacutequina cliente de forma correcta y los clientes como el estado actual esto eslo que se encuentra en ejecucioacuten El registro actualizacioacuten o cancelacioacuten de un
14httpresearchgooglecompubspub43438html
24
trabajo asiacute como el fallo de un nodo cliente implican un cambio de estado atramitar por el sistema lo que se define como evaluacioacuten (evaluation) Esto uacutelti-mo supone comparar el estado actual (clientes) con el estado deseado (conjuntode trabajos registrados) y enviarlos a los planificadores correspondientes que seencargaraacuten de asignar las tareas a los nodos clientes
Figura 16 Procedimiento de asignacioacuten en NomadFuente httpswwwnomadprojectio
En la figura 16 se observa el flujo de trabajo en el que las distintas evalua-ciones se encolan en el evaluation broker que se ejecuta en el servidor liacuteder ygestiona las evaluaciones pendientes asignaacutendoles prioridades
A continuacioacuten los nodos servidores ejecutan los scheduling workers queprocesan las evaluaciones llamando a los distintos planificadores que generanun plan de asignacioacuten esto es un conjunto de relaciones entre las tareas y losnodos clientes donde se ejecutaraacuten Este proceso se divide en dos fases primerose descartan aquellos clientes que no cumplan los requisitos y posteriormentese asigna una calificacioacuten al resto Se selecciona el nodo con mayor puntuacioacuteny se encola el plan en el gestor que se ejecuta en el servidor liacuteder Existen tresplanificadores de acuerdo al tipo de trabajo
Service Incluye aquellos trabajos que estaacuten destinados a ejecutarse en un pe-riacuteodo largo de tiempo Para realizar las asignaciones el planificador evaluacuteala mayor parte de los nodos y usa una versioacuten del algoritmo Best fit in-fluenciada por el trabajo de Google en su herramienta Borg Se trata deun algoritmo de planificacioacuten que sacrifica tiempo a cambio de maximizarel rendimiento de los clientes asignando la tarea a la maacutequina que tengala mayor carga de trabajo con el objetivo de reducir equipos en funciona-
25
miento
Batch Tareas que incluyen listas de comandos en general de menor duracioacuteny que no requieren interaccioacuten con el usuario Se vale del algoritmo deSparrow desarrollado por la universidad de Berkeley15 para limitar losnodos clientes a evaluar
System Trabajos destinados a ejecutarse en todos los nodos incluso los que seunen al cluster posteriormente
Core Mantenimiento interno de Nomad
Una vez se ha realizado el proceso de planificacioacuten el nodo liacuteder lo registra enla cola de planes (plan queue) que se encarga de asignarles prioridad y manejarcondiciones de carrera es decir que no accedan a los recursos de los clientes sincontrol y evitar que eacutestos superen su capacidad
La maacutequina liacuteder del conjunto puede de este modo aceptar una asignacioacuteny ser ejecutada por los clientes o por el contrario rechazaacutersela al planificadorlo que implicariacutea realizar un plan parcial o totalmente nuevo
Finalmente el estado de las evaluaciones se actualizan y los clientes soninformados de las asignaciones ejecutaacutendose las tareas
15httppeopleeecsberkeleyedu~keopublicationssosp13-final17pdf
26
6 Casos de uso y despliegue
Con el objetivo de mostrar las posibles utilidades que este tipo de sistemaspueden tener en las infraestructuras TI actuales se han desplegado las dos he-rramientas en la nube Microsoft Azure usando su servicio cloud de instancias demaacutequinas virtuales Linux para simular un conjunto de ordenadores conectadosentre siacute por una red LAN Sobre ellas se ha implementado dos casos de usouna aplicacioacuten web con una arquitectura con cierta orientacioacuten a microserviciosy un sistema de integracioacuten continua
El coacutedigo y todos los ficheros de configuracioacuten se pueden encontrar en elrepositorio del proyecto en GitHub16
61 Aplicacioacuten Web
Se busca simular el proceso de adaptacioacuten de una solucioacuten web para su des-pliegue en un sistema distribuido con las herramientas anteriormente descritascon el objetivo de aumentar tanto su escalabilidad como disponibilidad medianteredundancia
Se ha partido de una aplicacioacuten ya existente17 un servicio de almacenamien-to y reproduccioacuten de canciones A grandes rasgos este servicio permite crearusuarios subir canciones con sus respectivas portadas tener playlists propias yescuchar las canciones a traveacutes de un navegador web
La solucioacuten estaacute dividida en 4 partes (figura 17)
Una vista web con la loacutegica
Un almacenamiento conectado en red (NAS por sus siglas en ingleacutes)
Una API REST para gestionar las peticiones al almacenamiento
Base de datos NoSQL basada en MongoDB
La nueva tendencia de los proyectos web es su implementacioacuten en contene-dores Docker ya que facilitan su portabilidad y ofrecen un procedimiento dedespliegue raacutepido sobre todo a la hora de desarrollar y realizar pruebas en en-tornos de produccioacuten simulados Por ello en este caso se va a hacer uso de los
16httpsgithubcomAntonioAlfrzCloud-Orchestrators17httpsgithubcomsonsoleslpCDPSfy
27
motores de orquestacioacuten de contenedores de ambas herramientas Marathon enDCOS y el controlador Docker en el caso de Nomad
Figura 17 Arquitectura aplicacioacuten web
A continuacioacuten vamos detallar el despliegue en ambas herramientas de es-ta solucioacuten y observar tanto queacute dificultades se encuentran como que ventajasofrecen El objetivo final es adaptar el proyecto modificaacutendolo lo menos posiblecon objeto de analizar la capacidad de estas herramientas para desplegar cual-quier aplicacioacuten sin que eso conlleve la modificacioacuten de la arquitectura de eacutestaes decir que no sea dependiente del entorno
611 DCOS
Se ha descrito DCOS como una herramienta que se despliega sobre un con-junto de ordenadores y que permite instalar gestionar el despliegue de sistemasdistribuidos
Microsoft Azure cuenta con una plantilla para desplegar en su servicio cloudun cluster de maacutequinas virtuales con DCOS ya instalado que cuenta con
Maacutequinas maestras (1 3 o 5 a seleccionar por el usuario) configuradascomo un conjunto de disponibilidad esto eso Azure da ciertas garantiacuteasde que al menos una maacutequina estaraacute en funcionamiento
Maacutequinas agentes Por motivos de seguridad se distinguen dos roles
bull Nodos privados solo accesibles desde la red interna y configuradoscomo un conjunto de escala un recurso de Azure para gestionar ydesplegar maacutequinas con configuraciones ideacutenticas para permitir unraacutepido escalado
bull Un equipo conectado accesible desde Internet a travntildees de un balan-ceador de carga puacuteblico y situado en una subred externa
28
Dos balanceadores de carga
bull La interfaz puacuteblica del cluster que se conecta con el cliente puacuteblicobull Acceso a los equipos maestros para el administrador que soacutelo permiteconexioacuten mediante SSH y credenciales
Almacenamiento para todas las maacutequinas
Configuraciones necesarias de red y seguridad
En la figura 18 se observa un diagrama de la infraestructura
Figura 18 Infraestructura en Azure
El primer obstaacuteculo es la persistencia de estado de la aplicacioacuten que seconsigue gracias a una base de datos no relacional basada en MongoDB asiacutecomo el almacenamiento de las canciones Para implementarla tenemos variasposibilidades
Montar un sistema externo de almacenamiento conectado en red en todoslos agentes donde se ejecuten las tareas de esta manera si una tarea pasade un nodo a otro por cualquier motivo puede tener acceso a los mismosficheros (opcioacuten del caso de uso original)
Implementar un sistema de ficheros distribuidos en los agentes
Usar los servicios de almacenamiento de las nubes puacuteblicas
Aprovechar el sistema de voluacutemenes persistentes de Apache Mesos Eacutestepermite reservar recursos de un agente de forma que al arrancar una tarease crea un volumen independiente del ciclo de vida de eacutesta con ello esosrecursos donde se ha almacenado la informacioacuten pueden volver a ofrecerseal mismo entorno de tal manera que otra tarea pueda acceder a ella
DCOS aprovecha este sistema de voluacutemenes persistentes y permite instalarbases de datos distribuidas como ArangoDB o Apache Cassandra sin embargoesto implicariacutea modificar todo el coacutedigo referente al modelo de la base de datos
29
Por motivos de eficiencia y latencia asiacute como de una mayor gobernabilidadde los datos la mejor opcioacuten es usar el recurso de voluacutemenes persistentes queofrece Apache Mesos ya que de esta manera se gestionariacutea la aplicacioacuten completamediante una uacutenica herramienta Sin embargo esto implica que la informacioacutense encuentra exclusivamente en el agente donde se haya ejecutado la tarea y porlo tanto se sigue requiriendo de software externo para distribuir la informacioacutenpara que se accesible para todos los agentes A la hora de realizar este proyectose encontraba en desarrollo Flocker una solucioacuten desarrollada por ClusterHQque permite compartir los voluacutemenes de Docker a traveacutes de un cluster quesi bien es compatible con el planificador de Mesos el proyecto se encontrabatodaviacutea en fases tempranas de desarrollo y los sistemas de almacenamiento quesoporta quedaban fuera del aacutembito de este trabajo
Por todo ello dado que las maacutequinas se han desplegado en la nube puacuteblicade Azure se decidioacute usar su servicio de almacenamiento de objetos para lascanciones y otra maacutequina para desplegar MongoDB y asiacute mantener el modelode datos original de la aplicacioacuten La diferencia del almacenamiento de obje-tos con respecto a nivel de fichero es que el primero no tiene jerarquiacutea paraorganizar los archivos eacutestos se guardan como objetos (con sus metadatos) enun mismo espacio soacutelo diferenciaacutendose por un identificador uacutenico esto implicaentre otras cosas que se puede acceder a un fichero dado uacutenicamente su IDindependientemente de la localizacioacuten fiacutesica de eacuteste facilitando pues la gestioacuteny el desarrollo
El coacutedigo del proyecto se ha modificado en los siguientes apartados
Las direcciones de la base de datos y los balanceadores de carga asiacute comosus puertos estaban originalmente fijos Se han configurado como variablesde entorno para facilitar el descubrimiento del servicio y hacer transpa-rente la aplicacioacuten al entorno de despliegue
La API REST se ha adaptado al almacenamiento en Azure en vez de enlocal
Estas modificaciones no suponen un cambio sustancial pero permiten separala persistencia de las tareas ejecutadas por DCOS lo que facilita en granmedida su ejecucioacuten al ser totalmente sin estado y ademaacutes implican tenerlos datos bajo un mayor control
Para la orquestacioacuten de contenedores se va a usar el entorno Marathondesarrollado tambieacuten por Mesosphere Eacuteste se puede usar a traveacutes de una interfazgraacutefica la interfaz de liacutenea de comandos (en lo que sigue CLI por sus siglas eningleacutes) de DCOS o con su API HTTP
Primero se han publicado la imaacutegenes de los contenedores que encapsulanla interfaz web y la api de la aplicacioacuten en el repositorio puacuteblico DockerHub
Los despliegues en este entorno se describen mediante ficheros JSON en losque se detalla entre otras opciones la imagen del contenedor los puertos a usar
30
los recursos que debe ocupar en un nodo o las instrucciones de monitorizacioacuten
Para el servicio de descubrimiento DCOS ofrece la posibilidad de asignardirecciones IP virtuales (VIP por sus siglas en ingleacutes) a tareas que se compartenen todos los nodos DCOS lleva integrado un balanceador de carga a nivel TCP(el componente denominado Minuteman) que balancea entre las direccionesvirtuales de las tareas y todas las instancias de eacutestas a lo largo del cluster Estoes necesario por dos motivos equilibrar la carga de los equipos con el fin deevitar un punto de uacutenico fallo mediante redundancia y evitar la contienda dedirecciones al ejecutar las tareas en puertos aleatorios
Este balanceador de carga estaacute basado en el trabajo de Michael Mitzenma-cher The Power of Two Choices in Randomized Load Balancing18 A grandesrasgos el algoritmo mantiene una media moacutevil exponencial de latencias paracada destino (backend) ademaacutes de las caiacutedas consecutivas Si un destino noresponde a una negociacioacuten en tres pasos (three way handshake) de forma con-secutiva en un periodo inferior a 5 ms se considera caiacutedo El algoritmo iterasobre los destinos disponibles en base a su histoacuterico de fallos y escoge dos deforma aleatoria de los cuales coge el de mejor meacutetrica
Las direcciones virtuales soacutelo se pueden resolver dentro del cluster porello para implementar la interfaz puacuteblica de la aplicacioacuten esto es el balancea-dor de carga de la interfaz web usaremos un paquete de DCOS denominadomarathon-lb un balanceador basado en HAProxy y adaptado por MesosphereEn este caso equilibra la carga de todas instancias de las tareas ejecutadas porel entorno Marathon por sus etiquetas y permite ademaacutes definir como puntode entrada muacuteltiples hosts virtuales definidos por sus nombres completos dedominio (FQDN por sus siglas en ingleacutes) en nuestro caso la interfaz puacuteblicadel balanceador de Azure para los agentes
Por motivos de seguridad todas las tareas se ejecutan en los agentes privadoses decir los que son exclusivamente accesibles desde la red interna Por su partemarathon-lb se ejecuta en el agente puacuteblico que cuenta con IP puacuteblica y lospuertos 80 (HTTP) y 8080 abiertos de forma que la aplicacioacuten sea accesibledesde Internet Esto es posible debido a que Apache Mesos permite reservarrecursos mediante roles asignados a nodos para un uso especiacutefico De esta formala arquitectura vista desde la aplicacioacuten quedariacutea como en la figura 19
18httpswwweecsharvardedu~michaelmpostscriptstpds2001pdf
31
Figura 19 Arquitectura de la aplicacioacuten web en DCOS
Ejecucioacuten
A la hora de desplegar la aplicacioacuten DCOS puede gestionarse medianteuna interfaz graacutefica o una interfaz de liacutenea de comandos La primera se accedea traveacutes de un navegador web en el puerto 80 (HTTP) y permite instalar losentornos disponibles observar el estado de los nodos y las tareas que se estaacutenejecutando y los ficheros de registros que eacutestas generan
La CLI permite el control desde un nodo o una maacutequina remota (suponiendoque los maestros tienen IP puacuteblica y el puerto 80 abierto) ya que DCOS tieneun sistema de autorizacioacuten que permite tener una interfaz puacuteblica con ciertasgarantiacuteas de seguridad
Por su parte cada entorno de trabajo puede ser controlado por la CLI peroademaacutes cuenta con sus propias interfaces Marathon expone una API HTTPen el puerto 8080 de la direccioacuten puacuteblica de los maestros del cluster asiacute comootra interfaz graacutefica Para desplegar un contenedor se podriacutea usar la CLI
$ dcos marathon app add lt f i l e j songt
O la API HTTP
$ cu r l minusX POST http lt ip_maestro gt8080v2apps minusd ltf i l e jsongt minusH Contentminustype app l i c a t i o n j son
32
612 Nomad
La arquitectura de Nomad es maacutes sencilla ya que solo requiere de un ficheroejecutable en todos los nodos para funcionar Si DCOS es la base de instala-cioacuten de entornos de terceros Nomad integra todas las funcionalidades baacutesicasesto es gestor de recursos planificador y ejecutor en los nodos cliente Estaherramienta cuenta con un menor tiempo de desarrollo y en el momento deescribir este documento cuenta exclusivamente con los siguientes controladoresen comparacioacuten con los entornos de DCOS
Motor Docker es decir funcioacuten de orquestacioacuten de contenedores
Ejecucioacuten de archivos binarios como comandos de Shell
Ejecucioacuten de aplicaciones Java
Virtualizacioacuten de maacutequinas mediante tecnologiacutea QEMU
Todos ellos necesitan que la tecnologiacutea subyacente esteacute instalada en las maacute-quinas clientes (Docker Java QEMU) Actualmente no permite el registro decontroladores por parte de terceros aunque estaacute planificado en un futuro ofreceruna interfaz para su desarrollo
Nomad no cuenta con el servicio de descubrimiento sin embargo puede inte-grarse con la herramienta Consul desarrollada por la misma empresa Por otrolado para el balanceo de carga usaremos un contenedor Docker con HAProxyuna herramienta de coacutedigo abierto que ofrece tanto servicios de proxy como debalanceador y cuyos ficheros de configuracioacuten completaremos con el proyectoConsul Template19
Consul
Consul sigue la misma arquitectura que Nomad es decir un nodo servidorque orquesta un conjunto de maacutequinas clientes y permite a los procesos que seejecutan en los equipos definirlos como servicios ofreciendo diversas caracteriacutes-ticas entorno a estos de los cuales vamos a usar dos
Descubrimiento de servicio Las maacutequinas clientes publican en el cataacutelogode servicios las tareas en ejecucioacuten y Consul les asigna nombres de dominioaccesibles por todos los miembros del cluster a traveacutes de la interfaz DNSincluida en esta herramientaConsul se integra con Nomad de forma que todas las tareas que se ejecu-ten en la segunda son automaacuteticamente publicados como servicios de laprimera de esta manera no hace falta conocer la direccioacuten de la maacutequinacliente donde se esteacute ejecutando el proceso ya que se puede acceder a eacutela traveacutes de su nombre de dominio de forma transparente Por ejemplo si
19[httpsgithubcomhashicorpconsul-template]
33
ejecutamos una tarea con ID web en el puerto 8080 se puede acceder aella en la direccioacuten webserviceconsul8080Para que las direcciones propias de Consul las resuelva su propio DNS y noel que esteacute asignado por defecto en la maacutequina usaremos la herramientadnsmasq20 que permite especificar la direccioacuten de un servidor DNS paraconsultas de direcciones especiacuteficas
Monitorizacioacuten Permite realizar comprobaciones del servicio y seguir su esta-do Aprovecharemos esta funcionalidad tanto para definir el propio procesode Nomad como servicio de Consul como las tareas desplegadas
HAProxy + Consul Template
HAProxy es una solucioacuten versaacutetil de coacutedigo abierto que ofrece solucionesde balanceo de carga y proxy Existen otras herramientas en el mercado comoNGINX o ldirectord sin embargo HAProxy suponiacutea una solucioacuten sencilla deconfigurar para mostrar el caso de uso
El uso de estas herramientas se debe a dos motivos para que no existacontienda con respecto a los puertos de los clientes usados por las tareas eacutestos sevan a asignar de forma dinaacutemica lo que en principio implicariacutea que la aplicacioacutendeberiacutea realizar consultas DNS de tipo SRV (que incluye puertos) a la interfazde Consul y balancear la carga entre tareas por redundancia y capacidad
Como la direccioacuten IP y puerto son variables cada vez que las tareas seactualicen o se reasignen es necesario volver a configurar HAProxy de formamanual Por ello HashiCorp ha desarrollado un programa denominado Con-sul Template que realiza peticiones sucesivas a la interfaz HTTP de Consul delas direcciones fiacutesicas de un servicio y reinicia automaacuteticamente el proceso deHAProxy Asiacute definiendo estas tareas como servicios Consul podremos tantomonitorizarlas como escalar las tareas dinaacutemicamente sin necesidad de cambiarel balanceador A partir del contenedor Docker oficial de HAProxy se ha desa-rrollado otro con la configuracioacuten baacutesica y con Consul Template para desplegarlocomo una tarea en Nomad
Despliegue
Se ha usado el mismo coacutedigo que en el apartado anterior con la persistenciaen el servicio de almacenamiento de Azure Desde la perspectiva del hardwarese implementaraacute la misma infraestructura que en el caso de DCOS (figura 18)estos es definiremos dos tipos de maacutequinas clientes un agente que se conectaraacutecon el balanceador de carga con nombre de dominio puacuteblico y donde se desple-garaacute el balanceador de carga de la vista web y agentes privados no accesiblesdesde fuera del cluster y donde se ejecutaraacuten el resto de tareas en la red inter-na La principal diferencia radica en las tareas que ejecutan HAproxy y ConsulTemplate que sustituye a las direcciones IP virtuales que ofrece DCOS
20httpwwwthekelleysorgukdnsmasqdochtml
34
Figura 20 Despliegue en Azure de Nomad+Consul
Cabe matizar que los balanceadores basados en HAProxy se implementanpor necesidad de la aplicacioacuten para el descubrimiento del servicio a diferenciade los de Azure que se implementan por motivos de seguridad y escalabilidaddel cluster en siacute
Configuracioacuten Nomad
Los ficheros de configuracioacuten de las maacutequinas maacutester y cliente son similaresy comparten la mayoriacutea de las opciones como por ejemplo el nombre del nodoo la interfaz de red donde escucha Nomad las peticiones Sus opciones son engeneral auto-explicativas sin embargo existen dos detalles que matizar
El proceso de Nomad escucha las peticiones tanto de los protocolos deconsenso como del usuario a traveacutes de una interfaz de red que se debeindicar en el fichero de configuracioacuten
En el caso de los clientes se deben indicar las direcciones de los servidoresdel cluster sin embargo se trata de un sistema dinaacutemico en el que losnodos pueden sufrir errores y cambiar de direccioacuten Por ello se ha definidoNomad como un servicio de Consul y asiacute poder definir la direccioacuten de losservidores como un nombre de dominio no por su direccioacuten fiacutesica que elservidor DNS de Consul se encargaraacute de resolver
Por defecto Nomad usa los siguientes puertos
API HTTP 4646 Peticiones HTTP y recepcioacuten de oacuterdenes mediante laliacutenea de comandos
RPC 4647 Protocolo de consenso entre los nodos del cluster
Serf 4648 Protocolo de gossip entre los servidores de los centros de datosgobernados por Nomad
35
Los dos uacuteltimos deben ser interfaces alcanzables por otros nodos sin embargo laAPI HTTP por motivos de seguridad deberiacutea ser local ya que en caso contrariocualquier persona con acceso a ella tiene el control sobre la herramienta Eacutestasolo deberiacutea estar accesible en un servidor o gestionarlo mediante una terminalSSH por ejemplo En este trabajo al ser una prueba de concepto se ha abiertoen todos los nodos
Trabajos de Nomad
Las tareas se detallan en ficheros con formato HashiCorp Configuration Lan-guage un derivado del formato JSON creado por la empresa que le da nombrecompatible con eacuteste y que permite comentarios
En estos ficheros se puede definir
La regioacuten y el centro de datos donde se ejecutaraacute (Nomad permite lagestioacuten de centros de datos geograacuteficamente distribuidos en regiones)
La poliacutetica de actualizacioacuten de la tarea
Grupo de tareas esto es que se ejecutaraacuten en el mismo nodo
El nuacutemero de grupos a ejecutarescalar asiacute como los liacutemite que debencumplir los nodos asignados
La poliacutetica de reinicio ante fallo o error
Tareas El controlador su configuracioacuten los paraacutemetros del servicio aso-ciado a registrar en Consul asiacute como los recursos que consume (puertosmemoria)
En nuestro caso usamos sobre todo el controlador Docker esto eso orques-tacioacuten de contenedores en los nodos clientes y tres de sus opciones
Imagen del contenedor Se han subido todas las imaacutegenes del proyecto a Doc-ker Hub donde por defecto se busca la imagen
Puertos Los puertos a usar por el contenedor que pueden ser estaacuteticos asigna-dos por el usuario o dinaacutemicos siendo Nomad el que se encarga de mapearun puerto libre del nodo cliente al expuesto por el contenedor
Servidores DNS Como usamos la interfaz DNS de Consul como descubri-miento de servicio se debe configurar el contenedor para que use cualquiernodo del cluster como servidor DNS
Configuracioacuten Consul
Al ser desarrolladas por la misma empresa los ficheros de configuracioacuten deConsul y Nomad comparten muchas opciones Consul tambieacuten acepta peticionesa traveacutes de una interfaz de red siendo los puertos usados por defecto
36
RPC 8300 8400 Maneja la peticiones del resto de nodos y usuarios
Serf 8301 8302 Protocolo gossip
HTTP API 8500
HTTPS API Desactivada por defecto
Interfaz DNS 8600
Se debe asignar a los protocolos internos del cluster esto es RPC y Serf unainterfaz alcanzable por los nodos y por el contrarioasignar a los dos uacuteltimos ala interfaz de loopback por motivos de seguridad
Cabe destacar que Consul tambieacuten cuenta con una interfaz graacutefica que per-mite ver el estado de los equipos y los servicios registrados y que se encuentra enel mismo puerto que la API HTTP en la direccioacuten httpIP_EQUIPO8500ui
Ejecucioacuten
Tanto Nomad como Consul requieren de la ejecucioacuten de un fichero en todoslos nodos integrantes del cluster Como prueba de concepto se ha decidido usardos servidores para ambos aunque cabe matizar que es un nuacutemero ineficienteya que la caiacuteda de uno de ellos supondriacutea la peacuterdida del cuoacuterum y por tantodel consenso del cluster
En primer lugar se arrancan los servidores que son los encargados de ejecu-tar el protocolo de consenso y gestionar el cluster y a continuacioacuten los clientesque no tienen praacutecticamente estado y dependen de los servidores
En el caso de Consul se debe indicar el directorio donde se guardan losficheros que describen los servicios asiacute como el archivo que especifica el resto delas opciones
1 Se inicia el primer servidor en uno de los equipos
$ consu l agent minuscon f i gminusd i r e t c consu l d s e r v i c e s minuscon f i gminus f i l e consu l_server j son
2 Los siguientes equipos deben unirse al anterior por lo que antildeadimos elargumento join con la direccioacuten del primer servidor Para el caso de otrosservidores
$ consu l agent minuscon f i gminusd i r e t c consu l d s e r v i c e s minuscon f i gminus f i l e consu l_server j son minus j o i n ltIP_servidor1gt
37
Una vez los servidores han alcanzado el consenso y elegido un liacuteder en losclientes
$ consu l agent minuscon f i gminusd i r e t c consu l d s e r v i c e s minuscon f i gminus f i l e c on su l_c l i en t j son minus j o i n ltIP_cualquierServ idorgt
El proceso para iniciar Nomad es igual y los comandos similares sin embargoya no es necesario indicar una direccioacuten IP fija en los equipos sino el nombre dedominio del servicio de Nomad registrado por Consul En el primer servidor
$ nomad agent minusc on f i g nomad_server j son
Y el resto de equipos (con su fichero de configuracioacuten correspondiente)$ nomad agent minusc on f i g nomad_server j son minus j o i n nomad s e r v i c e consu l
Por uacuteltimo para desplegar la aplicacioacuten web se han escrito tres ficherosque detallan las tareas de la interfaz web API y los balanceadores de cargaMediante la CLI
$ nomad run minusaddress=http lt ip_c lus te r gt4646 lt f i l e hclgt
O mediante la API HTTP de Nomad$ cu r l minusX POST minusd ltf i l e hclgthttp lt ip_c lus te r gt4646 jobltjob_namegt
Ansible
Como se puede comprobar con el aumento del nuacutemero de equipos pasa aser inviable manejar todos los nodos a traveacutes de terminal Ademaacutes como seha comentado con anterioridad Nomad requiere que en los nodos clientes es-teacuten instalados las herramientas que soporten las tareas por ejemplo el motorde Docker Por ello para facilitar tanto el arranque como la instalacioacuten de lasdependencias vamos a usar Ansible una herramienta de coacutedigo abierto desarro-llada en Python que permite gestionar configuraciones aprovisionar recursosdespliegue de aplicaciones de forma automaacutetica
A grandes rasgos esta herramienta funciona mediante ficheros en formatoYAML denominados play-books que describen un conjunto de pasos a ejecutaren una lista de equipos remotos Estos pasos son ejecutados por moacutedulos inde-pendientes a traveacutes de SSH es decir en cualquier ordenador con conexioacuten a los
38
hosts dado su contrasentildea o clave puacuteblica puede arrancar el script y realizariacutealos pasos de forma remota gestionando el cluster desde un solo equipo
Se han desarrollado guiones para lo siguiente
Descarga de los binarios de Nomad y Consul en todos los nodos copiade los ficheros de configuracioacuten baacutesicos y modificarlos de acuerdo a cadanodo (nombre del equipo direccioacuten IP)
Instalacioacuten de las dependencias
Arranque de Nomad y Consul
Ansible extiende su funcionalidad a traveacutes de moacutedulos independientes que per-miten por ejemplo instalar paquetes mediante herramientas de gestioacuten de pa-quetes (APT yum) aprovisionar automaacuteticamente maacutequinas virtuales de Ama-zon EC2
Algunas opciones de los ficheros de configuracioacuten de Nomad y Consul sondependientes del nodo particular por ejemplo la interfaz de red Para estetrabajo se ha realizado un moacutedulo para modificar los ficheros de configuracioacutende forma automaacutetica En el repositorio del proyecto se encuentra una carpetadonde se encuentran todos los ficheros necesarios para desplegar un clustertotalmente funcional solo requiere de una liacutenea de terminal con Ansible
$ ans ib l eminusplaybook minus i hos t s minusk ltssh_passgt minusu ltnode_usergt s i t e yml
39
62 Servicio de integracioacuten continua
Se ha implementado un sistema de integracioacuten continua que permite ejecu-tar tareas de compilacioacuten y pruebas de forma distribuida aumentando asiacute elrendimiento de los equipos En primer lugar se detallaraacute los motivos por los quepuede resultar beneficioso para las empresas una implementacioacuten de este tipo alo que seguiraacute los detalles del despliegue
621 DevOps
Metodologiacutea que defiende la comunicacioacuten y colaboracioacuten entre desarrolla-dores de software y los profesionales de operaciones a lo largo de todo el ciclo devida de una aplicacioacuten Estaacute muy relacionado con el desarrollo aacutegil de softwareesto es un enfoque para los proyectos que defiende el desarrollo iterativo e in-cremental donde los requisitos y soluciones evolucionan con el tiempo seguacuten lanecesidad del proyecto DevOps extiende esta filosofiacutea a todas los componentesde un servicio incluyendo sistemas y operaciones
Se trata de un concepto que cada organizacioacuten o empresa adapta a suspropias necesidades y procesos de negocio en este proyecto nos vamos a centraren la integracioacuten continua una praacutectica fundamental tanto del desarrollo aacutegilcomo de esta filosofiacutea
622 Integracioacuten Continua
Se define como una praacutectica de desarrollo software donde los miembros delequipo ponen en comuacuten su trabajo frecuentemente al menos una vez al diacutea21Cada integracioacuten se verifica con una compilacioacuten automaacutetica que incluye laejecucioacuten de pruebas para detectar errores de integracioacuten tan pronto como seaposible
Desde el punto de vista operativo esto supone automatizar la configuracioacutende equipos o el despliegue de maacutequinas virtuales donde compilar el proyecto yejecutar las pruebas y posteriormente eliminarlas Este flujo de trabajo se vebeneficiado en entornos distribuidos ya que el objetivo del desarrollador es com-probar el resultado de las pruebas raacutepidamente sin preocuparse del despliegueo los propios equipos
Para esta prueba de concepto vamos a usar Jenkins un servidor de integra-cioacuten continua escrito en Java que nos permite definir trabajos que contendraacutenla descripcioacuten tanto del entorno como su ejecucioacuten
Este sigue una estructura maestro-esclavo muy similar al de los gestores declusters usados en este proyecto el maestro contiene toda la loacutegica del servicio
21httpmartinfowlercomarticlescontinuousIntegrationhtml
40
trabajos autenticacioacuten y los esclavos son los encargados de la ejecucioacuten ensiacute Jenkins tiene varias viacuteas para aprovisionar los uacuteltimos
Mediante SSH
Interfaz graacutefica
Desarrollar un script propio
Ejecucioacuten de un fichero java
La ventaja de usar planificadores es que el despliegue de esclavos es dinaacutemicoes decir no tener una maacutequina especiacuteficamente configurada para ello DCOS yNomad se encargaraacuten de configurar estos despliegues en sus maacutequinas y poste-riormente eliminarlos Para ello se ha usado la uacuteltima opcioacuten definiendo tareasque descarguen el fichero java Con todo ello se consigue un entorno de inte-gracioacuten continua eficiente que ademaacutes permite la ejecucioacuten de otros servicios deforma independiente
Jenkins permite la creacioacuten de plugins que extienden sus funcionalidadesTanto Nomad22 como Apache Mesos cuentan con uno que permite su integra-cioacuten
Para esta prueba se va a usar el mismo proyecto que para el caso de usode orquestacioacuten de contenedores la aplicacioacuten web al que se le ha antildeadido untest para comprobar que se conecta correctamente a la base de datos medianteMocha un framework de Nodejs Por otro lado se antildeade el plugin de git ya queel coacutedigo se obtiene de GitHub el repositorio remoto de control de versiones delproyecto
El proceso general de ejecucioacuten seriacutea como sigue
1 Se ejecuta el maestro de Jenkins como tarea Docker partiendo de la imagenoficial
2 Al arrancar un trabajo se manda una tarea a los planificadores que laasignaraacuten a un nodo cliente Esta tarea consiste en la descarga del ficherode configuracioacuten Java y arrancarlo configurando el equipo como un clientede Jenkins temporalmente
3 Jenkins ejecuta el trabajo en el nuevo cliente en este caso iniciar la apli-cacioacuten web iniciar las pruebas y generar un informe
4 Se elimina el cliente
A continuacioacuten se detallan los matices de cada herramienta a la hora de imple-mentar este servicio
22Desarrollado por Ivo Verberk httpwwwivoverberknl
41
623 Jenkins con Nomad
El plugin permite la ejecucioacuten del fichero Java mediante dos controladorescontenedores Docker y Java En este proyecto nos hemos decantado por el pri-mero ya que nos ahorra instalar la maacutequina virtual de java en todos los nodoscliente Por ello se ha construido un contenedor base con Java para la ejecucioacutendel fichero de configuracioacuten y Nodejs para lanzar la aplicacioacuten web
El plugin se configura con la direccioacuten IP del cluster y el contenedor queejecuta el esclavo Jenkins Por su parte el trabajo en Jenkins se define conel repositorio en GitHub donde se aloja el coacutedigo del proyecto a probar y loscomandos a ejecutar en este caso npm update y npm test
624 Jenkins con DCOS
En el caso de DCOS su sistema de paquetes incluye Jenkins por lo queal instalarlo ya se tiene la configuracioacuten de Mesos totalmente funcional Sinembargo para ejecutar la aplicacioacuten en particular y las pruebas se requiere deNodejs en los equipos esclavos por ello debemos antildeadir un plugin de Jenkinsque permite instalar este entorno antes de ejecutar el trabajo Una vez hechoesto soacutelo queda definir la tarea igual que en el caso anterior
Cabe destacar que Mesosphere tambieacuten ha desarrollado un plugin que per-mite hacer despliegues en Marathon de tal manera que permitiriacutea con cadacommit del coacutedigo compilar la imagen del contenedor Docker y desplegarlaautomaacuteticamente aunque en este proyecto no se ha hecho pruebas de esta fun-cionalidad
42
7 Escalando la infraestructura
Uno de los factores clave que se busca a la hora de implementar sistemasdistribuidos es el poder escalar la infraestructura de forma maacutes sencilla estoes detectar que las maacutequinas estaacuten alcanzando el liacutemite de su capacidad yaumentar eacutesta ya sea mejorando sus caracteriacutesticas teacutecnicas o antildeadiendo maacutesnodos al cluster
El coacutedigo y todos los ficheros de configuracioacuten de esta seccioacuten tambieacuten sepueden encontrar en el repositorio del proyecto en GitHub23
71 Disentildeo
Microsoft Azure permite organizar los servicios cloud de forma loacutegica a traveacutesde grupos de recursos y asiacute poder crear o eliminar eacutestos en conjunto parauna aplicacioacuten determinada (por ejemplo una aplicacioacuten web suele requerir demaacutequinas virtuales bases de datos almacenamiento) Ademaacutes dispone dela opcioacuten de crear plantillas en formato JSON que permite al desarrolladordefinir los recursos y su interrelacioacuten para desplegar de forma automaacutetica unainfraestructura TI en la nube
Azure tambieacuten ofrece la posibilidad de monitorizar el estado de las maacutequinasvirtuales a traveacutes de extensiones lo que permite configurar el escalado automaacute-tico al alcanzar cierto liacutemite definido por el operador Eacutesta es a priori la formaen que deberiacutea implementarse hablando en teacuterminos de eficiencia sin embargoesta aproximacioacuten es totalmente dependiente de la plataforma es decir no sepuede extrapolar a otro proveedor o sobre recursos propios sin realizar un nue-vo disentildeo En este proyecto las tareas que son ejecutadas por estos equipos notienen estado ya que todo lo relativo a la persistencia lo hemos asignado fueradel cluster esto permite escalar la plataforma a traveacutes de otra aproximaciones
Las plantillas aceptan una serie de variables a indicar por el usuario entreotras los conjuntos de escala para definir los nodos aceptan una variable quedefine el nuacutemero de maacutequinas que los componen Por otro lado Azure ofreceuna API REST y kits de desarrollo software (SDK por sus siglas en ingleacutes) quepermiten su despliegue de forma programaacutetica Aprovechando estas facilidadesen este proyecto se va a aproximar la escalabilidad con el sucesivo desplieguede la infraestructura de forma automaacutetica se monitorizan los equipos y si sedetecta una maacutequina excesivamente cargada se aumenta el nuacutemero de equiposen la plantilla y se vuelve a desplegar
23httpsgithubcomAntonioAlfrzCloud-Orchestrators
43
En este proyecto se han disentildeado las plantillas para desplegar la arquitec-tura necesaria tanto de Nomad como de DCOS En el caso de la primera eldespliegue es maacutes descriptivo ya que incluye maacutequinas virtuales grupos de se-guridad redes En el caso de DCOS Azure cuenta con un servicio especiacuteficopara clusters gobernados por DCOS denominado Azure Container Service queincluye los componentes necesarios y la instalacioacuten ya realizada
72 Implementacioacuten
En primer lugar para monitorizar el estado de los equipos se va a usar laherramienta Nagios un sistema que permite controlar el estado del hardwarey los servicios de un equipo Se trata de una herramienta muy completa de laque se va a usar su capacidad para ejecutar comandos (plugins) en los nodospara detectar picos de carga generar alertas y ejecutar programas para estoseventos
Se ha desplegado una maacutequina virtual con esta herramienta en ambos siste-mas y se ha instalado una extensioacuten de Nagios (Nagios Remote Plugin Executor)en todos los nodos que permite ejecutar comprobaciones remotamente en con-creto para esta prueba de concepto medir el nivel de saturacioacuten de la unidadcentral de procesamiento (CPU por sus siglas del ingleacutes) Cuando sucede uncambio de estado de una maacutequina esto es cuando este paraacutemetro supera el liacutemi-te definido por el operador Nagios permite actuar en consecuencia ejecutandoprogramas por ello se ha desarrollado un script que ejecuta lo siguiente
Un programa desarrollado en Python con el SDK de Azure que modificalas plantillas y despliega los recursos
Un guioacuten de Ansible para instalar todos los componentes necesarios en lasnuevas maacutequinas y arrancar de nuevo el cluster y las aplicaciones
44
8 Resultados y conclusiones
En este uacuteltimo apartado se da una visioacuten global del proyecto asiacute como a lasconclusiones maacutes importantes a las que se ha llegado y posibles temas futurosde desarrollo
81 Comparacioacuten
Ambas herramientas ofrecen las funcionalidades para gestionar los recursoseficientemente ofreciendo a los desarrolladores una plataforma donde desplegarsus aplicaciones de forma distribuida independientemente de los equipos fiacutesicosy el hardware que las soporten
DCOS es una herramienta que en un comienzo fue privativa pero cuyos res-ponsables la empresa Mesosphere decidieron publicar una versioacuten de coacutedigoEacutesta nos permite gestionar un cluster de una forma sencilla y usable ademaacutes decomplementarlo con otras herramientas como el balanceador de carga integradoo la autenticacioacuten de usuarios ademaacutes estaacute basada en Apache Mesos un pro-yecto de relativa madurez y con el soporte de la Apache Software FoundationDe forma resumida DCOS ofrece muchas posibilidades y servicios a cambiode una arquitectura e instalacioacuten maacutes compleja
Por su parte HashiCorp con menor tiempo de desarrollo ha conseguidouna herramienta muy sencilla de desplegar que ademaacutes cumple con todas lasfuncionalidades baacutesicas ejecutando un simple binario en cada nodo se puededesplegar un gestor de clusters totalmente funcional Sin embargo no cuentacon todas las posibilidades de Mesos (Nomad cuenta con menos controladoresque entornos posibles de Mesos) ni con los antildeadidos de DCOS lo que implicael uso de otras herramientas para complementar el servicio (Consul HAProxy)
De entre las dificultades encontradas al usar estas herramientas y desplegaraplicaciones sobre ellas se puede destacar la depuracioacuten en ocasiones se desco-noce si un error viene de la propia herramienta de la aplicacioacuten desplegada o delequipo fiacutesico si no se cuenta con un sistema de procesamiento de registro unose puede encontrar con muacuteltiples terminales abiertas inspeccionando numerososficheros de registro buscando posibles errores Ademaacutes no dejan de ser solucio-nes que para usar eficientemente se debe conocer parte de su funcionamientoy sintaxis a la hora de describir la tareas lo que supone un esfuerzo antildeadido yaque cada una tiene sus particularidades y liacutemites
45
82 Conclusiones
En una sociedad cada vez maacutes digital las empresas deben adaptarse a unmercado cuya demanda de contenido no deja de crecer Las nuevas arquitecturascomo microservicios asiacute como la gran cantidad de datos generada implica queuna mejor gestioacuten de los recursos y la rapidez para desplegar o escalar solucionesdando valor al cliente lo maacutes raacutepido posible es uno de los objetivos de todas lasempresas de base tecnoloacutegica
Las ventajas que ofrecen los planificadores con aplicaciones distribuidas sonnumerosas sin ir maacutes lejos empresas tan punteras como Google llevan maacutesde 10 antildeos orquestando contenedores24 Por un lado permiten aumentar elrendimiento de los equipos propios y por otro implementar un servicio comoplataforma para despliegues distribuidos sobre cualquier conjunto hardware deesta forma se provee un servicio similar al de la nube puacuteblica pero con laprincipal diferencia de que se elimina la independencia con el proveedor (vendorlock-in) esto es las aplicaciones no tienen limitaciones impuestas por eacuteste talescomo lenguaje de programacioacuten o herramientas y permite despliegues hiacutebridosentre recursos propios y la nube
83 Objetivos conseguidos
Implementacioacuten de los planificadores propuestos en la nube Se ha en-tendido y detallado el funcionamiento de estas herramientas y se hanimplementado en el servicio de infraestructura de Microsoft Azure
Despliegue de aplicaciones y servicios distribuidos Servicios que se usanactualmente en la industria del desarrollo software asiacute como una aplica-cioacuten web con una arquitectura moderna han sido desplegados de formadistribuida en los equipos cumpliendo con la funcionalidad esperada ade-maacutes de consiguiendo una alta disponibilidad
Aproximacioacuten de arquitectura escalable Se ha hecho una aproximacioacutende infraestructura escalable de forma que sea parcialmente extrapolable aotros proveedores
24httpwwwnextplatformcom20160322decade-container-control-google
46
84 Liacuteneas de investigacioacuten
Siguiendo con la materia de este proyecto se presentan posibles liacuteneas deinvestigacioacuten
Analizar el despliegue con estas herramientas de aplicaciones de Big Datay comparar la eficiencia con respecto a soluciones especializadas
Analizar el rendimiento de los algoritmos de planificacioacuten antes pruebasde estreacutes y situaciones de alta contienda
Comparar el uso de estas herramientas con las praacutecticas actuales de laindustria o implementacioacuten en un sistema de produccioacuten real
47
Referencias
[1] LA Barroso y U Houmllzle laquoThe Datacenter as a Computer An Introduc-tion to the Design of Warehouse-Scale Machinesraquo En Morgan amp ClaypoolPublishers ()
[2] Systems Research Group ndash NetOS (University of Cambridge) The evolu-tion of cluster scheduler architectures 2016 url httpswwwclcamacukresearchsrgnetoscamsasblog2016-03-09-scheduler-architectureshtml
[3] A Das I Gupta y A Motivala SWIM Scalable Weakly-consistent Infection-style Process Group Membership Protocol Inf teacutec Dept of ComputerScience Cornell University url https www cs cornell edu ~asdasresearchdsn02-swimpdf
[4] D Dubhashi y A Das Mastering Mesos PACKT Publishing mayo de2016
[5] The Apache Software Foundation Apache Mesos documentation urlhttpsmesosapacheorg
[6] David Greenberg Building Applications on Mesos OrsquoReilly Media 2016[7] Armand Grillet Comparison of Container Schedulers Inf teacutec Technische
Universitaumlt Berlin[8] HashiCorp Consul documentation url httpswwwconsulio[9] HashiCorp Nomad documentation url httpsdcosio[10] Dan C Marinescu Cloud computing theory and practice Morgan Kauf-
mann 2013[11] Mesosphere DCOS documentation url httpswwwnomadproject
io[12] Microsoft Azure documentation url httpsazuremicrosoftcom
es-esdocumentation[13] D Ongaro y J Ousterhout In Search of an Understandable Consensus
Algorithm Inf teacutec Stanford University url httpsraftgithubioraftpdf
[14] Fei Teng laquoRessource allocation and schelduling models for cloud compu-tingraquo Tesis de mtriacutea Ecole Centrale Paris 2011
[15] A Williams y col Automation and Orchestration with Docker and Contai-ners A Comprehensive Overview of the Docker and Container Ecosystem3 The New Stack 2016
48
- Resumen
- Summary
- Iacutendice de figuras
- Introduccioacuten y objetivos
-
- Contexto
- Objetivos
- Estructura del documento
-
- Cloud Computing
- Nuevas cargas de trabajo
- Gestioacuten de recursos Planificadores
-
- Sistemas distribuidos
-
- Clasificacioacuten
-
- Herramientas
-
- DCOS
-
- Apache Mesos
- Ejemplos de uso
-
- Nomad
-
- Protocolo de consenso Raft
- Protocolo gossip SWIM
- Planificacioacuten
-
- Casos de uso y despliegue
-
- Aplicacioacuten Web
-
- DCOS
- Nomad
-
- Servicio de integracioacuten continua
-
- DevOps
- Integracioacuten Continua
- Jenkins con Nomad
- Jenkins con DCOS
-
- Escalando la infraestructura
-
- Disentildeo
- Implementacioacuten
-
- Resultados y conclusiones
-
- Comparacioacuten
- Conclusiones
- Objetivos conseguidos
- Liacuteneas de investigacioacuten
-
5 Herramientas
En la industria comienzan a aparecer soluciones software de coacutedigo abiertoque aglutinan los servicios necesarios para gestionar la infraestructura TI de ma-nera maacutes eficaz El objetivo es doble se busca facilitar la gestioacuten de los recursosde computacioacuten para organizaciones con instalaciones propias mediante su usocon un enfoque cloud esto es desplegar aplicaciones a traveacutes de un conjuntode ordenadores de forma transparente y sin tener en cuenta la infraestructurasubyacente o aprovechar el maacuteximo rendimiento de la infraestructura de losproveedores cloud puacuteblicos de forma que se tiene el maacuteximo control sobre eacutestapero no se depende de las soluciones propietarias permitiendo asiacute despliegueshiacutebridos
Entre estas herramientas se pueden destacar
OpenStack Proyecto desarrollado por la fundacioacuten del mismo nombre paraproporcionar servicios de infraestructuras (IaaS) basado en componentesque se comunican a traveacutes de APIs El componente Magnum incluye mo-tores de orquestacioacuten de contenedores
Kubernetes Sistema de orquestacioacuten de contenedores Docker creado por Goo-gle
CoreOs Sistema operativo basado en Linux disentildeado para despliegues distri-buidos sobre contenedores incluyendo mecanismos de descubrimiento deservicio y comparticioacuten de configuracioacuten
Docker Swarm Herramienta nativa de orquestacioacuten de contenedores Docker
YARN Entorno de gestioacuten de recursos y aplicaciones distribuidas de Hadoopuna libreriacutea software de procesamiento de grandes conjuntos de datos
Como podemos observar existe un gran rango de opciones para gestionar lainfraestructura desde un bajo nivel como puede ser OpenStack hasta Kuberne-tes o Docker Swarm que ofrecen exclusivamente orquestacioacuten de contenedores
En este trabajo se ha optado por Mesosphere DCOS y HashiCorp Nomadque se encuentran en el teacutermino medio su objetivo es proporcionar serviciosde plataforma que permitan la coexistencia dediferentes cargas de trabajo en elcluster
13
51 DCOS
DCOS es un proyecto de coacutedigo abierto7 creado y desarrollado por la empre-sa Mesosphere Se describe como un sistema operativo distribuido que abstraelos recursos de un cluster (capacidad de procesamiento memoria) permite lagestioacuten de muacuteltiples ordenadores de forma transparente y simplifica la instala-cioacuten de aplicaciones distribuidas
Su arquitectura se puede comparar a la de Linux en teacuterminos de nuacutecleo(kernel) y espacio de usuario El primero consta de recursos protegidos a losque no puede acceder el usuario e involucra operaciones de bajo nivel comoasignacioacuten de recursos o aislamiento de procesos En el espacio de usuario seejecutan las aplicaciones y servicios de maacutes alto nivel
Siguiendo con este siacutemil el nuacutecleo de DCOS estaacute basado en Apache Mesosque se explicaraacute en un apartado posterior y el espacio de usuario que estaacute com-prendido por los componentes del sistema esto es las diferentes herramientasque en conjunto conforman DCOS y los servicios encargados de planificar yejecutar las aplicaciones y tareas del usuario
Figura 7 Arquitectura DCOSFuente httpsdcosio
De entre los componentes que conforman DCOS destacan
Admin Router Balanceador de carga central basado en NGINX que dis-pone un proxy entre todos los servicios en el puerto 80 permitiendo sugestioacuten mediante la interfaz graacutefica Ademaacutes se encarga de la autenticacioacutenpara acceder al panel de administracioacuten
Cosmos Gestor de paquetes de las aplicaciones
Diagnostics Se ejecuta en todos los nodos y se encarga de monitorizar elestado de los daemons que sustentan DCOS
7Desde abril de 2016 httpsmesospherecomblog20160419open-source-dcos
14
Exhibitor Gestiona y automatiza el despliegue de ZooKeper la herra-mienta que provee de configuracioacuten centralizada y registro de nombres
Marathon Equivale al proceso init de los sistemas tipo Unix esto es elprimer proceso en ejecucioacuten tras la carga del kernel y que genera los demaacutesprocesos Se encarga de arrancar y monitorizar las aplicaciones y servicios
Mesos-DNS Servicio de DNS interno que define el dominio mesos pa-ra nodos y tareas en el cluster es decir permite resolver nombres conindependencia de la direccioacuten fiacutesica
Minuteman Balanceador de carga integrado a nivel TCPUDP disponiblepara las propias aplicaciones
Por otra parte se definen como servicios a las diferentes aplicaciones dis-tribuidas que DCOS permite instalar en el cluster y que pueden haber sidodesarrollados por la misma empresa Mesosphere o por terceros por ejemploApache Spark Jenkins o Apache Hadoop En la figura 8 se muestra un diagramade los servicios disponibles incluyendo algunos de las aplicaciones distribuidasque soporta DCOS
Figura 8 Servicios DCOSFuente httpsdcosio
511 Apache Mesos
El nuacutecleo de DCOS estaacute basado en Apache Mesos un proyecto de coacutedigoabierto creado por la Universidad de California Berkeley y desarrollado actual-mente por la fundacioacuten Apache Se trata de un administrador de clusters queabstrae los recursos y los dispone para diferentes aplicaciones y entornos de tra-bajo distribuidos (frameworks) mediante una interfaz comuacuten En el momento deredaccioacuten de este proyecto Apache Mesos soportaba una variedad de entornosque abarcaba desde Big Data (Apache Spark Hadoop) hasta bases de datos(Cassandra Hypertable)
15
Arquitectura
Mesos se basa en la asignacioacuten de dos roles diferentes a los nodos
Maestros (Masters) Se encargan de la gestioacuten y reparticioacuten de los recursospara los diferentes entornos de trabajo mediante ldquoofertas de recursosrdquo deacuerdo a los disponibles y a la poliacutetica de asignacioacuten (planificacioacuten en dosniveles)
Esclavos (Slaves) Ordenadores donde se ejecutaraacuten las aplicaciones y cu-yos recursos son ofertados por los maestros
En el caso de fallo del maestro las tareas pueden seguir ejecutaacutendose perono se podraacute asignar nuevos recursos ni tareas por ello pueden existir varios enel cluster para configuraciones de alta disponibilidad pero soacutelo uno orquesta alos esclavos
Para la eleccioacuten del master liacuteder Mesos usa Apache ZooKeeper un proyectode software desarrollado por la misma fundacioacuten cuyo objetivo es proveer deun servicio de configuracioacuten centralizado y registro de nombres8
Por otra parte los entornos de trabajo son los programas que deciden final-mente queacute recursos se van a usar y se encargan de que los esclavos ejecuten lastareas Eacutestos se ejecutan sobre Mesos y constan de dos componentes
Planificador (Scheduler) Optimiza y decide los recursos a utilizar de losofertados informando a los Masters
Procesador (Executor) Ejecuta las aplicaciones o servicios en los esclavos
El objetivo final es conseguir una interfaz liviana tolerante a fallos paracualquier tipo de entorno de trabajo de tal manera que en los esclavos del clusterpuedan ejecutarse simultaacuteneamente tareas con necesidades y duracioacuten diferentesPara ello se basa en dos conceptos asignacioacuten y aislamiento de recursos
Asignacioacuten de recursos
En el cluster pueden coexistir entornos de trabajo con tareas de larga dura-cioacuten y con gran consumo de recursos con tareas cortas que los ocupan y liberancon rapidez El maestro integra un moacutedulo de asignacioacuten de recursos (allocationmodule) que se encarga del algoritmo de distribucioacuten
En el momento de escribir este proyecto estaban desarrollados dos moacutedulosuno mediante el cual el usuario puede asignar prioridades y otro que implementa
8httpszookeeperapacheorg
16
el algoritmo Dominant Resource Fairness9 a grandes rasgos se determina entodos los esclavos la tarea en ejecucioacuten que necesita maacutes recursos y se calcula laproporcioacuten del recurso de mayor peso con respecto al total por ejemplo si unatarea ocupa 2 GB de memoria con respecto a 10 GB totales que tiene el clusterse le asigna un dominant share del 20 la tarea se asignaraacute al nodo con menordominant share
Aislamiento de recursos
Para conseguir que tareas de diferentes entornos de trabajo y con distin-ta naturaleza se ejecuten simultaacuteneamente en un mismo nodo Mesos usa loscontenedores Linux (descritos en la seccioacuten 3)
Funcionamiento
La figura 9 muestra el esquema de la arquitectura de Apache Mesos conalta disponibilidad (tres maestros) y con dos entornos de trabajo ejecutaacutendo-se Hadoop que permite el almacenamiento y procesamiento de gran cantidadde datos para proyectos de big data y un sistema que implementa la interfazsistema de paso de mensajes MPI
Como se puede observar el sistema ZooKeeper elige a un solo maestro comoliacuteder y eacuteste orquesta el cluster comunicando los esclavos con los planificadoresde los diferentes entornos de trabajo Tambieacuten se puede observar como las tareasde los distintos entornos estaacuten distribuidas entre los tres esclavos disponibles
Figura 9 Arquitectura de Apache MesosFuente httpsmesosapacheorg
El proceso de asignacioacuten se realiza como sigue en primer lugar un usuariosolicita la ejecucioacuten de una tarea mediante la interfaz de cada entorno de traba-jo (interfaz graacutefica API HTTP ) De forma paralela un esclavo informa almaestro de los recursos que tiene libres En consecuencia eacuteste se lo notifica almoacutedulo de asignacioacuten que en funcioacuten de su configuracioacuten decide cuaacutento ofertar
9httpspeopleeecsberkeleyedu~aligpapersdrfpdf
17
y a queacute entorno de trabajo y enviacutea la oferta a los planificadores Eacutestos respondenal maestro con queacute recursos ha decidido usar para cada tarea Finalmente lastareas son enviadas al esclavo seleccionado el cual asigna los recursos indicadosal procesador (executor) quien finalmente las ejecuta
Cabriacutea pensar que esta metodologiacutea puede conducir a situaciones en lasque un entorno podriacutea quedarse con tareas sin ejecutarse a la espera de unaoferta satisfactoria para ello Mesos implementa un sistema de filtros medianteel cual los entornos especifican los requisitos miacutenimos que debe cumplir unaoferta por ejemplo se puede especificar en queacute nodos debe desplegarse la tareaEste sistema estaacute disentildeado asiacute con el objetivo de mantener lo maacutes transparenteposible esta herramientas de forma que acepte entornos de trabajo de distintasnaturalezas
512 Ejemplos de uso
Grandes empresas estaacuten usando Apache Mesos con eficacia de acuerdo a susnecesidades e infraestructuras Caben destacar
Ebay En el modelo de implementacioacuten continua en esta empresa10 cadadesarrollador cuenta con su propia instancia que se ejecuta en una maacutequinavirtual dedicada lo que ha conllevado un uso de los recursos poco eficiente Enuna prueba de concepto consiguieron realizar una herramienta de integracioacutencontinua distribuida basada en un cluster con Apache mesos y con el entornoMarathon y Jenkins
Apple Anuncioacute que el motor de su famosa herramienta de asistencia per-sonal para iPhones Siri estaacute desplegada sobre Apache Mesos11 Para ello handesarrollado su propio entorno para facilitar a los ingenieros a desplegar los ser-vicios que la herramienta necesita para resolver las peticiones de los usuarios
Twitter Desarrolloacute su propio entorno denominado Aurora y actualmentegestionan sus recursos y miden el coste de las tareas que los empleados usancon el objetivo de que sean conscientes del gasto que puede suponer un usoinadecuado de la infraestructura12
10httpwwwebaytechblogcom20140404delivering-ebays-ci-solution-with-apache-mesos-part-i11httpwwwbusinessinsidercomapple-siri-uses-apache-mesos-2015-812httpswwwlinuxcomNEWS4-UNIQUE-WAYS-UBER-TWITTER-PAYPAL-AND-HUBSPOT-USE-APACHE-MESOS
18
52 Nomad
Herramienta de coacutedigo abierto de gestioacuten de clusters creada y desarrolladapor Hashicorp13 que permite el despliegue de aplicaciones y procesos de formadistribuida
Las principales diferencias con Apache Mesos a grandes rasgos son
Arquitectura maacutes ligera Nomad soacutelo requiere de un fichero para funcionarejecutaacutendolo con las correspondientes configuraciones en todos los nodosrealiza las funciones de gestioacuten del cluster eleccioacuten de liacuteder planificacioacutende recursos y ejecucioacuten de las tareas
Centro de datos y regiones muacuteltiples Su arquitectura estaacute orientada afacilitar la gestioacuten de diferentes centros de datos geograacuteficamente distri-buidos
Entorno de ejecucioacuten Las tareas se definen y son interpretadas mediantecontroladores integrados en Nomad que se valen de los recursos y herra-mientas de los nodos clientes para ejecutarlas Esta integracioacuten dificultael desarrollo de controladores por parte de terceros a diferencia de Mesosque delega dicha responsabilidad en los entornos de trabajo externos alproyecto
Usa un planificador de estado compartido con respecto a la planificacioacutenen dos niveles de Mesos
Antes de entrar en maacutes detalle en la arquitectura es importante definir lossiguientes teacuterminos
Controlador (Driver) Software que se encarga de interpretar las definicionesde las tareas y ejecutarlas semejante a los procesadores de los entornosde trabajo de Mesos A la hora de redactar este proyecto Nomad contabacon controladores para contenedores Docker virtualizacioacuten de maacutequinasmediante el emulador QEMU aplicaciones java y archivos binarios
Grupo de trabajo (Task Group) Conjunto de tareas que se ejecutan en elmismo nodo cliente
Trabajo (Job) Conjunto loacutegico de tareas y grupos de trabajo que se despliegana la vez
Asignacioacuten (Allocation) Relacioacuten entre un grupo de trabajo y el cliente don-de se ejecuta
Evaluacioacuten (Evaluation) Proceso mediante el cual Nomad planifica y ges-tiona el registro o actualizaciones de los trabajos
13httpswwwhashicorpcom
19
Nomad sigue una arquitectura maestro-esclavo similar a la de Apache Mesosmuacuteltiples servidores acuerdan entre siacute un liacuteder que gestiona la planificacioacuten detareas en los clientes que soacutelo conocen sus asignaciones y las ejecutan
Todos los servidores participan paralelamente en tareas de planificacioacuten derecursos y asignacioacuten de tareas y ademaacutes entre ellos eligen un liacuteder que seencarga de la coordinacioacuten de la suscripcioacuten de los clientes al cluster y de lagestioacuten de las peticiones
Los clientes estaacuten configurados para comunicarse con el servidor usando lla-madas a procedimiento remoto (RPC por sus siglas en ingleacutes) que permite unordenador ejecutar coacutedigo en otra maacutequina Mediante esta tecnologiacutea los nodosclientes avisan de su estado e informa de sus asignaciones recursos y controla-dores disponibles
Existe la posibilidad de gestionar varios centros de datos agrupados en regio-nes eacutestas son independientes pero permite definir tareas o comprobar el estadode todas ellas desde cualquier punto A continuacioacuten se muestra una figura dela arquitectura a alto nivel de esta configuracioacuten
Figura 10 Arquitectura multi-regioacuten en NomadFuente httpswwwnomadprojectio
La herramienta se sustenta sobre tres protocolos fundamentales un protocolode consenso entre los servidores para compartir informacioacuten sobre su estado yel liacuteder un protocolo Gossip para la gestioacuten entre regiones y el planificador detareas
521 Protocolo de consenso Raft
El objetivo es obtener consistencia en un conjunto de nodos que comparteninformacioacuten es decir si un cliente realiza un cambio que todos los nodos veanla misma informacioacuten a la vez y ademaacutes sea tolerante a fallos Para ello se basaen el algoritmo Raft[13] que se detalla brevemente a continuacioacuten
20
Los nodos participantes en el algoritmo pueden estar en tres estados
Liacuteder (Leader) Todos los cambios que realicen en el cluster pasan por eacutel pri-mero
Seguidor (Follower) Nodo pasivo cuya responsabilidad es responder a laspeticiones del nodo liacuteder
Candidato (Candidate) Maacutequina que no ha encontrado liacuteder y solicita sueleccioacuten
Supongamos que tenemos cinco equipos que acaban de arrancar el protocoloEn la figura 11 se observan los nodos y sus respectivos registros a la derecha
Figura 11 Equipos sin consenso ejecutando el protocolo RAFTFuente httpsgithubcomongardieraftscope
Al comenzar todos los nodos son seguidores esperando recibir comunicacioacutende un nodo que actuacutee como liacuteder Cada nodo tiene un tiempo de espera aleatoriodespueacutes del cual si no es informado por un liacuteder pasa a estado candidato y pideel ldquovotordquo al resto de los participantes El algoritmo divide el tiempo en plazos uncandidato pasa a liacuteder si recibe la mayoriacutea de los votos en un plazo determinadoSe define mayoriacutea o cuoacuterum (quorum) comolceil
N2rceil
+ 1 (1)
donde N representa el nuacutemero de nodos
Para el ejemplo propuesto de 5 equipos se requieren de 3 votos Soacutelo losnodos que se encuentren en estado seguidor pueden votar una uacutenica vez a laprimera solicitud que reciba dentro de un plazo
Supoacutengase que el nodo denotado con S1 ha cumplido su tiempo de espera yrealiza la peticioacuten de voto (figura 12) A partir de este momento se pueden dartres casos
La maacutequina gana la eleccioacuten y pasa a ser liacuteder informando al resto
Otro servidor se establece como liacuteder en el mismo momento
Varios nodos pasan a ser candidatos por lo que ninguno consigue los votos
21
Figura 12 Un equipo pasa a estado candidato (RAFT)
Si un candidato recibe un aviso de un liacuteder en el mismo plazo el primeropasa a ser seguidor y se acaba la eleccioacuten de liacuteder
Por otro lado si un equipo candidato no recibe los votos en el plazo y agotasu tiempo de espera avanza al siguiente plazo y repite el proceso de votacioacutenLa tercera posibilidad puede conllevar a un estado indefinido ya que varioscandidatos pueden agotar su tiempo de espera al mismo tiempo y repartir losvotos Para solventarlo el algoritmo establece tiempos de espera aleatorios paralos candidatos
Siguiendo con el ejemplo propuesto el servidor S1 pasa a ser el liacuteder Cadacierto tiempo eacuteste debe realizar avisos a los nodos seguidores para no agotar sutiempo de espera
En este momento el cluster de servidores estaacute en ldquoconsensordquo y la informacioacutenen todos los nodos estaacute actualizada Un cambio en la informacioacuten inicia unproceso de replicacioacuten el liacuteder registra el cambio lo pasa al resto de nodos yuna vez eacutestos responden el cambio se hace efectivo
Supoacutengase que se realiza un cambio en los datos en la figura 13 en la partederecha se observa el cambio en el registro del servidor S1 que informa a losnodos seguidores En consecuencia los nodos registran el cambio y responden aS1
Figura 13 Cambio en un registro (RAFT)
Una vez el cuoacuterum (en el ejemplo tres equipos) informa al liacuteder de que
22
ha registrado el cambio el liacuteder lo hace efectivo en su sistema y notifica a losnodos que hacen lo mismo En la figura 14 el enviacuteo todaviacutea no ha llegado ala maacutequina S3 y se observa que no ha hecho efectivo el cambio (en el registroaparece punteado)
Figura 14 Aprobacioacuten del resto de equipos (RAFT)
Este protocolo funcionaraacute correctamente mientras exista un nuacutemero de nodosen funcionamiento igual o superior al cuoacuterum en el ejemplo propuesto elcuoacuterum es tres por lo que el sistema puede tolerar la caiacuteda de dos de los equipos
522 Protocolo gossip SWIM
Nomad permite la gestioacuten simultaacutenea de varios centros de datos reparti-dos en regiones geograacuteficamente separadas requiriendo de un protocolo ligeroque mantenga a los miembros actualizados sobre los participantes del conjun-to Para ello usa una ligera variante del protocolo SWIM[3] (Scalable Weakly-consistent Infection-style Process Group Membership Protocol) desarrollada porHashiCorp Estaacute clasificado como un protocolo de tipo gossip que debe su nom-bre a la semejanza con coacutemo se distribuye un rumor en una red social
SWIM se sustenta en dos caracteriacutesticas fundamentales la deteccioacuten de fallosy la distribucioacuten de la informacioacuten relativa a los miembros A continuacioacuten sedetalla el funcionamiento de ambos componentes
Deteccioacuten de fallos
Este componente tiene dos paraacutemetros el periodo de protocolo T y el nuacutemerode subgrupos de deteccioacuten de fallos k en los que se dividen los nodos Paracomprobar la comunicacioacuten entre dos maacutequinas usa la utilidad ping basadaen el protocolo ICMP La deteccioacuten de caiacuteda de un servidor sigue el siguientealgoritmo
Durante el periodo T cada miembro Mi de un subgrupo elige otro al azar Mjdel mismo subgrupo y le enviacutea un mensaje ping para comprobar su estado Enel caso de que se cumpla un tiempo de espera determinado por una estimacioacuten
23
del tiempo de ida y vuelta (RTT por sus siglas en ingleacutes) de la red y no hayarespuesta Mi le vuelve a enviar un mensaje ping indirectamente a traveacutes deun nuacutemero k de miembros escogidos aleatoriamente De no recibir ninguna res-puesta Mi establece que Mj ha sufrido un fallo y lo etiqueta como ldquosospechosordquoinformando al componente de distribucioacuten
Figura 15 Diagrama de tiempo del protocolo SWIMFuente httpswwwcscornelledu
Componente de distribucioacuten
Se encarga de informar de cualquier cambio en los miembros a todo el con-junto Los eventos de nodo caiacutedo y la unioacuten o disociacioacuten de un miembro setransmiten a todos los servidores para que actualicen sus lista Para distribuirla informacioacuten a todos los nodos se podriacutea usar el meacutetodo de multicast perosuele estar deshabilitado Por ello se utiliza una teacutecnica de transmisioacuten denomi-nada Piggybacking mediante la cual se adjunta a los propios mensajes PINGy ACK del algoritmo la informacioacuten a distribuir reduciendo asiacute la congestioacutenen la red
523 Planificacioacuten
Proceso encargado de distribuir las tareas entre los nodos clientes de acuerdoa su estado
El planificador de Nomad estaacute basado en las publicaciones de Google sobresus herramientas de gestioacuten de clusters Borg y Omega14 y entiende los trabajosdescritos por el usuario como un estado deseado es decir su despliegue en unamaacutequina cliente de forma correcta y los clientes como el estado actual esto eslo que se encuentra en ejecucioacuten El registro actualizacioacuten o cancelacioacuten de un
14httpresearchgooglecompubspub43438html
24
trabajo asiacute como el fallo de un nodo cliente implican un cambio de estado atramitar por el sistema lo que se define como evaluacioacuten (evaluation) Esto uacutelti-mo supone comparar el estado actual (clientes) con el estado deseado (conjuntode trabajos registrados) y enviarlos a los planificadores correspondientes que seencargaraacuten de asignar las tareas a los nodos clientes
Figura 16 Procedimiento de asignacioacuten en NomadFuente httpswwwnomadprojectio
En la figura 16 se observa el flujo de trabajo en el que las distintas evalua-ciones se encolan en el evaluation broker que se ejecuta en el servidor liacuteder ygestiona las evaluaciones pendientes asignaacutendoles prioridades
A continuacioacuten los nodos servidores ejecutan los scheduling workers queprocesan las evaluaciones llamando a los distintos planificadores que generanun plan de asignacioacuten esto es un conjunto de relaciones entre las tareas y losnodos clientes donde se ejecutaraacuten Este proceso se divide en dos fases primerose descartan aquellos clientes que no cumplan los requisitos y posteriormentese asigna una calificacioacuten al resto Se selecciona el nodo con mayor puntuacioacuteny se encola el plan en el gestor que se ejecuta en el servidor liacuteder Existen tresplanificadores de acuerdo al tipo de trabajo
Service Incluye aquellos trabajos que estaacuten destinados a ejecutarse en un pe-riacuteodo largo de tiempo Para realizar las asignaciones el planificador evaluacuteala mayor parte de los nodos y usa una versioacuten del algoritmo Best fit in-fluenciada por el trabajo de Google en su herramienta Borg Se trata deun algoritmo de planificacioacuten que sacrifica tiempo a cambio de maximizarel rendimiento de los clientes asignando la tarea a la maacutequina que tengala mayor carga de trabajo con el objetivo de reducir equipos en funciona-
25
miento
Batch Tareas que incluyen listas de comandos en general de menor duracioacuteny que no requieren interaccioacuten con el usuario Se vale del algoritmo deSparrow desarrollado por la universidad de Berkeley15 para limitar losnodos clientes a evaluar
System Trabajos destinados a ejecutarse en todos los nodos incluso los que seunen al cluster posteriormente
Core Mantenimiento interno de Nomad
Una vez se ha realizado el proceso de planificacioacuten el nodo liacuteder lo registra enla cola de planes (plan queue) que se encarga de asignarles prioridad y manejarcondiciones de carrera es decir que no accedan a los recursos de los clientes sincontrol y evitar que eacutestos superen su capacidad
La maacutequina liacuteder del conjunto puede de este modo aceptar una asignacioacuteny ser ejecutada por los clientes o por el contrario rechazaacutersela al planificadorlo que implicariacutea realizar un plan parcial o totalmente nuevo
Finalmente el estado de las evaluaciones se actualizan y los clientes soninformados de las asignaciones ejecutaacutendose las tareas
15httppeopleeecsberkeleyedu~keopublicationssosp13-final17pdf
26
6 Casos de uso y despliegue
Con el objetivo de mostrar las posibles utilidades que este tipo de sistemaspueden tener en las infraestructuras TI actuales se han desplegado las dos he-rramientas en la nube Microsoft Azure usando su servicio cloud de instancias demaacutequinas virtuales Linux para simular un conjunto de ordenadores conectadosentre siacute por una red LAN Sobre ellas se ha implementado dos casos de usouna aplicacioacuten web con una arquitectura con cierta orientacioacuten a microserviciosy un sistema de integracioacuten continua
El coacutedigo y todos los ficheros de configuracioacuten se pueden encontrar en elrepositorio del proyecto en GitHub16
61 Aplicacioacuten Web
Se busca simular el proceso de adaptacioacuten de una solucioacuten web para su des-pliegue en un sistema distribuido con las herramientas anteriormente descritascon el objetivo de aumentar tanto su escalabilidad como disponibilidad medianteredundancia
Se ha partido de una aplicacioacuten ya existente17 un servicio de almacenamien-to y reproduccioacuten de canciones A grandes rasgos este servicio permite crearusuarios subir canciones con sus respectivas portadas tener playlists propias yescuchar las canciones a traveacutes de un navegador web
La solucioacuten estaacute dividida en 4 partes (figura 17)
Una vista web con la loacutegica
Un almacenamiento conectado en red (NAS por sus siglas en ingleacutes)
Una API REST para gestionar las peticiones al almacenamiento
Base de datos NoSQL basada en MongoDB
La nueva tendencia de los proyectos web es su implementacioacuten en contene-dores Docker ya que facilitan su portabilidad y ofrecen un procedimiento dedespliegue raacutepido sobre todo a la hora de desarrollar y realizar pruebas en en-tornos de produccioacuten simulados Por ello en este caso se va a hacer uso de los
16httpsgithubcomAntonioAlfrzCloud-Orchestrators17httpsgithubcomsonsoleslpCDPSfy
27
motores de orquestacioacuten de contenedores de ambas herramientas Marathon enDCOS y el controlador Docker en el caso de Nomad
Figura 17 Arquitectura aplicacioacuten web
A continuacioacuten vamos detallar el despliegue en ambas herramientas de es-ta solucioacuten y observar tanto queacute dificultades se encuentran como que ventajasofrecen El objetivo final es adaptar el proyecto modificaacutendolo lo menos posiblecon objeto de analizar la capacidad de estas herramientas para desplegar cual-quier aplicacioacuten sin que eso conlleve la modificacioacuten de la arquitectura de eacutestaes decir que no sea dependiente del entorno
611 DCOS
Se ha descrito DCOS como una herramienta que se despliega sobre un con-junto de ordenadores y que permite instalar gestionar el despliegue de sistemasdistribuidos
Microsoft Azure cuenta con una plantilla para desplegar en su servicio cloudun cluster de maacutequinas virtuales con DCOS ya instalado que cuenta con
Maacutequinas maestras (1 3 o 5 a seleccionar por el usuario) configuradascomo un conjunto de disponibilidad esto eso Azure da ciertas garantiacuteasde que al menos una maacutequina estaraacute en funcionamiento
Maacutequinas agentes Por motivos de seguridad se distinguen dos roles
bull Nodos privados solo accesibles desde la red interna y configuradoscomo un conjunto de escala un recurso de Azure para gestionar ydesplegar maacutequinas con configuraciones ideacutenticas para permitir unraacutepido escalado
bull Un equipo conectado accesible desde Internet a travntildees de un balan-ceador de carga puacuteblico y situado en una subred externa
28
Dos balanceadores de carga
bull La interfaz puacuteblica del cluster que se conecta con el cliente puacuteblicobull Acceso a los equipos maestros para el administrador que soacutelo permiteconexioacuten mediante SSH y credenciales
Almacenamiento para todas las maacutequinas
Configuraciones necesarias de red y seguridad
En la figura 18 se observa un diagrama de la infraestructura
Figura 18 Infraestructura en Azure
El primer obstaacuteculo es la persistencia de estado de la aplicacioacuten que seconsigue gracias a una base de datos no relacional basada en MongoDB asiacutecomo el almacenamiento de las canciones Para implementarla tenemos variasposibilidades
Montar un sistema externo de almacenamiento conectado en red en todoslos agentes donde se ejecuten las tareas de esta manera si una tarea pasade un nodo a otro por cualquier motivo puede tener acceso a los mismosficheros (opcioacuten del caso de uso original)
Implementar un sistema de ficheros distribuidos en los agentes
Usar los servicios de almacenamiento de las nubes puacuteblicas
Aprovechar el sistema de voluacutemenes persistentes de Apache Mesos Eacutestepermite reservar recursos de un agente de forma que al arrancar una tarease crea un volumen independiente del ciclo de vida de eacutesta con ello esosrecursos donde se ha almacenado la informacioacuten pueden volver a ofrecerseal mismo entorno de tal manera que otra tarea pueda acceder a ella
DCOS aprovecha este sistema de voluacutemenes persistentes y permite instalarbases de datos distribuidas como ArangoDB o Apache Cassandra sin embargoesto implicariacutea modificar todo el coacutedigo referente al modelo de la base de datos
29
Por motivos de eficiencia y latencia asiacute como de una mayor gobernabilidadde los datos la mejor opcioacuten es usar el recurso de voluacutemenes persistentes queofrece Apache Mesos ya que de esta manera se gestionariacutea la aplicacioacuten completamediante una uacutenica herramienta Sin embargo esto implica que la informacioacutense encuentra exclusivamente en el agente donde se haya ejecutado la tarea y porlo tanto se sigue requiriendo de software externo para distribuir la informacioacutenpara que se accesible para todos los agentes A la hora de realizar este proyectose encontraba en desarrollo Flocker una solucioacuten desarrollada por ClusterHQque permite compartir los voluacutemenes de Docker a traveacutes de un cluster quesi bien es compatible con el planificador de Mesos el proyecto se encontrabatodaviacutea en fases tempranas de desarrollo y los sistemas de almacenamiento quesoporta quedaban fuera del aacutembito de este trabajo
Por todo ello dado que las maacutequinas se han desplegado en la nube puacuteblicade Azure se decidioacute usar su servicio de almacenamiento de objetos para lascanciones y otra maacutequina para desplegar MongoDB y asiacute mantener el modelode datos original de la aplicacioacuten La diferencia del almacenamiento de obje-tos con respecto a nivel de fichero es que el primero no tiene jerarquiacutea paraorganizar los archivos eacutestos se guardan como objetos (con sus metadatos) enun mismo espacio soacutelo diferenciaacutendose por un identificador uacutenico esto implicaentre otras cosas que se puede acceder a un fichero dado uacutenicamente su IDindependientemente de la localizacioacuten fiacutesica de eacuteste facilitando pues la gestioacuteny el desarrollo
El coacutedigo del proyecto se ha modificado en los siguientes apartados
Las direcciones de la base de datos y los balanceadores de carga asiacute comosus puertos estaban originalmente fijos Se han configurado como variablesde entorno para facilitar el descubrimiento del servicio y hacer transpa-rente la aplicacioacuten al entorno de despliegue
La API REST se ha adaptado al almacenamiento en Azure en vez de enlocal
Estas modificaciones no suponen un cambio sustancial pero permiten separala persistencia de las tareas ejecutadas por DCOS lo que facilita en granmedida su ejecucioacuten al ser totalmente sin estado y ademaacutes implican tenerlos datos bajo un mayor control
Para la orquestacioacuten de contenedores se va a usar el entorno Marathondesarrollado tambieacuten por Mesosphere Eacuteste se puede usar a traveacutes de una interfazgraacutefica la interfaz de liacutenea de comandos (en lo que sigue CLI por sus siglas eningleacutes) de DCOS o con su API HTTP
Primero se han publicado la imaacutegenes de los contenedores que encapsulanla interfaz web y la api de la aplicacioacuten en el repositorio puacuteblico DockerHub
Los despliegues en este entorno se describen mediante ficheros JSON en losque se detalla entre otras opciones la imagen del contenedor los puertos a usar
30
los recursos que debe ocupar en un nodo o las instrucciones de monitorizacioacuten
Para el servicio de descubrimiento DCOS ofrece la posibilidad de asignardirecciones IP virtuales (VIP por sus siglas en ingleacutes) a tareas que se compartenen todos los nodos DCOS lleva integrado un balanceador de carga a nivel TCP(el componente denominado Minuteman) que balancea entre las direccionesvirtuales de las tareas y todas las instancias de eacutestas a lo largo del cluster Estoes necesario por dos motivos equilibrar la carga de los equipos con el fin deevitar un punto de uacutenico fallo mediante redundancia y evitar la contienda dedirecciones al ejecutar las tareas en puertos aleatorios
Este balanceador de carga estaacute basado en el trabajo de Michael Mitzenma-cher The Power of Two Choices in Randomized Load Balancing18 A grandesrasgos el algoritmo mantiene una media moacutevil exponencial de latencias paracada destino (backend) ademaacutes de las caiacutedas consecutivas Si un destino noresponde a una negociacioacuten en tres pasos (three way handshake) de forma con-secutiva en un periodo inferior a 5 ms se considera caiacutedo El algoritmo iterasobre los destinos disponibles en base a su histoacuterico de fallos y escoge dos deforma aleatoria de los cuales coge el de mejor meacutetrica
Las direcciones virtuales soacutelo se pueden resolver dentro del cluster porello para implementar la interfaz puacuteblica de la aplicacioacuten esto es el balancea-dor de carga de la interfaz web usaremos un paquete de DCOS denominadomarathon-lb un balanceador basado en HAProxy y adaptado por MesosphereEn este caso equilibra la carga de todas instancias de las tareas ejecutadas porel entorno Marathon por sus etiquetas y permite ademaacutes definir como puntode entrada muacuteltiples hosts virtuales definidos por sus nombres completos dedominio (FQDN por sus siglas en ingleacutes) en nuestro caso la interfaz puacuteblicadel balanceador de Azure para los agentes
Por motivos de seguridad todas las tareas se ejecutan en los agentes privadoses decir los que son exclusivamente accesibles desde la red interna Por su partemarathon-lb se ejecuta en el agente puacuteblico que cuenta con IP puacuteblica y lospuertos 80 (HTTP) y 8080 abiertos de forma que la aplicacioacuten sea accesibledesde Internet Esto es posible debido a que Apache Mesos permite reservarrecursos mediante roles asignados a nodos para un uso especiacutefico De esta formala arquitectura vista desde la aplicacioacuten quedariacutea como en la figura 19
18httpswwweecsharvardedu~michaelmpostscriptstpds2001pdf
31
Figura 19 Arquitectura de la aplicacioacuten web en DCOS
Ejecucioacuten
A la hora de desplegar la aplicacioacuten DCOS puede gestionarse medianteuna interfaz graacutefica o una interfaz de liacutenea de comandos La primera se accedea traveacutes de un navegador web en el puerto 80 (HTTP) y permite instalar losentornos disponibles observar el estado de los nodos y las tareas que se estaacutenejecutando y los ficheros de registros que eacutestas generan
La CLI permite el control desde un nodo o una maacutequina remota (suponiendoque los maestros tienen IP puacuteblica y el puerto 80 abierto) ya que DCOS tieneun sistema de autorizacioacuten que permite tener una interfaz puacuteblica con ciertasgarantiacuteas de seguridad
Por su parte cada entorno de trabajo puede ser controlado por la CLI peroademaacutes cuenta con sus propias interfaces Marathon expone una API HTTPen el puerto 8080 de la direccioacuten puacuteblica de los maestros del cluster asiacute comootra interfaz graacutefica Para desplegar un contenedor se podriacutea usar la CLI
$ dcos marathon app add lt f i l e j songt
O la API HTTP
$ cu r l minusX POST http lt ip_maestro gt8080v2apps minusd ltf i l e jsongt minusH Contentminustype app l i c a t i o n j son
32
612 Nomad
La arquitectura de Nomad es maacutes sencilla ya que solo requiere de un ficheroejecutable en todos los nodos para funcionar Si DCOS es la base de instala-cioacuten de entornos de terceros Nomad integra todas las funcionalidades baacutesicasesto es gestor de recursos planificador y ejecutor en los nodos cliente Estaherramienta cuenta con un menor tiempo de desarrollo y en el momento deescribir este documento cuenta exclusivamente con los siguientes controladoresen comparacioacuten con los entornos de DCOS
Motor Docker es decir funcioacuten de orquestacioacuten de contenedores
Ejecucioacuten de archivos binarios como comandos de Shell
Ejecucioacuten de aplicaciones Java
Virtualizacioacuten de maacutequinas mediante tecnologiacutea QEMU
Todos ellos necesitan que la tecnologiacutea subyacente esteacute instalada en las maacute-quinas clientes (Docker Java QEMU) Actualmente no permite el registro decontroladores por parte de terceros aunque estaacute planificado en un futuro ofreceruna interfaz para su desarrollo
Nomad no cuenta con el servicio de descubrimiento sin embargo puede inte-grarse con la herramienta Consul desarrollada por la misma empresa Por otrolado para el balanceo de carga usaremos un contenedor Docker con HAProxyuna herramienta de coacutedigo abierto que ofrece tanto servicios de proxy como debalanceador y cuyos ficheros de configuracioacuten completaremos con el proyectoConsul Template19
Consul
Consul sigue la misma arquitectura que Nomad es decir un nodo servidorque orquesta un conjunto de maacutequinas clientes y permite a los procesos que seejecutan en los equipos definirlos como servicios ofreciendo diversas caracteriacutes-ticas entorno a estos de los cuales vamos a usar dos
Descubrimiento de servicio Las maacutequinas clientes publican en el cataacutelogode servicios las tareas en ejecucioacuten y Consul les asigna nombres de dominioaccesibles por todos los miembros del cluster a traveacutes de la interfaz DNSincluida en esta herramientaConsul se integra con Nomad de forma que todas las tareas que se ejecu-ten en la segunda son automaacuteticamente publicados como servicios de laprimera de esta manera no hace falta conocer la direccioacuten de la maacutequinacliente donde se esteacute ejecutando el proceso ya que se puede acceder a eacutela traveacutes de su nombre de dominio de forma transparente Por ejemplo si
19[httpsgithubcomhashicorpconsul-template]
33
ejecutamos una tarea con ID web en el puerto 8080 se puede acceder aella en la direccioacuten webserviceconsul8080Para que las direcciones propias de Consul las resuelva su propio DNS y noel que esteacute asignado por defecto en la maacutequina usaremos la herramientadnsmasq20 que permite especificar la direccioacuten de un servidor DNS paraconsultas de direcciones especiacuteficas
Monitorizacioacuten Permite realizar comprobaciones del servicio y seguir su esta-do Aprovecharemos esta funcionalidad tanto para definir el propio procesode Nomad como servicio de Consul como las tareas desplegadas
HAProxy + Consul Template
HAProxy es una solucioacuten versaacutetil de coacutedigo abierto que ofrece solucionesde balanceo de carga y proxy Existen otras herramientas en el mercado comoNGINX o ldirectord sin embargo HAProxy suponiacutea una solucioacuten sencilla deconfigurar para mostrar el caso de uso
El uso de estas herramientas se debe a dos motivos para que no existacontienda con respecto a los puertos de los clientes usados por las tareas eacutestos sevan a asignar de forma dinaacutemica lo que en principio implicariacutea que la aplicacioacutendeberiacutea realizar consultas DNS de tipo SRV (que incluye puertos) a la interfazde Consul y balancear la carga entre tareas por redundancia y capacidad
Como la direccioacuten IP y puerto son variables cada vez que las tareas seactualicen o se reasignen es necesario volver a configurar HAProxy de formamanual Por ello HashiCorp ha desarrollado un programa denominado Con-sul Template que realiza peticiones sucesivas a la interfaz HTTP de Consul delas direcciones fiacutesicas de un servicio y reinicia automaacuteticamente el proceso deHAProxy Asiacute definiendo estas tareas como servicios Consul podremos tantomonitorizarlas como escalar las tareas dinaacutemicamente sin necesidad de cambiarel balanceador A partir del contenedor Docker oficial de HAProxy se ha desa-rrollado otro con la configuracioacuten baacutesica y con Consul Template para desplegarlocomo una tarea en Nomad
Despliegue
Se ha usado el mismo coacutedigo que en el apartado anterior con la persistenciaen el servicio de almacenamiento de Azure Desde la perspectiva del hardwarese implementaraacute la misma infraestructura que en el caso de DCOS (figura 18)estos es definiremos dos tipos de maacutequinas clientes un agente que se conectaraacutecon el balanceador de carga con nombre de dominio puacuteblico y donde se desple-garaacute el balanceador de carga de la vista web y agentes privados no accesiblesdesde fuera del cluster y donde se ejecutaraacuten el resto de tareas en la red inter-na La principal diferencia radica en las tareas que ejecutan HAproxy y ConsulTemplate que sustituye a las direcciones IP virtuales que ofrece DCOS
20httpwwwthekelleysorgukdnsmasqdochtml
34
Figura 20 Despliegue en Azure de Nomad+Consul
Cabe matizar que los balanceadores basados en HAProxy se implementanpor necesidad de la aplicacioacuten para el descubrimiento del servicio a diferenciade los de Azure que se implementan por motivos de seguridad y escalabilidaddel cluster en siacute
Configuracioacuten Nomad
Los ficheros de configuracioacuten de las maacutequinas maacutester y cliente son similaresy comparten la mayoriacutea de las opciones como por ejemplo el nombre del nodoo la interfaz de red donde escucha Nomad las peticiones Sus opciones son engeneral auto-explicativas sin embargo existen dos detalles que matizar
El proceso de Nomad escucha las peticiones tanto de los protocolos deconsenso como del usuario a traveacutes de una interfaz de red que se debeindicar en el fichero de configuracioacuten
En el caso de los clientes se deben indicar las direcciones de los servidoresdel cluster sin embargo se trata de un sistema dinaacutemico en el que losnodos pueden sufrir errores y cambiar de direccioacuten Por ello se ha definidoNomad como un servicio de Consul y asiacute poder definir la direccioacuten de losservidores como un nombre de dominio no por su direccioacuten fiacutesica que elservidor DNS de Consul se encargaraacute de resolver
Por defecto Nomad usa los siguientes puertos
API HTTP 4646 Peticiones HTTP y recepcioacuten de oacuterdenes mediante laliacutenea de comandos
RPC 4647 Protocolo de consenso entre los nodos del cluster
Serf 4648 Protocolo de gossip entre los servidores de los centros de datosgobernados por Nomad
35
Los dos uacuteltimos deben ser interfaces alcanzables por otros nodos sin embargo laAPI HTTP por motivos de seguridad deberiacutea ser local ya que en caso contrariocualquier persona con acceso a ella tiene el control sobre la herramienta Eacutestasolo deberiacutea estar accesible en un servidor o gestionarlo mediante una terminalSSH por ejemplo En este trabajo al ser una prueba de concepto se ha abiertoen todos los nodos
Trabajos de Nomad
Las tareas se detallan en ficheros con formato HashiCorp Configuration Lan-guage un derivado del formato JSON creado por la empresa que le da nombrecompatible con eacuteste y que permite comentarios
En estos ficheros se puede definir
La regioacuten y el centro de datos donde se ejecutaraacute (Nomad permite lagestioacuten de centros de datos geograacuteficamente distribuidos en regiones)
La poliacutetica de actualizacioacuten de la tarea
Grupo de tareas esto es que se ejecutaraacuten en el mismo nodo
El nuacutemero de grupos a ejecutarescalar asiacute como los liacutemite que debencumplir los nodos asignados
La poliacutetica de reinicio ante fallo o error
Tareas El controlador su configuracioacuten los paraacutemetros del servicio aso-ciado a registrar en Consul asiacute como los recursos que consume (puertosmemoria)
En nuestro caso usamos sobre todo el controlador Docker esto eso orques-tacioacuten de contenedores en los nodos clientes y tres de sus opciones
Imagen del contenedor Se han subido todas las imaacutegenes del proyecto a Doc-ker Hub donde por defecto se busca la imagen
Puertos Los puertos a usar por el contenedor que pueden ser estaacuteticos asigna-dos por el usuario o dinaacutemicos siendo Nomad el que se encarga de mapearun puerto libre del nodo cliente al expuesto por el contenedor
Servidores DNS Como usamos la interfaz DNS de Consul como descubri-miento de servicio se debe configurar el contenedor para que use cualquiernodo del cluster como servidor DNS
Configuracioacuten Consul
Al ser desarrolladas por la misma empresa los ficheros de configuracioacuten deConsul y Nomad comparten muchas opciones Consul tambieacuten acepta peticionesa traveacutes de una interfaz de red siendo los puertos usados por defecto
36
RPC 8300 8400 Maneja la peticiones del resto de nodos y usuarios
Serf 8301 8302 Protocolo gossip
HTTP API 8500
HTTPS API Desactivada por defecto
Interfaz DNS 8600
Se debe asignar a los protocolos internos del cluster esto es RPC y Serf unainterfaz alcanzable por los nodos y por el contrarioasignar a los dos uacuteltimos ala interfaz de loopback por motivos de seguridad
Cabe destacar que Consul tambieacuten cuenta con una interfaz graacutefica que per-mite ver el estado de los equipos y los servicios registrados y que se encuentra enel mismo puerto que la API HTTP en la direccioacuten httpIP_EQUIPO8500ui
Ejecucioacuten
Tanto Nomad como Consul requieren de la ejecucioacuten de un fichero en todoslos nodos integrantes del cluster Como prueba de concepto se ha decidido usardos servidores para ambos aunque cabe matizar que es un nuacutemero ineficienteya que la caiacuteda de uno de ellos supondriacutea la peacuterdida del cuoacuterum y por tantodel consenso del cluster
En primer lugar se arrancan los servidores que son los encargados de ejecu-tar el protocolo de consenso y gestionar el cluster y a continuacioacuten los clientesque no tienen praacutecticamente estado y dependen de los servidores
En el caso de Consul se debe indicar el directorio donde se guardan losficheros que describen los servicios asiacute como el archivo que especifica el resto delas opciones
1 Se inicia el primer servidor en uno de los equipos
$ consu l agent minuscon f i gminusd i r e t c consu l d s e r v i c e s minuscon f i gminus f i l e consu l_server j son
2 Los siguientes equipos deben unirse al anterior por lo que antildeadimos elargumento join con la direccioacuten del primer servidor Para el caso de otrosservidores
$ consu l agent minuscon f i gminusd i r e t c consu l d s e r v i c e s minuscon f i gminus f i l e consu l_server j son minus j o i n ltIP_servidor1gt
37
Una vez los servidores han alcanzado el consenso y elegido un liacuteder en losclientes
$ consu l agent minuscon f i gminusd i r e t c consu l d s e r v i c e s minuscon f i gminus f i l e c on su l_c l i en t j son minus j o i n ltIP_cualquierServ idorgt
El proceso para iniciar Nomad es igual y los comandos similares sin embargoya no es necesario indicar una direccioacuten IP fija en los equipos sino el nombre dedominio del servicio de Nomad registrado por Consul En el primer servidor
$ nomad agent minusc on f i g nomad_server j son
Y el resto de equipos (con su fichero de configuracioacuten correspondiente)$ nomad agent minusc on f i g nomad_server j son minus j o i n nomad s e r v i c e consu l
Por uacuteltimo para desplegar la aplicacioacuten web se han escrito tres ficherosque detallan las tareas de la interfaz web API y los balanceadores de cargaMediante la CLI
$ nomad run minusaddress=http lt ip_c lus te r gt4646 lt f i l e hclgt
O mediante la API HTTP de Nomad$ cu r l minusX POST minusd ltf i l e hclgthttp lt ip_c lus te r gt4646 jobltjob_namegt
Ansible
Como se puede comprobar con el aumento del nuacutemero de equipos pasa aser inviable manejar todos los nodos a traveacutes de terminal Ademaacutes como seha comentado con anterioridad Nomad requiere que en los nodos clientes es-teacuten instalados las herramientas que soporten las tareas por ejemplo el motorde Docker Por ello para facilitar tanto el arranque como la instalacioacuten de lasdependencias vamos a usar Ansible una herramienta de coacutedigo abierto desarro-llada en Python que permite gestionar configuraciones aprovisionar recursosdespliegue de aplicaciones de forma automaacutetica
A grandes rasgos esta herramienta funciona mediante ficheros en formatoYAML denominados play-books que describen un conjunto de pasos a ejecutaren una lista de equipos remotos Estos pasos son ejecutados por moacutedulos inde-pendientes a traveacutes de SSH es decir en cualquier ordenador con conexioacuten a los
38
hosts dado su contrasentildea o clave puacuteblica puede arrancar el script y realizariacutealos pasos de forma remota gestionando el cluster desde un solo equipo
Se han desarrollado guiones para lo siguiente
Descarga de los binarios de Nomad y Consul en todos los nodos copiade los ficheros de configuracioacuten baacutesicos y modificarlos de acuerdo a cadanodo (nombre del equipo direccioacuten IP)
Instalacioacuten de las dependencias
Arranque de Nomad y Consul
Ansible extiende su funcionalidad a traveacutes de moacutedulos independientes que per-miten por ejemplo instalar paquetes mediante herramientas de gestioacuten de pa-quetes (APT yum) aprovisionar automaacuteticamente maacutequinas virtuales de Ama-zon EC2
Algunas opciones de los ficheros de configuracioacuten de Nomad y Consul sondependientes del nodo particular por ejemplo la interfaz de red Para estetrabajo se ha realizado un moacutedulo para modificar los ficheros de configuracioacutende forma automaacutetica En el repositorio del proyecto se encuentra una carpetadonde se encuentran todos los ficheros necesarios para desplegar un clustertotalmente funcional solo requiere de una liacutenea de terminal con Ansible
$ ans ib l eminusplaybook minus i hos t s minusk ltssh_passgt minusu ltnode_usergt s i t e yml
39
62 Servicio de integracioacuten continua
Se ha implementado un sistema de integracioacuten continua que permite ejecu-tar tareas de compilacioacuten y pruebas de forma distribuida aumentando asiacute elrendimiento de los equipos En primer lugar se detallaraacute los motivos por los quepuede resultar beneficioso para las empresas una implementacioacuten de este tipo alo que seguiraacute los detalles del despliegue
621 DevOps
Metodologiacutea que defiende la comunicacioacuten y colaboracioacuten entre desarrolla-dores de software y los profesionales de operaciones a lo largo de todo el ciclo devida de una aplicacioacuten Estaacute muy relacionado con el desarrollo aacutegil de softwareesto es un enfoque para los proyectos que defiende el desarrollo iterativo e in-cremental donde los requisitos y soluciones evolucionan con el tiempo seguacuten lanecesidad del proyecto DevOps extiende esta filosofiacutea a todas los componentesde un servicio incluyendo sistemas y operaciones
Se trata de un concepto que cada organizacioacuten o empresa adapta a suspropias necesidades y procesos de negocio en este proyecto nos vamos a centraren la integracioacuten continua una praacutectica fundamental tanto del desarrollo aacutegilcomo de esta filosofiacutea
622 Integracioacuten Continua
Se define como una praacutectica de desarrollo software donde los miembros delequipo ponen en comuacuten su trabajo frecuentemente al menos una vez al diacutea21Cada integracioacuten se verifica con una compilacioacuten automaacutetica que incluye laejecucioacuten de pruebas para detectar errores de integracioacuten tan pronto como seaposible
Desde el punto de vista operativo esto supone automatizar la configuracioacutende equipos o el despliegue de maacutequinas virtuales donde compilar el proyecto yejecutar las pruebas y posteriormente eliminarlas Este flujo de trabajo se vebeneficiado en entornos distribuidos ya que el objetivo del desarrollador es com-probar el resultado de las pruebas raacutepidamente sin preocuparse del despliegueo los propios equipos
Para esta prueba de concepto vamos a usar Jenkins un servidor de integra-cioacuten continua escrito en Java que nos permite definir trabajos que contendraacutenla descripcioacuten tanto del entorno como su ejecucioacuten
Este sigue una estructura maestro-esclavo muy similar al de los gestores declusters usados en este proyecto el maestro contiene toda la loacutegica del servicio
21httpmartinfowlercomarticlescontinuousIntegrationhtml
40
trabajos autenticacioacuten y los esclavos son los encargados de la ejecucioacuten ensiacute Jenkins tiene varias viacuteas para aprovisionar los uacuteltimos
Mediante SSH
Interfaz graacutefica
Desarrollar un script propio
Ejecucioacuten de un fichero java
La ventaja de usar planificadores es que el despliegue de esclavos es dinaacutemicoes decir no tener una maacutequina especiacuteficamente configurada para ello DCOS yNomad se encargaraacuten de configurar estos despliegues en sus maacutequinas y poste-riormente eliminarlos Para ello se ha usado la uacuteltima opcioacuten definiendo tareasque descarguen el fichero java Con todo ello se consigue un entorno de inte-gracioacuten continua eficiente que ademaacutes permite la ejecucioacuten de otros servicios deforma independiente
Jenkins permite la creacioacuten de plugins que extienden sus funcionalidadesTanto Nomad22 como Apache Mesos cuentan con uno que permite su integra-cioacuten
Para esta prueba se va a usar el mismo proyecto que para el caso de usode orquestacioacuten de contenedores la aplicacioacuten web al que se le ha antildeadido untest para comprobar que se conecta correctamente a la base de datos medianteMocha un framework de Nodejs Por otro lado se antildeade el plugin de git ya queel coacutedigo se obtiene de GitHub el repositorio remoto de control de versiones delproyecto
El proceso general de ejecucioacuten seriacutea como sigue
1 Se ejecuta el maestro de Jenkins como tarea Docker partiendo de la imagenoficial
2 Al arrancar un trabajo se manda una tarea a los planificadores que laasignaraacuten a un nodo cliente Esta tarea consiste en la descarga del ficherode configuracioacuten Java y arrancarlo configurando el equipo como un clientede Jenkins temporalmente
3 Jenkins ejecuta el trabajo en el nuevo cliente en este caso iniciar la apli-cacioacuten web iniciar las pruebas y generar un informe
4 Se elimina el cliente
A continuacioacuten se detallan los matices de cada herramienta a la hora de imple-mentar este servicio
22Desarrollado por Ivo Verberk httpwwwivoverberknl
41
623 Jenkins con Nomad
El plugin permite la ejecucioacuten del fichero Java mediante dos controladorescontenedores Docker y Java En este proyecto nos hemos decantado por el pri-mero ya que nos ahorra instalar la maacutequina virtual de java en todos los nodoscliente Por ello se ha construido un contenedor base con Java para la ejecucioacutendel fichero de configuracioacuten y Nodejs para lanzar la aplicacioacuten web
El plugin se configura con la direccioacuten IP del cluster y el contenedor queejecuta el esclavo Jenkins Por su parte el trabajo en Jenkins se define conel repositorio en GitHub donde se aloja el coacutedigo del proyecto a probar y loscomandos a ejecutar en este caso npm update y npm test
624 Jenkins con DCOS
En el caso de DCOS su sistema de paquetes incluye Jenkins por lo queal instalarlo ya se tiene la configuracioacuten de Mesos totalmente funcional Sinembargo para ejecutar la aplicacioacuten en particular y las pruebas se requiere deNodejs en los equipos esclavos por ello debemos antildeadir un plugin de Jenkinsque permite instalar este entorno antes de ejecutar el trabajo Una vez hechoesto soacutelo queda definir la tarea igual que en el caso anterior
Cabe destacar que Mesosphere tambieacuten ha desarrollado un plugin que per-mite hacer despliegues en Marathon de tal manera que permitiriacutea con cadacommit del coacutedigo compilar la imagen del contenedor Docker y desplegarlaautomaacuteticamente aunque en este proyecto no se ha hecho pruebas de esta fun-cionalidad
42
7 Escalando la infraestructura
Uno de los factores clave que se busca a la hora de implementar sistemasdistribuidos es el poder escalar la infraestructura de forma maacutes sencilla estoes detectar que las maacutequinas estaacuten alcanzando el liacutemite de su capacidad yaumentar eacutesta ya sea mejorando sus caracteriacutesticas teacutecnicas o antildeadiendo maacutesnodos al cluster
El coacutedigo y todos los ficheros de configuracioacuten de esta seccioacuten tambieacuten sepueden encontrar en el repositorio del proyecto en GitHub23
71 Disentildeo
Microsoft Azure permite organizar los servicios cloud de forma loacutegica a traveacutesde grupos de recursos y asiacute poder crear o eliminar eacutestos en conjunto parauna aplicacioacuten determinada (por ejemplo una aplicacioacuten web suele requerir demaacutequinas virtuales bases de datos almacenamiento) Ademaacutes dispone dela opcioacuten de crear plantillas en formato JSON que permite al desarrolladordefinir los recursos y su interrelacioacuten para desplegar de forma automaacutetica unainfraestructura TI en la nube
Azure tambieacuten ofrece la posibilidad de monitorizar el estado de las maacutequinasvirtuales a traveacutes de extensiones lo que permite configurar el escalado automaacute-tico al alcanzar cierto liacutemite definido por el operador Eacutesta es a priori la formaen que deberiacutea implementarse hablando en teacuterminos de eficiencia sin embargoesta aproximacioacuten es totalmente dependiente de la plataforma es decir no sepuede extrapolar a otro proveedor o sobre recursos propios sin realizar un nue-vo disentildeo En este proyecto las tareas que son ejecutadas por estos equipos notienen estado ya que todo lo relativo a la persistencia lo hemos asignado fueradel cluster esto permite escalar la plataforma a traveacutes de otra aproximaciones
Las plantillas aceptan una serie de variables a indicar por el usuario entreotras los conjuntos de escala para definir los nodos aceptan una variable quedefine el nuacutemero de maacutequinas que los componen Por otro lado Azure ofreceuna API REST y kits de desarrollo software (SDK por sus siglas en ingleacutes) quepermiten su despliegue de forma programaacutetica Aprovechando estas facilidadesen este proyecto se va a aproximar la escalabilidad con el sucesivo desplieguede la infraestructura de forma automaacutetica se monitorizan los equipos y si sedetecta una maacutequina excesivamente cargada se aumenta el nuacutemero de equiposen la plantilla y se vuelve a desplegar
23httpsgithubcomAntonioAlfrzCloud-Orchestrators
43
En este proyecto se han disentildeado las plantillas para desplegar la arquitec-tura necesaria tanto de Nomad como de DCOS En el caso de la primera eldespliegue es maacutes descriptivo ya que incluye maacutequinas virtuales grupos de se-guridad redes En el caso de DCOS Azure cuenta con un servicio especiacuteficopara clusters gobernados por DCOS denominado Azure Container Service queincluye los componentes necesarios y la instalacioacuten ya realizada
72 Implementacioacuten
En primer lugar para monitorizar el estado de los equipos se va a usar laherramienta Nagios un sistema que permite controlar el estado del hardwarey los servicios de un equipo Se trata de una herramienta muy completa de laque se va a usar su capacidad para ejecutar comandos (plugins) en los nodospara detectar picos de carga generar alertas y ejecutar programas para estoseventos
Se ha desplegado una maacutequina virtual con esta herramienta en ambos siste-mas y se ha instalado una extensioacuten de Nagios (Nagios Remote Plugin Executor)en todos los nodos que permite ejecutar comprobaciones remotamente en con-creto para esta prueba de concepto medir el nivel de saturacioacuten de la unidadcentral de procesamiento (CPU por sus siglas del ingleacutes) Cuando sucede uncambio de estado de una maacutequina esto es cuando este paraacutemetro supera el liacutemi-te definido por el operador Nagios permite actuar en consecuencia ejecutandoprogramas por ello se ha desarrollado un script que ejecuta lo siguiente
Un programa desarrollado en Python con el SDK de Azure que modificalas plantillas y despliega los recursos
Un guioacuten de Ansible para instalar todos los componentes necesarios en lasnuevas maacutequinas y arrancar de nuevo el cluster y las aplicaciones
44
8 Resultados y conclusiones
En este uacuteltimo apartado se da una visioacuten global del proyecto asiacute como a lasconclusiones maacutes importantes a las que se ha llegado y posibles temas futurosde desarrollo
81 Comparacioacuten
Ambas herramientas ofrecen las funcionalidades para gestionar los recursoseficientemente ofreciendo a los desarrolladores una plataforma donde desplegarsus aplicaciones de forma distribuida independientemente de los equipos fiacutesicosy el hardware que las soporten
DCOS es una herramienta que en un comienzo fue privativa pero cuyos res-ponsables la empresa Mesosphere decidieron publicar una versioacuten de coacutedigoEacutesta nos permite gestionar un cluster de una forma sencilla y usable ademaacutes decomplementarlo con otras herramientas como el balanceador de carga integradoo la autenticacioacuten de usuarios ademaacutes estaacute basada en Apache Mesos un pro-yecto de relativa madurez y con el soporte de la Apache Software FoundationDe forma resumida DCOS ofrece muchas posibilidades y servicios a cambiode una arquitectura e instalacioacuten maacutes compleja
Por su parte HashiCorp con menor tiempo de desarrollo ha conseguidouna herramienta muy sencilla de desplegar que ademaacutes cumple con todas lasfuncionalidades baacutesicas ejecutando un simple binario en cada nodo se puededesplegar un gestor de clusters totalmente funcional Sin embargo no cuentacon todas las posibilidades de Mesos (Nomad cuenta con menos controladoresque entornos posibles de Mesos) ni con los antildeadidos de DCOS lo que implicael uso de otras herramientas para complementar el servicio (Consul HAProxy)
De entre las dificultades encontradas al usar estas herramientas y desplegaraplicaciones sobre ellas se puede destacar la depuracioacuten en ocasiones se desco-noce si un error viene de la propia herramienta de la aplicacioacuten desplegada o delequipo fiacutesico si no se cuenta con un sistema de procesamiento de registro unose puede encontrar con muacuteltiples terminales abiertas inspeccionando numerososficheros de registro buscando posibles errores Ademaacutes no dejan de ser solucio-nes que para usar eficientemente se debe conocer parte de su funcionamientoy sintaxis a la hora de describir la tareas lo que supone un esfuerzo antildeadido yaque cada una tiene sus particularidades y liacutemites
45
82 Conclusiones
En una sociedad cada vez maacutes digital las empresas deben adaptarse a unmercado cuya demanda de contenido no deja de crecer Las nuevas arquitecturascomo microservicios asiacute como la gran cantidad de datos generada implica queuna mejor gestioacuten de los recursos y la rapidez para desplegar o escalar solucionesdando valor al cliente lo maacutes raacutepido posible es uno de los objetivos de todas lasempresas de base tecnoloacutegica
Las ventajas que ofrecen los planificadores con aplicaciones distribuidas sonnumerosas sin ir maacutes lejos empresas tan punteras como Google llevan maacutesde 10 antildeos orquestando contenedores24 Por un lado permiten aumentar elrendimiento de los equipos propios y por otro implementar un servicio comoplataforma para despliegues distribuidos sobre cualquier conjunto hardware deesta forma se provee un servicio similar al de la nube puacuteblica pero con laprincipal diferencia de que se elimina la independencia con el proveedor (vendorlock-in) esto es las aplicaciones no tienen limitaciones impuestas por eacuteste talescomo lenguaje de programacioacuten o herramientas y permite despliegues hiacutebridosentre recursos propios y la nube
83 Objetivos conseguidos
Implementacioacuten de los planificadores propuestos en la nube Se ha en-tendido y detallado el funcionamiento de estas herramientas y se hanimplementado en el servicio de infraestructura de Microsoft Azure
Despliegue de aplicaciones y servicios distribuidos Servicios que se usanactualmente en la industria del desarrollo software asiacute como una aplica-cioacuten web con una arquitectura moderna han sido desplegados de formadistribuida en los equipos cumpliendo con la funcionalidad esperada ade-maacutes de consiguiendo una alta disponibilidad
Aproximacioacuten de arquitectura escalable Se ha hecho una aproximacioacutende infraestructura escalable de forma que sea parcialmente extrapolable aotros proveedores
24httpwwwnextplatformcom20160322decade-container-control-google
46
84 Liacuteneas de investigacioacuten
Siguiendo con la materia de este proyecto se presentan posibles liacuteneas deinvestigacioacuten
Analizar el despliegue con estas herramientas de aplicaciones de Big Datay comparar la eficiencia con respecto a soluciones especializadas
Analizar el rendimiento de los algoritmos de planificacioacuten antes pruebasde estreacutes y situaciones de alta contienda
Comparar el uso de estas herramientas con las praacutecticas actuales de laindustria o implementacioacuten en un sistema de produccioacuten real
47
Referencias
[1] LA Barroso y U Houmllzle laquoThe Datacenter as a Computer An Introduc-tion to the Design of Warehouse-Scale Machinesraquo En Morgan amp ClaypoolPublishers ()
[2] Systems Research Group ndash NetOS (University of Cambridge) The evolu-tion of cluster scheduler architectures 2016 url httpswwwclcamacukresearchsrgnetoscamsasblog2016-03-09-scheduler-architectureshtml
[3] A Das I Gupta y A Motivala SWIM Scalable Weakly-consistent Infection-style Process Group Membership Protocol Inf teacutec Dept of ComputerScience Cornell University url https www cs cornell edu ~asdasresearchdsn02-swimpdf
[4] D Dubhashi y A Das Mastering Mesos PACKT Publishing mayo de2016
[5] The Apache Software Foundation Apache Mesos documentation urlhttpsmesosapacheorg
[6] David Greenberg Building Applications on Mesos OrsquoReilly Media 2016[7] Armand Grillet Comparison of Container Schedulers Inf teacutec Technische
Universitaumlt Berlin[8] HashiCorp Consul documentation url httpswwwconsulio[9] HashiCorp Nomad documentation url httpsdcosio[10] Dan C Marinescu Cloud computing theory and practice Morgan Kauf-
mann 2013[11] Mesosphere DCOS documentation url httpswwwnomadproject
io[12] Microsoft Azure documentation url httpsazuremicrosoftcom
es-esdocumentation[13] D Ongaro y J Ousterhout In Search of an Understandable Consensus
Algorithm Inf teacutec Stanford University url httpsraftgithubioraftpdf
[14] Fei Teng laquoRessource allocation and schelduling models for cloud compu-tingraquo Tesis de mtriacutea Ecole Centrale Paris 2011
[15] A Williams y col Automation and Orchestration with Docker and Contai-ners A Comprehensive Overview of the Docker and Container Ecosystem3 The New Stack 2016
48
- Resumen
- Summary
- Iacutendice de figuras
- Introduccioacuten y objetivos
-
- Contexto
- Objetivos
- Estructura del documento
-
- Cloud Computing
- Nuevas cargas de trabajo
- Gestioacuten de recursos Planificadores
-
- Sistemas distribuidos
-
- Clasificacioacuten
-
- Herramientas
-
- DCOS
-
- Apache Mesos
- Ejemplos de uso
-
- Nomad
-
- Protocolo de consenso Raft
- Protocolo gossip SWIM
- Planificacioacuten
-
- Casos de uso y despliegue
-
- Aplicacioacuten Web
-
- DCOS
- Nomad
-
- Servicio de integracioacuten continua
-
- DevOps
- Integracioacuten Continua
- Jenkins con Nomad
- Jenkins con DCOS
-
- Escalando la infraestructura
-
- Disentildeo
- Implementacioacuten
-
- Resultados y conclusiones
-
- Comparacioacuten
- Conclusiones
- Objetivos conseguidos
- Liacuteneas de investigacioacuten
-
51 DCOS
DCOS es un proyecto de coacutedigo abierto7 creado y desarrollado por la empre-sa Mesosphere Se describe como un sistema operativo distribuido que abstraelos recursos de un cluster (capacidad de procesamiento memoria) permite lagestioacuten de muacuteltiples ordenadores de forma transparente y simplifica la instala-cioacuten de aplicaciones distribuidas
Su arquitectura se puede comparar a la de Linux en teacuterminos de nuacutecleo(kernel) y espacio de usuario El primero consta de recursos protegidos a losque no puede acceder el usuario e involucra operaciones de bajo nivel comoasignacioacuten de recursos o aislamiento de procesos En el espacio de usuario seejecutan las aplicaciones y servicios de maacutes alto nivel
Siguiendo con este siacutemil el nuacutecleo de DCOS estaacute basado en Apache Mesosque se explicaraacute en un apartado posterior y el espacio de usuario que estaacute com-prendido por los componentes del sistema esto es las diferentes herramientasque en conjunto conforman DCOS y los servicios encargados de planificar yejecutar las aplicaciones y tareas del usuario
Figura 7 Arquitectura DCOSFuente httpsdcosio
De entre los componentes que conforman DCOS destacan
Admin Router Balanceador de carga central basado en NGINX que dis-pone un proxy entre todos los servicios en el puerto 80 permitiendo sugestioacuten mediante la interfaz graacutefica Ademaacutes se encarga de la autenticacioacutenpara acceder al panel de administracioacuten
Cosmos Gestor de paquetes de las aplicaciones
Diagnostics Se ejecuta en todos los nodos y se encarga de monitorizar elestado de los daemons que sustentan DCOS
7Desde abril de 2016 httpsmesospherecomblog20160419open-source-dcos
14
Exhibitor Gestiona y automatiza el despliegue de ZooKeper la herra-mienta que provee de configuracioacuten centralizada y registro de nombres
Marathon Equivale al proceso init de los sistemas tipo Unix esto es elprimer proceso en ejecucioacuten tras la carga del kernel y que genera los demaacutesprocesos Se encarga de arrancar y monitorizar las aplicaciones y servicios
Mesos-DNS Servicio de DNS interno que define el dominio mesos pa-ra nodos y tareas en el cluster es decir permite resolver nombres conindependencia de la direccioacuten fiacutesica
Minuteman Balanceador de carga integrado a nivel TCPUDP disponiblepara las propias aplicaciones
Por otra parte se definen como servicios a las diferentes aplicaciones dis-tribuidas que DCOS permite instalar en el cluster y que pueden haber sidodesarrollados por la misma empresa Mesosphere o por terceros por ejemploApache Spark Jenkins o Apache Hadoop En la figura 8 se muestra un diagramade los servicios disponibles incluyendo algunos de las aplicaciones distribuidasque soporta DCOS
Figura 8 Servicios DCOSFuente httpsdcosio
511 Apache Mesos
El nuacutecleo de DCOS estaacute basado en Apache Mesos un proyecto de coacutedigoabierto creado por la Universidad de California Berkeley y desarrollado actual-mente por la fundacioacuten Apache Se trata de un administrador de clusters queabstrae los recursos y los dispone para diferentes aplicaciones y entornos de tra-bajo distribuidos (frameworks) mediante una interfaz comuacuten En el momento deredaccioacuten de este proyecto Apache Mesos soportaba una variedad de entornosque abarcaba desde Big Data (Apache Spark Hadoop) hasta bases de datos(Cassandra Hypertable)
15
Arquitectura
Mesos se basa en la asignacioacuten de dos roles diferentes a los nodos
Maestros (Masters) Se encargan de la gestioacuten y reparticioacuten de los recursospara los diferentes entornos de trabajo mediante ldquoofertas de recursosrdquo deacuerdo a los disponibles y a la poliacutetica de asignacioacuten (planificacioacuten en dosniveles)
Esclavos (Slaves) Ordenadores donde se ejecutaraacuten las aplicaciones y cu-yos recursos son ofertados por los maestros
En el caso de fallo del maestro las tareas pueden seguir ejecutaacutendose perono se podraacute asignar nuevos recursos ni tareas por ello pueden existir varios enel cluster para configuraciones de alta disponibilidad pero soacutelo uno orquesta alos esclavos
Para la eleccioacuten del master liacuteder Mesos usa Apache ZooKeeper un proyectode software desarrollado por la misma fundacioacuten cuyo objetivo es proveer deun servicio de configuracioacuten centralizado y registro de nombres8
Por otra parte los entornos de trabajo son los programas que deciden final-mente queacute recursos se van a usar y se encargan de que los esclavos ejecuten lastareas Eacutestos se ejecutan sobre Mesos y constan de dos componentes
Planificador (Scheduler) Optimiza y decide los recursos a utilizar de losofertados informando a los Masters
Procesador (Executor) Ejecuta las aplicaciones o servicios en los esclavos
El objetivo final es conseguir una interfaz liviana tolerante a fallos paracualquier tipo de entorno de trabajo de tal manera que en los esclavos del clusterpuedan ejecutarse simultaacuteneamente tareas con necesidades y duracioacuten diferentesPara ello se basa en dos conceptos asignacioacuten y aislamiento de recursos
Asignacioacuten de recursos
En el cluster pueden coexistir entornos de trabajo con tareas de larga dura-cioacuten y con gran consumo de recursos con tareas cortas que los ocupan y liberancon rapidez El maestro integra un moacutedulo de asignacioacuten de recursos (allocationmodule) que se encarga del algoritmo de distribucioacuten
En el momento de escribir este proyecto estaban desarrollados dos moacutedulosuno mediante el cual el usuario puede asignar prioridades y otro que implementa
8httpszookeeperapacheorg
16
el algoritmo Dominant Resource Fairness9 a grandes rasgos se determina entodos los esclavos la tarea en ejecucioacuten que necesita maacutes recursos y se calcula laproporcioacuten del recurso de mayor peso con respecto al total por ejemplo si unatarea ocupa 2 GB de memoria con respecto a 10 GB totales que tiene el clusterse le asigna un dominant share del 20 la tarea se asignaraacute al nodo con menordominant share
Aislamiento de recursos
Para conseguir que tareas de diferentes entornos de trabajo y con distin-ta naturaleza se ejecuten simultaacuteneamente en un mismo nodo Mesos usa loscontenedores Linux (descritos en la seccioacuten 3)
Funcionamiento
La figura 9 muestra el esquema de la arquitectura de Apache Mesos conalta disponibilidad (tres maestros) y con dos entornos de trabajo ejecutaacutendo-se Hadoop que permite el almacenamiento y procesamiento de gran cantidadde datos para proyectos de big data y un sistema que implementa la interfazsistema de paso de mensajes MPI
Como se puede observar el sistema ZooKeeper elige a un solo maestro comoliacuteder y eacuteste orquesta el cluster comunicando los esclavos con los planificadoresde los diferentes entornos de trabajo Tambieacuten se puede observar como las tareasde los distintos entornos estaacuten distribuidas entre los tres esclavos disponibles
Figura 9 Arquitectura de Apache MesosFuente httpsmesosapacheorg
El proceso de asignacioacuten se realiza como sigue en primer lugar un usuariosolicita la ejecucioacuten de una tarea mediante la interfaz de cada entorno de traba-jo (interfaz graacutefica API HTTP ) De forma paralela un esclavo informa almaestro de los recursos que tiene libres En consecuencia eacuteste se lo notifica almoacutedulo de asignacioacuten que en funcioacuten de su configuracioacuten decide cuaacutento ofertar
9httpspeopleeecsberkeleyedu~aligpapersdrfpdf
17
y a queacute entorno de trabajo y enviacutea la oferta a los planificadores Eacutestos respondenal maestro con queacute recursos ha decidido usar para cada tarea Finalmente lastareas son enviadas al esclavo seleccionado el cual asigna los recursos indicadosal procesador (executor) quien finalmente las ejecuta
Cabriacutea pensar que esta metodologiacutea puede conducir a situaciones en lasque un entorno podriacutea quedarse con tareas sin ejecutarse a la espera de unaoferta satisfactoria para ello Mesos implementa un sistema de filtros medianteel cual los entornos especifican los requisitos miacutenimos que debe cumplir unaoferta por ejemplo se puede especificar en queacute nodos debe desplegarse la tareaEste sistema estaacute disentildeado asiacute con el objetivo de mantener lo maacutes transparenteposible esta herramientas de forma que acepte entornos de trabajo de distintasnaturalezas
512 Ejemplos de uso
Grandes empresas estaacuten usando Apache Mesos con eficacia de acuerdo a susnecesidades e infraestructuras Caben destacar
Ebay En el modelo de implementacioacuten continua en esta empresa10 cadadesarrollador cuenta con su propia instancia que se ejecuta en una maacutequinavirtual dedicada lo que ha conllevado un uso de los recursos poco eficiente Enuna prueba de concepto consiguieron realizar una herramienta de integracioacutencontinua distribuida basada en un cluster con Apache mesos y con el entornoMarathon y Jenkins
Apple Anuncioacute que el motor de su famosa herramienta de asistencia per-sonal para iPhones Siri estaacute desplegada sobre Apache Mesos11 Para ello handesarrollado su propio entorno para facilitar a los ingenieros a desplegar los ser-vicios que la herramienta necesita para resolver las peticiones de los usuarios
Twitter Desarrolloacute su propio entorno denominado Aurora y actualmentegestionan sus recursos y miden el coste de las tareas que los empleados usancon el objetivo de que sean conscientes del gasto que puede suponer un usoinadecuado de la infraestructura12
10httpwwwebaytechblogcom20140404delivering-ebays-ci-solution-with-apache-mesos-part-i11httpwwwbusinessinsidercomapple-siri-uses-apache-mesos-2015-812httpswwwlinuxcomNEWS4-UNIQUE-WAYS-UBER-TWITTER-PAYPAL-AND-HUBSPOT-USE-APACHE-MESOS
18
52 Nomad
Herramienta de coacutedigo abierto de gestioacuten de clusters creada y desarrolladapor Hashicorp13 que permite el despliegue de aplicaciones y procesos de formadistribuida
Las principales diferencias con Apache Mesos a grandes rasgos son
Arquitectura maacutes ligera Nomad soacutelo requiere de un fichero para funcionarejecutaacutendolo con las correspondientes configuraciones en todos los nodosrealiza las funciones de gestioacuten del cluster eleccioacuten de liacuteder planificacioacutende recursos y ejecucioacuten de las tareas
Centro de datos y regiones muacuteltiples Su arquitectura estaacute orientada afacilitar la gestioacuten de diferentes centros de datos geograacuteficamente distri-buidos
Entorno de ejecucioacuten Las tareas se definen y son interpretadas mediantecontroladores integrados en Nomad que se valen de los recursos y herra-mientas de los nodos clientes para ejecutarlas Esta integracioacuten dificultael desarrollo de controladores por parte de terceros a diferencia de Mesosque delega dicha responsabilidad en los entornos de trabajo externos alproyecto
Usa un planificador de estado compartido con respecto a la planificacioacutenen dos niveles de Mesos
Antes de entrar en maacutes detalle en la arquitectura es importante definir lossiguientes teacuterminos
Controlador (Driver) Software que se encarga de interpretar las definicionesde las tareas y ejecutarlas semejante a los procesadores de los entornosde trabajo de Mesos A la hora de redactar este proyecto Nomad contabacon controladores para contenedores Docker virtualizacioacuten de maacutequinasmediante el emulador QEMU aplicaciones java y archivos binarios
Grupo de trabajo (Task Group) Conjunto de tareas que se ejecutan en elmismo nodo cliente
Trabajo (Job) Conjunto loacutegico de tareas y grupos de trabajo que se despliegana la vez
Asignacioacuten (Allocation) Relacioacuten entre un grupo de trabajo y el cliente don-de se ejecuta
Evaluacioacuten (Evaluation) Proceso mediante el cual Nomad planifica y ges-tiona el registro o actualizaciones de los trabajos
13httpswwwhashicorpcom
19
Nomad sigue una arquitectura maestro-esclavo similar a la de Apache Mesosmuacuteltiples servidores acuerdan entre siacute un liacuteder que gestiona la planificacioacuten detareas en los clientes que soacutelo conocen sus asignaciones y las ejecutan
Todos los servidores participan paralelamente en tareas de planificacioacuten derecursos y asignacioacuten de tareas y ademaacutes entre ellos eligen un liacuteder que seencarga de la coordinacioacuten de la suscripcioacuten de los clientes al cluster y de lagestioacuten de las peticiones
Los clientes estaacuten configurados para comunicarse con el servidor usando lla-madas a procedimiento remoto (RPC por sus siglas en ingleacutes) que permite unordenador ejecutar coacutedigo en otra maacutequina Mediante esta tecnologiacutea los nodosclientes avisan de su estado e informa de sus asignaciones recursos y controla-dores disponibles
Existe la posibilidad de gestionar varios centros de datos agrupados en regio-nes eacutestas son independientes pero permite definir tareas o comprobar el estadode todas ellas desde cualquier punto A continuacioacuten se muestra una figura dela arquitectura a alto nivel de esta configuracioacuten
Figura 10 Arquitectura multi-regioacuten en NomadFuente httpswwwnomadprojectio
La herramienta se sustenta sobre tres protocolos fundamentales un protocolode consenso entre los servidores para compartir informacioacuten sobre su estado yel liacuteder un protocolo Gossip para la gestioacuten entre regiones y el planificador detareas
521 Protocolo de consenso Raft
El objetivo es obtener consistencia en un conjunto de nodos que comparteninformacioacuten es decir si un cliente realiza un cambio que todos los nodos veanla misma informacioacuten a la vez y ademaacutes sea tolerante a fallos Para ello se basaen el algoritmo Raft[13] que se detalla brevemente a continuacioacuten
20
Los nodos participantes en el algoritmo pueden estar en tres estados
Liacuteder (Leader) Todos los cambios que realicen en el cluster pasan por eacutel pri-mero
Seguidor (Follower) Nodo pasivo cuya responsabilidad es responder a laspeticiones del nodo liacuteder
Candidato (Candidate) Maacutequina que no ha encontrado liacuteder y solicita sueleccioacuten
Supongamos que tenemos cinco equipos que acaban de arrancar el protocoloEn la figura 11 se observan los nodos y sus respectivos registros a la derecha
Figura 11 Equipos sin consenso ejecutando el protocolo RAFTFuente httpsgithubcomongardieraftscope
Al comenzar todos los nodos son seguidores esperando recibir comunicacioacutende un nodo que actuacutee como liacuteder Cada nodo tiene un tiempo de espera aleatoriodespueacutes del cual si no es informado por un liacuteder pasa a estado candidato y pideel ldquovotordquo al resto de los participantes El algoritmo divide el tiempo en plazos uncandidato pasa a liacuteder si recibe la mayoriacutea de los votos en un plazo determinadoSe define mayoriacutea o cuoacuterum (quorum) comolceil
N2rceil
+ 1 (1)
donde N representa el nuacutemero de nodos
Para el ejemplo propuesto de 5 equipos se requieren de 3 votos Soacutelo losnodos que se encuentren en estado seguidor pueden votar una uacutenica vez a laprimera solicitud que reciba dentro de un plazo
Supoacutengase que el nodo denotado con S1 ha cumplido su tiempo de espera yrealiza la peticioacuten de voto (figura 12) A partir de este momento se pueden dartres casos
La maacutequina gana la eleccioacuten y pasa a ser liacuteder informando al resto
Otro servidor se establece como liacuteder en el mismo momento
Varios nodos pasan a ser candidatos por lo que ninguno consigue los votos
21
Figura 12 Un equipo pasa a estado candidato (RAFT)
Si un candidato recibe un aviso de un liacuteder en el mismo plazo el primeropasa a ser seguidor y se acaba la eleccioacuten de liacuteder
Por otro lado si un equipo candidato no recibe los votos en el plazo y agotasu tiempo de espera avanza al siguiente plazo y repite el proceso de votacioacutenLa tercera posibilidad puede conllevar a un estado indefinido ya que varioscandidatos pueden agotar su tiempo de espera al mismo tiempo y repartir losvotos Para solventarlo el algoritmo establece tiempos de espera aleatorios paralos candidatos
Siguiendo con el ejemplo propuesto el servidor S1 pasa a ser el liacuteder Cadacierto tiempo eacuteste debe realizar avisos a los nodos seguidores para no agotar sutiempo de espera
En este momento el cluster de servidores estaacute en ldquoconsensordquo y la informacioacutenen todos los nodos estaacute actualizada Un cambio en la informacioacuten inicia unproceso de replicacioacuten el liacuteder registra el cambio lo pasa al resto de nodos yuna vez eacutestos responden el cambio se hace efectivo
Supoacutengase que se realiza un cambio en los datos en la figura 13 en la partederecha se observa el cambio en el registro del servidor S1 que informa a losnodos seguidores En consecuencia los nodos registran el cambio y responden aS1
Figura 13 Cambio en un registro (RAFT)
Una vez el cuoacuterum (en el ejemplo tres equipos) informa al liacuteder de que
22
ha registrado el cambio el liacuteder lo hace efectivo en su sistema y notifica a losnodos que hacen lo mismo En la figura 14 el enviacuteo todaviacutea no ha llegado ala maacutequina S3 y se observa que no ha hecho efectivo el cambio (en el registroaparece punteado)
Figura 14 Aprobacioacuten del resto de equipos (RAFT)
Este protocolo funcionaraacute correctamente mientras exista un nuacutemero de nodosen funcionamiento igual o superior al cuoacuterum en el ejemplo propuesto elcuoacuterum es tres por lo que el sistema puede tolerar la caiacuteda de dos de los equipos
522 Protocolo gossip SWIM
Nomad permite la gestioacuten simultaacutenea de varios centros de datos reparti-dos en regiones geograacuteficamente separadas requiriendo de un protocolo ligeroque mantenga a los miembros actualizados sobre los participantes del conjun-to Para ello usa una ligera variante del protocolo SWIM[3] (Scalable Weakly-consistent Infection-style Process Group Membership Protocol) desarrollada porHashiCorp Estaacute clasificado como un protocolo de tipo gossip que debe su nom-bre a la semejanza con coacutemo se distribuye un rumor en una red social
SWIM se sustenta en dos caracteriacutesticas fundamentales la deteccioacuten de fallosy la distribucioacuten de la informacioacuten relativa a los miembros A continuacioacuten sedetalla el funcionamiento de ambos componentes
Deteccioacuten de fallos
Este componente tiene dos paraacutemetros el periodo de protocolo T y el nuacutemerode subgrupos de deteccioacuten de fallos k en los que se dividen los nodos Paracomprobar la comunicacioacuten entre dos maacutequinas usa la utilidad ping basadaen el protocolo ICMP La deteccioacuten de caiacuteda de un servidor sigue el siguientealgoritmo
Durante el periodo T cada miembro Mi de un subgrupo elige otro al azar Mjdel mismo subgrupo y le enviacutea un mensaje ping para comprobar su estado Enel caso de que se cumpla un tiempo de espera determinado por una estimacioacuten
23
del tiempo de ida y vuelta (RTT por sus siglas en ingleacutes) de la red y no hayarespuesta Mi le vuelve a enviar un mensaje ping indirectamente a traveacutes deun nuacutemero k de miembros escogidos aleatoriamente De no recibir ninguna res-puesta Mi establece que Mj ha sufrido un fallo y lo etiqueta como ldquosospechosordquoinformando al componente de distribucioacuten
Figura 15 Diagrama de tiempo del protocolo SWIMFuente httpswwwcscornelledu
Componente de distribucioacuten
Se encarga de informar de cualquier cambio en los miembros a todo el con-junto Los eventos de nodo caiacutedo y la unioacuten o disociacioacuten de un miembro setransmiten a todos los servidores para que actualicen sus lista Para distribuirla informacioacuten a todos los nodos se podriacutea usar el meacutetodo de multicast perosuele estar deshabilitado Por ello se utiliza una teacutecnica de transmisioacuten denomi-nada Piggybacking mediante la cual se adjunta a los propios mensajes PINGy ACK del algoritmo la informacioacuten a distribuir reduciendo asiacute la congestioacutenen la red
523 Planificacioacuten
Proceso encargado de distribuir las tareas entre los nodos clientes de acuerdoa su estado
El planificador de Nomad estaacute basado en las publicaciones de Google sobresus herramientas de gestioacuten de clusters Borg y Omega14 y entiende los trabajosdescritos por el usuario como un estado deseado es decir su despliegue en unamaacutequina cliente de forma correcta y los clientes como el estado actual esto eslo que se encuentra en ejecucioacuten El registro actualizacioacuten o cancelacioacuten de un
14httpresearchgooglecompubspub43438html
24
trabajo asiacute como el fallo de un nodo cliente implican un cambio de estado atramitar por el sistema lo que se define como evaluacioacuten (evaluation) Esto uacutelti-mo supone comparar el estado actual (clientes) con el estado deseado (conjuntode trabajos registrados) y enviarlos a los planificadores correspondientes que seencargaraacuten de asignar las tareas a los nodos clientes
Figura 16 Procedimiento de asignacioacuten en NomadFuente httpswwwnomadprojectio
En la figura 16 se observa el flujo de trabajo en el que las distintas evalua-ciones se encolan en el evaluation broker que se ejecuta en el servidor liacuteder ygestiona las evaluaciones pendientes asignaacutendoles prioridades
A continuacioacuten los nodos servidores ejecutan los scheduling workers queprocesan las evaluaciones llamando a los distintos planificadores que generanun plan de asignacioacuten esto es un conjunto de relaciones entre las tareas y losnodos clientes donde se ejecutaraacuten Este proceso se divide en dos fases primerose descartan aquellos clientes que no cumplan los requisitos y posteriormentese asigna una calificacioacuten al resto Se selecciona el nodo con mayor puntuacioacuteny se encola el plan en el gestor que se ejecuta en el servidor liacuteder Existen tresplanificadores de acuerdo al tipo de trabajo
Service Incluye aquellos trabajos que estaacuten destinados a ejecutarse en un pe-riacuteodo largo de tiempo Para realizar las asignaciones el planificador evaluacuteala mayor parte de los nodos y usa una versioacuten del algoritmo Best fit in-fluenciada por el trabajo de Google en su herramienta Borg Se trata deun algoritmo de planificacioacuten que sacrifica tiempo a cambio de maximizarel rendimiento de los clientes asignando la tarea a la maacutequina que tengala mayor carga de trabajo con el objetivo de reducir equipos en funciona-
25
miento
Batch Tareas que incluyen listas de comandos en general de menor duracioacuteny que no requieren interaccioacuten con el usuario Se vale del algoritmo deSparrow desarrollado por la universidad de Berkeley15 para limitar losnodos clientes a evaluar
System Trabajos destinados a ejecutarse en todos los nodos incluso los que seunen al cluster posteriormente
Core Mantenimiento interno de Nomad
Una vez se ha realizado el proceso de planificacioacuten el nodo liacuteder lo registra enla cola de planes (plan queue) que se encarga de asignarles prioridad y manejarcondiciones de carrera es decir que no accedan a los recursos de los clientes sincontrol y evitar que eacutestos superen su capacidad
La maacutequina liacuteder del conjunto puede de este modo aceptar una asignacioacuteny ser ejecutada por los clientes o por el contrario rechazaacutersela al planificadorlo que implicariacutea realizar un plan parcial o totalmente nuevo
Finalmente el estado de las evaluaciones se actualizan y los clientes soninformados de las asignaciones ejecutaacutendose las tareas
15httppeopleeecsberkeleyedu~keopublicationssosp13-final17pdf
26
6 Casos de uso y despliegue
Con el objetivo de mostrar las posibles utilidades que este tipo de sistemaspueden tener en las infraestructuras TI actuales se han desplegado las dos he-rramientas en la nube Microsoft Azure usando su servicio cloud de instancias demaacutequinas virtuales Linux para simular un conjunto de ordenadores conectadosentre siacute por una red LAN Sobre ellas se ha implementado dos casos de usouna aplicacioacuten web con una arquitectura con cierta orientacioacuten a microserviciosy un sistema de integracioacuten continua
El coacutedigo y todos los ficheros de configuracioacuten se pueden encontrar en elrepositorio del proyecto en GitHub16
61 Aplicacioacuten Web
Se busca simular el proceso de adaptacioacuten de una solucioacuten web para su des-pliegue en un sistema distribuido con las herramientas anteriormente descritascon el objetivo de aumentar tanto su escalabilidad como disponibilidad medianteredundancia
Se ha partido de una aplicacioacuten ya existente17 un servicio de almacenamien-to y reproduccioacuten de canciones A grandes rasgos este servicio permite crearusuarios subir canciones con sus respectivas portadas tener playlists propias yescuchar las canciones a traveacutes de un navegador web
La solucioacuten estaacute dividida en 4 partes (figura 17)
Una vista web con la loacutegica
Un almacenamiento conectado en red (NAS por sus siglas en ingleacutes)
Una API REST para gestionar las peticiones al almacenamiento
Base de datos NoSQL basada en MongoDB
La nueva tendencia de los proyectos web es su implementacioacuten en contene-dores Docker ya que facilitan su portabilidad y ofrecen un procedimiento dedespliegue raacutepido sobre todo a la hora de desarrollar y realizar pruebas en en-tornos de produccioacuten simulados Por ello en este caso se va a hacer uso de los
16httpsgithubcomAntonioAlfrzCloud-Orchestrators17httpsgithubcomsonsoleslpCDPSfy
27
motores de orquestacioacuten de contenedores de ambas herramientas Marathon enDCOS y el controlador Docker en el caso de Nomad
Figura 17 Arquitectura aplicacioacuten web
A continuacioacuten vamos detallar el despliegue en ambas herramientas de es-ta solucioacuten y observar tanto queacute dificultades se encuentran como que ventajasofrecen El objetivo final es adaptar el proyecto modificaacutendolo lo menos posiblecon objeto de analizar la capacidad de estas herramientas para desplegar cual-quier aplicacioacuten sin que eso conlleve la modificacioacuten de la arquitectura de eacutestaes decir que no sea dependiente del entorno
611 DCOS
Se ha descrito DCOS como una herramienta que se despliega sobre un con-junto de ordenadores y que permite instalar gestionar el despliegue de sistemasdistribuidos
Microsoft Azure cuenta con una plantilla para desplegar en su servicio cloudun cluster de maacutequinas virtuales con DCOS ya instalado que cuenta con
Maacutequinas maestras (1 3 o 5 a seleccionar por el usuario) configuradascomo un conjunto de disponibilidad esto eso Azure da ciertas garantiacuteasde que al menos una maacutequina estaraacute en funcionamiento
Maacutequinas agentes Por motivos de seguridad se distinguen dos roles
bull Nodos privados solo accesibles desde la red interna y configuradoscomo un conjunto de escala un recurso de Azure para gestionar ydesplegar maacutequinas con configuraciones ideacutenticas para permitir unraacutepido escalado
bull Un equipo conectado accesible desde Internet a travntildees de un balan-ceador de carga puacuteblico y situado en una subred externa
28
Dos balanceadores de carga
bull La interfaz puacuteblica del cluster que se conecta con el cliente puacuteblicobull Acceso a los equipos maestros para el administrador que soacutelo permiteconexioacuten mediante SSH y credenciales
Almacenamiento para todas las maacutequinas
Configuraciones necesarias de red y seguridad
En la figura 18 se observa un diagrama de la infraestructura
Figura 18 Infraestructura en Azure
El primer obstaacuteculo es la persistencia de estado de la aplicacioacuten que seconsigue gracias a una base de datos no relacional basada en MongoDB asiacutecomo el almacenamiento de las canciones Para implementarla tenemos variasposibilidades
Montar un sistema externo de almacenamiento conectado en red en todoslos agentes donde se ejecuten las tareas de esta manera si una tarea pasade un nodo a otro por cualquier motivo puede tener acceso a los mismosficheros (opcioacuten del caso de uso original)
Implementar un sistema de ficheros distribuidos en los agentes
Usar los servicios de almacenamiento de las nubes puacuteblicas
Aprovechar el sistema de voluacutemenes persistentes de Apache Mesos Eacutestepermite reservar recursos de un agente de forma que al arrancar una tarease crea un volumen independiente del ciclo de vida de eacutesta con ello esosrecursos donde se ha almacenado la informacioacuten pueden volver a ofrecerseal mismo entorno de tal manera que otra tarea pueda acceder a ella
DCOS aprovecha este sistema de voluacutemenes persistentes y permite instalarbases de datos distribuidas como ArangoDB o Apache Cassandra sin embargoesto implicariacutea modificar todo el coacutedigo referente al modelo de la base de datos
29
Por motivos de eficiencia y latencia asiacute como de una mayor gobernabilidadde los datos la mejor opcioacuten es usar el recurso de voluacutemenes persistentes queofrece Apache Mesos ya que de esta manera se gestionariacutea la aplicacioacuten completamediante una uacutenica herramienta Sin embargo esto implica que la informacioacutense encuentra exclusivamente en el agente donde se haya ejecutado la tarea y porlo tanto se sigue requiriendo de software externo para distribuir la informacioacutenpara que se accesible para todos los agentes A la hora de realizar este proyectose encontraba en desarrollo Flocker una solucioacuten desarrollada por ClusterHQque permite compartir los voluacutemenes de Docker a traveacutes de un cluster quesi bien es compatible con el planificador de Mesos el proyecto se encontrabatodaviacutea en fases tempranas de desarrollo y los sistemas de almacenamiento quesoporta quedaban fuera del aacutembito de este trabajo
Por todo ello dado que las maacutequinas se han desplegado en la nube puacuteblicade Azure se decidioacute usar su servicio de almacenamiento de objetos para lascanciones y otra maacutequina para desplegar MongoDB y asiacute mantener el modelode datos original de la aplicacioacuten La diferencia del almacenamiento de obje-tos con respecto a nivel de fichero es que el primero no tiene jerarquiacutea paraorganizar los archivos eacutestos se guardan como objetos (con sus metadatos) enun mismo espacio soacutelo diferenciaacutendose por un identificador uacutenico esto implicaentre otras cosas que se puede acceder a un fichero dado uacutenicamente su IDindependientemente de la localizacioacuten fiacutesica de eacuteste facilitando pues la gestioacuteny el desarrollo
El coacutedigo del proyecto se ha modificado en los siguientes apartados
Las direcciones de la base de datos y los balanceadores de carga asiacute comosus puertos estaban originalmente fijos Se han configurado como variablesde entorno para facilitar el descubrimiento del servicio y hacer transpa-rente la aplicacioacuten al entorno de despliegue
La API REST se ha adaptado al almacenamiento en Azure en vez de enlocal
Estas modificaciones no suponen un cambio sustancial pero permiten separala persistencia de las tareas ejecutadas por DCOS lo que facilita en granmedida su ejecucioacuten al ser totalmente sin estado y ademaacutes implican tenerlos datos bajo un mayor control
Para la orquestacioacuten de contenedores se va a usar el entorno Marathondesarrollado tambieacuten por Mesosphere Eacuteste se puede usar a traveacutes de una interfazgraacutefica la interfaz de liacutenea de comandos (en lo que sigue CLI por sus siglas eningleacutes) de DCOS o con su API HTTP
Primero se han publicado la imaacutegenes de los contenedores que encapsulanla interfaz web y la api de la aplicacioacuten en el repositorio puacuteblico DockerHub
Los despliegues en este entorno se describen mediante ficheros JSON en losque se detalla entre otras opciones la imagen del contenedor los puertos a usar
30
los recursos que debe ocupar en un nodo o las instrucciones de monitorizacioacuten
Para el servicio de descubrimiento DCOS ofrece la posibilidad de asignardirecciones IP virtuales (VIP por sus siglas en ingleacutes) a tareas que se compartenen todos los nodos DCOS lleva integrado un balanceador de carga a nivel TCP(el componente denominado Minuteman) que balancea entre las direccionesvirtuales de las tareas y todas las instancias de eacutestas a lo largo del cluster Estoes necesario por dos motivos equilibrar la carga de los equipos con el fin deevitar un punto de uacutenico fallo mediante redundancia y evitar la contienda dedirecciones al ejecutar las tareas en puertos aleatorios
Este balanceador de carga estaacute basado en el trabajo de Michael Mitzenma-cher The Power of Two Choices in Randomized Load Balancing18 A grandesrasgos el algoritmo mantiene una media moacutevil exponencial de latencias paracada destino (backend) ademaacutes de las caiacutedas consecutivas Si un destino noresponde a una negociacioacuten en tres pasos (three way handshake) de forma con-secutiva en un periodo inferior a 5 ms se considera caiacutedo El algoritmo iterasobre los destinos disponibles en base a su histoacuterico de fallos y escoge dos deforma aleatoria de los cuales coge el de mejor meacutetrica
Las direcciones virtuales soacutelo se pueden resolver dentro del cluster porello para implementar la interfaz puacuteblica de la aplicacioacuten esto es el balancea-dor de carga de la interfaz web usaremos un paquete de DCOS denominadomarathon-lb un balanceador basado en HAProxy y adaptado por MesosphereEn este caso equilibra la carga de todas instancias de las tareas ejecutadas porel entorno Marathon por sus etiquetas y permite ademaacutes definir como puntode entrada muacuteltiples hosts virtuales definidos por sus nombres completos dedominio (FQDN por sus siglas en ingleacutes) en nuestro caso la interfaz puacuteblicadel balanceador de Azure para los agentes
Por motivos de seguridad todas las tareas se ejecutan en los agentes privadoses decir los que son exclusivamente accesibles desde la red interna Por su partemarathon-lb se ejecuta en el agente puacuteblico que cuenta con IP puacuteblica y lospuertos 80 (HTTP) y 8080 abiertos de forma que la aplicacioacuten sea accesibledesde Internet Esto es posible debido a que Apache Mesos permite reservarrecursos mediante roles asignados a nodos para un uso especiacutefico De esta formala arquitectura vista desde la aplicacioacuten quedariacutea como en la figura 19
18httpswwweecsharvardedu~michaelmpostscriptstpds2001pdf
31
Figura 19 Arquitectura de la aplicacioacuten web en DCOS
Ejecucioacuten
A la hora de desplegar la aplicacioacuten DCOS puede gestionarse medianteuna interfaz graacutefica o una interfaz de liacutenea de comandos La primera se accedea traveacutes de un navegador web en el puerto 80 (HTTP) y permite instalar losentornos disponibles observar el estado de los nodos y las tareas que se estaacutenejecutando y los ficheros de registros que eacutestas generan
La CLI permite el control desde un nodo o una maacutequina remota (suponiendoque los maestros tienen IP puacuteblica y el puerto 80 abierto) ya que DCOS tieneun sistema de autorizacioacuten que permite tener una interfaz puacuteblica con ciertasgarantiacuteas de seguridad
Por su parte cada entorno de trabajo puede ser controlado por la CLI peroademaacutes cuenta con sus propias interfaces Marathon expone una API HTTPen el puerto 8080 de la direccioacuten puacuteblica de los maestros del cluster asiacute comootra interfaz graacutefica Para desplegar un contenedor se podriacutea usar la CLI
$ dcos marathon app add lt f i l e j songt
O la API HTTP
$ cu r l minusX POST http lt ip_maestro gt8080v2apps minusd ltf i l e jsongt minusH Contentminustype app l i c a t i o n j son
32
612 Nomad
La arquitectura de Nomad es maacutes sencilla ya que solo requiere de un ficheroejecutable en todos los nodos para funcionar Si DCOS es la base de instala-cioacuten de entornos de terceros Nomad integra todas las funcionalidades baacutesicasesto es gestor de recursos planificador y ejecutor en los nodos cliente Estaherramienta cuenta con un menor tiempo de desarrollo y en el momento deescribir este documento cuenta exclusivamente con los siguientes controladoresen comparacioacuten con los entornos de DCOS
Motor Docker es decir funcioacuten de orquestacioacuten de contenedores
Ejecucioacuten de archivos binarios como comandos de Shell
Ejecucioacuten de aplicaciones Java
Virtualizacioacuten de maacutequinas mediante tecnologiacutea QEMU
Todos ellos necesitan que la tecnologiacutea subyacente esteacute instalada en las maacute-quinas clientes (Docker Java QEMU) Actualmente no permite el registro decontroladores por parte de terceros aunque estaacute planificado en un futuro ofreceruna interfaz para su desarrollo
Nomad no cuenta con el servicio de descubrimiento sin embargo puede inte-grarse con la herramienta Consul desarrollada por la misma empresa Por otrolado para el balanceo de carga usaremos un contenedor Docker con HAProxyuna herramienta de coacutedigo abierto que ofrece tanto servicios de proxy como debalanceador y cuyos ficheros de configuracioacuten completaremos con el proyectoConsul Template19
Consul
Consul sigue la misma arquitectura que Nomad es decir un nodo servidorque orquesta un conjunto de maacutequinas clientes y permite a los procesos que seejecutan en los equipos definirlos como servicios ofreciendo diversas caracteriacutes-ticas entorno a estos de los cuales vamos a usar dos
Descubrimiento de servicio Las maacutequinas clientes publican en el cataacutelogode servicios las tareas en ejecucioacuten y Consul les asigna nombres de dominioaccesibles por todos los miembros del cluster a traveacutes de la interfaz DNSincluida en esta herramientaConsul se integra con Nomad de forma que todas las tareas que se ejecu-ten en la segunda son automaacuteticamente publicados como servicios de laprimera de esta manera no hace falta conocer la direccioacuten de la maacutequinacliente donde se esteacute ejecutando el proceso ya que se puede acceder a eacutela traveacutes de su nombre de dominio de forma transparente Por ejemplo si
19[httpsgithubcomhashicorpconsul-template]
33
ejecutamos una tarea con ID web en el puerto 8080 se puede acceder aella en la direccioacuten webserviceconsul8080Para que las direcciones propias de Consul las resuelva su propio DNS y noel que esteacute asignado por defecto en la maacutequina usaremos la herramientadnsmasq20 que permite especificar la direccioacuten de un servidor DNS paraconsultas de direcciones especiacuteficas
Monitorizacioacuten Permite realizar comprobaciones del servicio y seguir su esta-do Aprovecharemos esta funcionalidad tanto para definir el propio procesode Nomad como servicio de Consul como las tareas desplegadas
HAProxy + Consul Template
HAProxy es una solucioacuten versaacutetil de coacutedigo abierto que ofrece solucionesde balanceo de carga y proxy Existen otras herramientas en el mercado comoNGINX o ldirectord sin embargo HAProxy suponiacutea una solucioacuten sencilla deconfigurar para mostrar el caso de uso
El uso de estas herramientas se debe a dos motivos para que no existacontienda con respecto a los puertos de los clientes usados por las tareas eacutestos sevan a asignar de forma dinaacutemica lo que en principio implicariacutea que la aplicacioacutendeberiacutea realizar consultas DNS de tipo SRV (que incluye puertos) a la interfazde Consul y balancear la carga entre tareas por redundancia y capacidad
Como la direccioacuten IP y puerto son variables cada vez que las tareas seactualicen o se reasignen es necesario volver a configurar HAProxy de formamanual Por ello HashiCorp ha desarrollado un programa denominado Con-sul Template que realiza peticiones sucesivas a la interfaz HTTP de Consul delas direcciones fiacutesicas de un servicio y reinicia automaacuteticamente el proceso deHAProxy Asiacute definiendo estas tareas como servicios Consul podremos tantomonitorizarlas como escalar las tareas dinaacutemicamente sin necesidad de cambiarel balanceador A partir del contenedor Docker oficial de HAProxy se ha desa-rrollado otro con la configuracioacuten baacutesica y con Consul Template para desplegarlocomo una tarea en Nomad
Despliegue
Se ha usado el mismo coacutedigo que en el apartado anterior con la persistenciaen el servicio de almacenamiento de Azure Desde la perspectiva del hardwarese implementaraacute la misma infraestructura que en el caso de DCOS (figura 18)estos es definiremos dos tipos de maacutequinas clientes un agente que se conectaraacutecon el balanceador de carga con nombre de dominio puacuteblico y donde se desple-garaacute el balanceador de carga de la vista web y agentes privados no accesiblesdesde fuera del cluster y donde se ejecutaraacuten el resto de tareas en la red inter-na La principal diferencia radica en las tareas que ejecutan HAproxy y ConsulTemplate que sustituye a las direcciones IP virtuales que ofrece DCOS
20httpwwwthekelleysorgukdnsmasqdochtml
34
Figura 20 Despliegue en Azure de Nomad+Consul
Cabe matizar que los balanceadores basados en HAProxy se implementanpor necesidad de la aplicacioacuten para el descubrimiento del servicio a diferenciade los de Azure que se implementan por motivos de seguridad y escalabilidaddel cluster en siacute
Configuracioacuten Nomad
Los ficheros de configuracioacuten de las maacutequinas maacutester y cliente son similaresy comparten la mayoriacutea de las opciones como por ejemplo el nombre del nodoo la interfaz de red donde escucha Nomad las peticiones Sus opciones son engeneral auto-explicativas sin embargo existen dos detalles que matizar
El proceso de Nomad escucha las peticiones tanto de los protocolos deconsenso como del usuario a traveacutes de una interfaz de red que se debeindicar en el fichero de configuracioacuten
En el caso de los clientes se deben indicar las direcciones de los servidoresdel cluster sin embargo se trata de un sistema dinaacutemico en el que losnodos pueden sufrir errores y cambiar de direccioacuten Por ello se ha definidoNomad como un servicio de Consul y asiacute poder definir la direccioacuten de losservidores como un nombre de dominio no por su direccioacuten fiacutesica que elservidor DNS de Consul se encargaraacute de resolver
Por defecto Nomad usa los siguientes puertos
API HTTP 4646 Peticiones HTTP y recepcioacuten de oacuterdenes mediante laliacutenea de comandos
RPC 4647 Protocolo de consenso entre los nodos del cluster
Serf 4648 Protocolo de gossip entre los servidores de los centros de datosgobernados por Nomad
35
Los dos uacuteltimos deben ser interfaces alcanzables por otros nodos sin embargo laAPI HTTP por motivos de seguridad deberiacutea ser local ya que en caso contrariocualquier persona con acceso a ella tiene el control sobre la herramienta Eacutestasolo deberiacutea estar accesible en un servidor o gestionarlo mediante una terminalSSH por ejemplo En este trabajo al ser una prueba de concepto se ha abiertoen todos los nodos
Trabajos de Nomad
Las tareas se detallan en ficheros con formato HashiCorp Configuration Lan-guage un derivado del formato JSON creado por la empresa que le da nombrecompatible con eacuteste y que permite comentarios
En estos ficheros se puede definir
La regioacuten y el centro de datos donde se ejecutaraacute (Nomad permite lagestioacuten de centros de datos geograacuteficamente distribuidos en regiones)
La poliacutetica de actualizacioacuten de la tarea
Grupo de tareas esto es que se ejecutaraacuten en el mismo nodo
El nuacutemero de grupos a ejecutarescalar asiacute como los liacutemite que debencumplir los nodos asignados
La poliacutetica de reinicio ante fallo o error
Tareas El controlador su configuracioacuten los paraacutemetros del servicio aso-ciado a registrar en Consul asiacute como los recursos que consume (puertosmemoria)
En nuestro caso usamos sobre todo el controlador Docker esto eso orques-tacioacuten de contenedores en los nodos clientes y tres de sus opciones
Imagen del contenedor Se han subido todas las imaacutegenes del proyecto a Doc-ker Hub donde por defecto se busca la imagen
Puertos Los puertos a usar por el contenedor que pueden ser estaacuteticos asigna-dos por el usuario o dinaacutemicos siendo Nomad el que se encarga de mapearun puerto libre del nodo cliente al expuesto por el contenedor
Servidores DNS Como usamos la interfaz DNS de Consul como descubri-miento de servicio se debe configurar el contenedor para que use cualquiernodo del cluster como servidor DNS
Configuracioacuten Consul
Al ser desarrolladas por la misma empresa los ficheros de configuracioacuten deConsul y Nomad comparten muchas opciones Consul tambieacuten acepta peticionesa traveacutes de una interfaz de red siendo los puertos usados por defecto
36
RPC 8300 8400 Maneja la peticiones del resto de nodos y usuarios
Serf 8301 8302 Protocolo gossip
HTTP API 8500
HTTPS API Desactivada por defecto
Interfaz DNS 8600
Se debe asignar a los protocolos internos del cluster esto es RPC y Serf unainterfaz alcanzable por los nodos y por el contrarioasignar a los dos uacuteltimos ala interfaz de loopback por motivos de seguridad
Cabe destacar que Consul tambieacuten cuenta con una interfaz graacutefica que per-mite ver el estado de los equipos y los servicios registrados y que se encuentra enel mismo puerto que la API HTTP en la direccioacuten httpIP_EQUIPO8500ui
Ejecucioacuten
Tanto Nomad como Consul requieren de la ejecucioacuten de un fichero en todoslos nodos integrantes del cluster Como prueba de concepto se ha decidido usardos servidores para ambos aunque cabe matizar que es un nuacutemero ineficienteya que la caiacuteda de uno de ellos supondriacutea la peacuterdida del cuoacuterum y por tantodel consenso del cluster
En primer lugar se arrancan los servidores que son los encargados de ejecu-tar el protocolo de consenso y gestionar el cluster y a continuacioacuten los clientesque no tienen praacutecticamente estado y dependen de los servidores
En el caso de Consul se debe indicar el directorio donde se guardan losficheros que describen los servicios asiacute como el archivo que especifica el resto delas opciones
1 Se inicia el primer servidor en uno de los equipos
$ consu l agent minuscon f i gminusd i r e t c consu l d s e r v i c e s minuscon f i gminus f i l e consu l_server j son
2 Los siguientes equipos deben unirse al anterior por lo que antildeadimos elargumento join con la direccioacuten del primer servidor Para el caso de otrosservidores
$ consu l agent minuscon f i gminusd i r e t c consu l d s e r v i c e s minuscon f i gminus f i l e consu l_server j son minus j o i n ltIP_servidor1gt
37
Una vez los servidores han alcanzado el consenso y elegido un liacuteder en losclientes
$ consu l agent minuscon f i gminusd i r e t c consu l d s e r v i c e s minuscon f i gminus f i l e c on su l_c l i en t j son minus j o i n ltIP_cualquierServ idorgt
El proceso para iniciar Nomad es igual y los comandos similares sin embargoya no es necesario indicar una direccioacuten IP fija en los equipos sino el nombre dedominio del servicio de Nomad registrado por Consul En el primer servidor
$ nomad agent minusc on f i g nomad_server j son
Y el resto de equipos (con su fichero de configuracioacuten correspondiente)$ nomad agent minusc on f i g nomad_server j son minus j o i n nomad s e r v i c e consu l
Por uacuteltimo para desplegar la aplicacioacuten web se han escrito tres ficherosque detallan las tareas de la interfaz web API y los balanceadores de cargaMediante la CLI
$ nomad run minusaddress=http lt ip_c lus te r gt4646 lt f i l e hclgt
O mediante la API HTTP de Nomad$ cu r l minusX POST minusd ltf i l e hclgthttp lt ip_c lus te r gt4646 jobltjob_namegt
Ansible
Como se puede comprobar con el aumento del nuacutemero de equipos pasa aser inviable manejar todos los nodos a traveacutes de terminal Ademaacutes como seha comentado con anterioridad Nomad requiere que en los nodos clientes es-teacuten instalados las herramientas que soporten las tareas por ejemplo el motorde Docker Por ello para facilitar tanto el arranque como la instalacioacuten de lasdependencias vamos a usar Ansible una herramienta de coacutedigo abierto desarro-llada en Python que permite gestionar configuraciones aprovisionar recursosdespliegue de aplicaciones de forma automaacutetica
A grandes rasgos esta herramienta funciona mediante ficheros en formatoYAML denominados play-books que describen un conjunto de pasos a ejecutaren una lista de equipos remotos Estos pasos son ejecutados por moacutedulos inde-pendientes a traveacutes de SSH es decir en cualquier ordenador con conexioacuten a los
38
hosts dado su contrasentildea o clave puacuteblica puede arrancar el script y realizariacutealos pasos de forma remota gestionando el cluster desde un solo equipo
Se han desarrollado guiones para lo siguiente
Descarga de los binarios de Nomad y Consul en todos los nodos copiade los ficheros de configuracioacuten baacutesicos y modificarlos de acuerdo a cadanodo (nombre del equipo direccioacuten IP)
Instalacioacuten de las dependencias
Arranque de Nomad y Consul
Ansible extiende su funcionalidad a traveacutes de moacutedulos independientes que per-miten por ejemplo instalar paquetes mediante herramientas de gestioacuten de pa-quetes (APT yum) aprovisionar automaacuteticamente maacutequinas virtuales de Ama-zon EC2
Algunas opciones de los ficheros de configuracioacuten de Nomad y Consul sondependientes del nodo particular por ejemplo la interfaz de red Para estetrabajo se ha realizado un moacutedulo para modificar los ficheros de configuracioacutende forma automaacutetica En el repositorio del proyecto se encuentra una carpetadonde se encuentran todos los ficheros necesarios para desplegar un clustertotalmente funcional solo requiere de una liacutenea de terminal con Ansible
$ ans ib l eminusplaybook minus i hos t s minusk ltssh_passgt minusu ltnode_usergt s i t e yml
39
62 Servicio de integracioacuten continua
Se ha implementado un sistema de integracioacuten continua que permite ejecu-tar tareas de compilacioacuten y pruebas de forma distribuida aumentando asiacute elrendimiento de los equipos En primer lugar se detallaraacute los motivos por los quepuede resultar beneficioso para las empresas una implementacioacuten de este tipo alo que seguiraacute los detalles del despliegue
621 DevOps
Metodologiacutea que defiende la comunicacioacuten y colaboracioacuten entre desarrolla-dores de software y los profesionales de operaciones a lo largo de todo el ciclo devida de una aplicacioacuten Estaacute muy relacionado con el desarrollo aacutegil de softwareesto es un enfoque para los proyectos que defiende el desarrollo iterativo e in-cremental donde los requisitos y soluciones evolucionan con el tiempo seguacuten lanecesidad del proyecto DevOps extiende esta filosofiacutea a todas los componentesde un servicio incluyendo sistemas y operaciones
Se trata de un concepto que cada organizacioacuten o empresa adapta a suspropias necesidades y procesos de negocio en este proyecto nos vamos a centraren la integracioacuten continua una praacutectica fundamental tanto del desarrollo aacutegilcomo de esta filosofiacutea
622 Integracioacuten Continua
Se define como una praacutectica de desarrollo software donde los miembros delequipo ponen en comuacuten su trabajo frecuentemente al menos una vez al diacutea21Cada integracioacuten se verifica con una compilacioacuten automaacutetica que incluye laejecucioacuten de pruebas para detectar errores de integracioacuten tan pronto como seaposible
Desde el punto de vista operativo esto supone automatizar la configuracioacutende equipos o el despliegue de maacutequinas virtuales donde compilar el proyecto yejecutar las pruebas y posteriormente eliminarlas Este flujo de trabajo se vebeneficiado en entornos distribuidos ya que el objetivo del desarrollador es com-probar el resultado de las pruebas raacutepidamente sin preocuparse del despliegueo los propios equipos
Para esta prueba de concepto vamos a usar Jenkins un servidor de integra-cioacuten continua escrito en Java que nos permite definir trabajos que contendraacutenla descripcioacuten tanto del entorno como su ejecucioacuten
Este sigue una estructura maestro-esclavo muy similar al de los gestores declusters usados en este proyecto el maestro contiene toda la loacutegica del servicio
21httpmartinfowlercomarticlescontinuousIntegrationhtml
40
trabajos autenticacioacuten y los esclavos son los encargados de la ejecucioacuten ensiacute Jenkins tiene varias viacuteas para aprovisionar los uacuteltimos
Mediante SSH
Interfaz graacutefica
Desarrollar un script propio
Ejecucioacuten de un fichero java
La ventaja de usar planificadores es que el despliegue de esclavos es dinaacutemicoes decir no tener una maacutequina especiacuteficamente configurada para ello DCOS yNomad se encargaraacuten de configurar estos despliegues en sus maacutequinas y poste-riormente eliminarlos Para ello se ha usado la uacuteltima opcioacuten definiendo tareasque descarguen el fichero java Con todo ello se consigue un entorno de inte-gracioacuten continua eficiente que ademaacutes permite la ejecucioacuten de otros servicios deforma independiente
Jenkins permite la creacioacuten de plugins que extienden sus funcionalidadesTanto Nomad22 como Apache Mesos cuentan con uno que permite su integra-cioacuten
Para esta prueba se va a usar el mismo proyecto que para el caso de usode orquestacioacuten de contenedores la aplicacioacuten web al que se le ha antildeadido untest para comprobar que se conecta correctamente a la base de datos medianteMocha un framework de Nodejs Por otro lado se antildeade el plugin de git ya queel coacutedigo se obtiene de GitHub el repositorio remoto de control de versiones delproyecto
El proceso general de ejecucioacuten seriacutea como sigue
1 Se ejecuta el maestro de Jenkins como tarea Docker partiendo de la imagenoficial
2 Al arrancar un trabajo se manda una tarea a los planificadores que laasignaraacuten a un nodo cliente Esta tarea consiste en la descarga del ficherode configuracioacuten Java y arrancarlo configurando el equipo como un clientede Jenkins temporalmente
3 Jenkins ejecuta el trabajo en el nuevo cliente en este caso iniciar la apli-cacioacuten web iniciar las pruebas y generar un informe
4 Se elimina el cliente
A continuacioacuten se detallan los matices de cada herramienta a la hora de imple-mentar este servicio
22Desarrollado por Ivo Verberk httpwwwivoverberknl
41
623 Jenkins con Nomad
El plugin permite la ejecucioacuten del fichero Java mediante dos controladorescontenedores Docker y Java En este proyecto nos hemos decantado por el pri-mero ya que nos ahorra instalar la maacutequina virtual de java en todos los nodoscliente Por ello se ha construido un contenedor base con Java para la ejecucioacutendel fichero de configuracioacuten y Nodejs para lanzar la aplicacioacuten web
El plugin se configura con la direccioacuten IP del cluster y el contenedor queejecuta el esclavo Jenkins Por su parte el trabajo en Jenkins se define conel repositorio en GitHub donde se aloja el coacutedigo del proyecto a probar y loscomandos a ejecutar en este caso npm update y npm test
624 Jenkins con DCOS
En el caso de DCOS su sistema de paquetes incluye Jenkins por lo queal instalarlo ya se tiene la configuracioacuten de Mesos totalmente funcional Sinembargo para ejecutar la aplicacioacuten en particular y las pruebas se requiere deNodejs en los equipos esclavos por ello debemos antildeadir un plugin de Jenkinsque permite instalar este entorno antes de ejecutar el trabajo Una vez hechoesto soacutelo queda definir la tarea igual que en el caso anterior
Cabe destacar que Mesosphere tambieacuten ha desarrollado un plugin que per-mite hacer despliegues en Marathon de tal manera que permitiriacutea con cadacommit del coacutedigo compilar la imagen del contenedor Docker y desplegarlaautomaacuteticamente aunque en este proyecto no se ha hecho pruebas de esta fun-cionalidad
42
7 Escalando la infraestructura
Uno de los factores clave que se busca a la hora de implementar sistemasdistribuidos es el poder escalar la infraestructura de forma maacutes sencilla estoes detectar que las maacutequinas estaacuten alcanzando el liacutemite de su capacidad yaumentar eacutesta ya sea mejorando sus caracteriacutesticas teacutecnicas o antildeadiendo maacutesnodos al cluster
El coacutedigo y todos los ficheros de configuracioacuten de esta seccioacuten tambieacuten sepueden encontrar en el repositorio del proyecto en GitHub23
71 Disentildeo
Microsoft Azure permite organizar los servicios cloud de forma loacutegica a traveacutesde grupos de recursos y asiacute poder crear o eliminar eacutestos en conjunto parauna aplicacioacuten determinada (por ejemplo una aplicacioacuten web suele requerir demaacutequinas virtuales bases de datos almacenamiento) Ademaacutes dispone dela opcioacuten de crear plantillas en formato JSON que permite al desarrolladordefinir los recursos y su interrelacioacuten para desplegar de forma automaacutetica unainfraestructura TI en la nube
Azure tambieacuten ofrece la posibilidad de monitorizar el estado de las maacutequinasvirtuales a traveacutes de extensiones lo que permite configurar el escalado automaacute-tico al alcanzar cierto liacutemite definido por el operador Eacutesta es a priori la formaen que deberiacutea implementarse hablando en teacuterminos de eficiencia sin embargoesta aproximacioacuten es totalmente dependiente de la plataforma es decir no sepuede extrapolar a otro proveedor o sobre recursos propios sin realizar un nue-vo disentildeo En este proyecto las tareas que son ejecutadas por estos equipos notienen estado ya que todo lo relativo a la persistencia lo hemos asignado fueradel cluster esto permite escalar la plataforma a traveacutes de otra aproximaciones
Las plantillas aceptan una serie de variables a indicar por el usuario entreotras los conjuntos de escala para definir los nodos aceptan una variable quedefine el nuacutemero de maacutequinas que los componen Por otro lado Azure ofreceuna API REST y kits de desarrollo software (SDK por sus siglas en ingleacutes) quepermiten su despliegue de forma programaacutetica Aprovechando estas facilidadesen este proyecto se va a aproximar la escalabilidad con el sucesivo desplieguede la infraestructura de forma automaacutetica se monitorizan los equipos y si sedetecta una maacutequina excesivamente cargada se aumenta el nuacutemero de equiposen la plantilla y se vuelve a desplegar
23httpsgithubcomAntonioAlfrzCloud-Orchestrators
43
En este proyecto se han disentildeado las plantillas para desplegar la arquitec-tura necesaria tanto de Nomad como de DCOS En el caso de la primera eldespliegue es maacutes descriptivo ya que incluye maacutequinas virtuales grupos de se-guridad redes En el caso de DCOS Azure cuenta con un servicio especiacuteficopara clusters gobernados por DCOS denominado Azure Container Service queincluye los componentes necesarios y la instalacioacuten ya realizada
72 Implementacioacuten
En primer lugar para monitorizar el estado de los equipos se va a usar laherramienta Nagios un sistema que permite controlar el estado del hardwarey los servicios de un equipo Se trata de una herramienta muy completa de laque se va a usar su capacidad para ejecutar comandos (plugins) en los nodospara detectar picos de carga generar alertas y ejecutar programas para estoseventos
Se ha desplegado una maacutequina virtual con esta herramienta en ambos siste-mas y se ha instalado una extensioacuten de Nagios (Nagios Remote Plugin Executor)en todos los nodos que permite ejecutar comprobaciones remotamente en con-creto para esta prueba de concepto medir el nivel de saturacioacuten de la unidadcentral de procesamiento (CPU por sus siglas del ingleacutes) Cuando sucede uncambio de estado de una maacutequina esto es cuando este paraacutemetro supera el liacutemi-te definido por el operador Nagios permite actuar en consecuencia ejecutandoprogramas por ello se ha desarrollado un script que ejecuta lo siguiente
Un programa desarrollado en Python con el SDK de Azure que modificalas plantillas y despliega los recursos
Un guioacuten de Ansible para instalar todos los componentes necesarios en lasnuevas maacutequinas y arrancar de nuevo el cluster y las aplicaciones
44
8 Resultados y conclusiones
En este uacuteltimo apartado se da una visioacuten global del proyecto asiacute como a lasconclusiones maacutes importantes a las que se ha llegado y posibles temas futurosde desarrollo
81 Comparacioacuten
Ambas herramientas ofrecen las funcionalidades para gestionar los recursoseficientemente ofreciendo a los desarrolladores una plataforma donde desplegarsus aplicaciones de forma distribuida independientemente de los equipos fiacutesicosy el hardware que las soporten
DCOS es una herramienta que en un comienzo fue privativa pero cuyos res-ponsables la empresa Mesosphere decidieron publicar una versioacuten de coacutedigoEacutesta nos permite gestionar un cluster de una forma sencilla y usable ademaacutes decomplementarlo con otras herramientas como el balanceador de carga integradoo la autenticacioacuten de usuarios ademaacutes estaacute basada en Apache Mesos un pro-yecto de relativa madurez y con el soporte de la Apache Software FoundationDe forma resumida DCOS ofrece muchas posibilidades y servicios a cambiode una arquitectura e instalacioacuten maacutes compleja
Por su parte HashiCorp con menor tiempo de desarrollo ha conseguidouna herramienta muy sencilla de desplegar que ademaacutes cumple con todas lasfuncionalidades baacutesicas ejecutando un simple binario en cada nodo se puededesplegar un gestor de clusters totalmente funcional Sin embargo no cuentacon todas las posibilidades de Mesos (Nomad cuenta con menos controladoresque entornos posibles de Mesos) ni con los antildeadidos de DCOS lo que implicael uso de otras herramientas para complementar el servicio (Consul HAProxy)
De entre las dificultades encontradas al usar estas herramientas y desplegaraplicaciones sobre ellas se puede destacar la depuracioacuten en ocasiones se desco-noce si un error viene de la propia herramienta de la aplicacioacuten desplegada o delequipo fiacutesico si no se cuenta con un sistema de procesamiento de registro unose puede encontrar con muacuteltiples terminales abiertas inspeccionando numerososficheros de registro buscando posibles errores Ademaacutes no dejan de ser solucio-nes que para usar eficientemente se debe conocer parte de su funcionamientoy sintaxis a la hora de describir la tareas lo que supone un esfuerzo antildeadido yaque cada una tiene sus particularidades y liacutemites
45
82 Conclusiones
En una sociedad cada vez maacutes digital las empresas deben adaptarse a unmercado cuya demanda de contenido no deja de crecer Las nuevas arquitecturascomo microservicios asiacute como la gran cantidad de datos generada implica queuna mejor gestioacuten de los recursos y la rapidez para desplegar o escalar solucionesdando valor al cliente lo maacutes raacutepido posible es uno de los objetivos de todas lasempresas de base tecnoloacutegica
Las ventajas que ofrecen los planificadores con aplicaciones distribuidas sonnumerosas sin ir maacutes lejos empresas tan punteras como Google llevan maacutesde 10 antildeos orquestando contenedores24 Por un lado permiten aumentar elrendimiento de los equipos propios y por otro implementar un servicio comoplataforma para despliegues distribuidos sobre cualquier conjunto hardware deesta forma se provee un servicio similar al de la nube puacuteblica pero con laprincipal diferencia de que se elimina la independencia con el proveedor (vendorlock-in) esto es las aplicaciones no tienen limitaciones impuestas por eacuteste talescomo lenguaje de programacioacuten o herramientas y permite despliegues hiacutebridosentre recursos propios y la nube
83 Objetivos conseguidos
Implementacioacuten de los planificadores propuestos en la nube Se ha en-tendido y detallado el funcionamiento de estas herramientas y se hanimplementado en el servicio de infraestructura de Microsoft Azure
Despliegue de aplicaciones y servicios distribuidos Servicios que se usanactualmente en la industria del desarrollo software asiacute como una aplica-cioacuten web con una arquitectura moderna han sido desplegados de formadistribuida en los equipos cumpliendo con la funcionalidad esperada ade-maacutes de consiguiendo una alta disponibilidad
Aproximacioacuten de arquitectura escalable Se ha hecho una aproximacioacutende infraestructura escalable de forma que sea parcialmente extrapolable aotros proveedores
24httpwwwnextplatformcom20160322decade-container-control-google
46
84 Liacuteneas de investigacioacuten
Siguiendo con la materia de este proyecto se presentan posibles liacuteneas deinvestigacioacuten
Analizar el despliegue con estas herramientas de aplicaciones de Big Datay comparar la eficiencia con respecto a soluciones especializadas
Analizar el rendimiento de los algoritmos de planificacioacuten antes pruebasde estreacutes y situaciones de alta contienda
Comparar el uso de estas herramientas con las praacutecticas actuales de laindustria o implementacioacuten en un sistema de produccioacuten real
47
Referencias
[1] LA Barroso y U Houmllzle laquoThe Datacenter as a Computer An Introduc-tion to the Design of Warehouse-Scale Machinesraquo En Morgan amp ClaypoolPublishers ()
[2] Systems Research Group ndash NetOS (University of Cambridge) The evolu-tion of cluster scheduler architectures 2016 url httpswwwclcamacukresearchsrgnetoscamsasblog2016-03-09-scheduler-architectureshtml
[3] A Das I Gupta y A Motivala SWIM Scalable Weakly-consistent Infection-style Process Group Membership Protocol Inf teacutec Dept of ComputerScience Cornell University url https www cs cornell edu ~asdasresearchdsn02-swimpdf
[4] D Dubhashi y A Das Mastering Mesos PACKT Publishing mayo de2016
[5] The Apache Software Foundation Apache Mesos documentation urlhttpsmesosapacheorg
[6] David Greenberg Building Applications on Mesos OrsquoReilly Media 2016[7] Armand Grillet Comparison of Container Schedulers Inf teacutec Technische
Universitaumlt Berlin[8] HashiCorp Consul documentation url httpswwwconsulio[9] HashiCorp Nomad documentation url httpsdcosio[10] Dan C Marinescu Cloud computing theory and practice Morgan Kauf-
mann 2013[11] Mesosphere DCOS documentation url httpswwwnomadproject
io[12] Microsoft Azure documentation url httpsazuremicrosoftcom
es-esdocumentation[13] D Ongaro y J Ousterhout In Search of an Understandable Consensus
Algorithm Inf teacutec Stanford University url httpsraftgithubioraftpdf
[14] Fei Teng laquoRessource allocation and schelduling models for cloud compu-tingraquo Tesis de mtriacutea Ecole Centrale Paris 2011
[15] A Williams y col Automation and Orchestration with Docker and Contai-ners A Comprehensive Overview of the Docker and Container Ecosystem3 The New Stack 2016
48
- Resumen
- Summary
- Iacutendice de figuras
- Introduccioacuten y objetivos
-
- Contexto
- Objetivos
- Estructura del documento
-
- Cloud Computing
- Nuevas cargas de trabajo
- Gestioacuten de recursos Planificadores
-
- Sistemas distribuidos
-
- Clasificacioacuten
-
- Herramientas
-
- DCOS
-
- Apache Mesos
- Ejemplos de uso
-
- Nomad
-
- Protocolo de consenso Raft
- Protocolo gossip SWIM
- Planificacioacuten
-
- Casos de uso y despliegue
-
- Aplicacioacuten Web
-
- DCOS
- Nomad
-
- Servicio de integracioacuten continua
-
- DevOps
- Integracioacuten Continua
- Jenkins con Nomad
- Jenkins con DCOS
-
- Escalando la infraestructura
-
- Disentildeo
- Implementacioacuten
-
- Resultados y conclusiones
-
- Comparacioacuten
- Conclusiones
- Objetivos conseguidos
- Liacuteneas de investigacioacuten
-
Exhibitor Gestiona y automatiza el despliegue de ZooKeper la herra-mienta que provee de configuracioacuten centralizada y registro de nombres
Marathon Equivale al proceso init de los sistemas tipo Unix esto es elprimer proceso en ejecucioacuten tras la carga del kernel y que genera los demaacutesprocesos Se encarga de arrancar y monitorizar las aplicaciones y servicios
Mesos-DNS Servicio de DNS interno que define el dominio mesos pa-ra nodos y tareas en el cluster es decir permite resolver nombres conindependencia de la direccioacuten fiacutesica
Minuteman Balanceador de carga integrado a nivel TCPUDP disponiblepara las propias aplicaciones
Por otra parte se definen como servicios a las diferentes aplicaciones dis-tribuidas que DCOS permite instalar en el cluster y que pueden haber sidodesarrollados por la misma empresa Mesosphere o por terceros por ejemploApache Spark Jenkins o Apache Hadoop En la figura 8 se muestra un diagramade los servicios disponibles incluyendo algunos de las aplicaciones distribuidasque soporta DCOS
Figura 8 Servicios DCOSFuente httpsdcosio
511 Apache Mesos
El nuacutecleo de DCOS estaacute basado en Apache Mesos un proyecto de coacutedigoabierto creado por la Universidad de California Berkeley y desarrollado actual-mente por la fundacioacuten Apache Se trata de un administrador de clusters queabstrae los recursos y los dispone para diferentes aplicaciones y entornos de tra-bajo distribuidos (frameworks) mediante una interfaz comuacuten En el momento deredaccioacuten de este proyecto Apache Mesos soportaba una variedad de entornosque abarcaba desde Big Data (Apache Spark Hadoop) hasta bases de datos(Cassandra Hypertable)
15
Arquitectura
Mesos se basa en la asignacioacuten de dos roles diferentes a los nodos
Maestros (Masters) Se encargan de la gestioacuten y reparticioacuten de los recursospara los diferentes entornos de trabajo mediante ldquoofertas de recursosrdquo deacuerdo a los disponibles y a la poliacutetica de asignacioacuten (planificacioacuten en dosniveles)
Esclavos (Slaves) Ordenadores donde se ejecutaraacuten las aplicaciones y cu-yos recursos son ofertados por los maestros
En el caso de fallo del maestro las tareas pueden seguir ejecutaacutendose perono se podraacute asignar nuevos recursos ni tareas por ello pueden existir varios enel cluster para configuraciones de alta disponibilidad pero soacutelo uno orquesta alos esclavos
Para la eleccioacuten del master liacuteder Mesos usa Apache ZooKeeper un proyectode software desarrollado por la misma fundacioacuten cuyo objetivo es proveer deun servicio de configuracioacuten centralizado y registro de nombres8
Por otra parte los entornos de trabajo son los programas que deciden final-mente queacute recursos se van a usar y se encargan de que los esclavos ejecuten lastareas Eacutestos se ejecutan sobre Mesos y constan de dos componentes
Planificador (Scheduler) Optimiza y decide los recursos a utilizar de losofertados informando a los Masters
Procesador (Executor) Ejecuta las aplicaciones o servicios en los esclavos
El objetivo final es conseguir una interfaz liviana tolerante a fallos paracualquier tipo de entorno de trabajo de tal manera que en los esclavos del clusterpuedan ejecutarse simultaacuteneamente tareas con necesidades y duracioacuten diferentesPara ello se basa en dos conceptos asignacioacuten y aislamiento de recursos
Asignacioacuten de recursos
En el cluster pueden coexistir entornos de trabajo con tareas de larga dura-cioacuten y con gran consumo de recursos con tareas cortas que los ocupan y liberancon rapidez El maestro integra un moacutedulo de asignacioacuten de recursos (allocationmodule) que se encarga del algoritmo de distribucioacuten
En el momento de escribir este proyecto estaban desarrollados dos moacutedulosuno mediante el cual el usuario puede asignar prioridades y otro que implementa
8httpszookeeperapacheorg
16
el algoritmo Dominant Resource Fairness9 a grandes rasgos se determina entodos los esclavos la tarea en ejecucioacuten que necesita maacutes recursos y se calcula laproporcioacuten del recurso de mayor peso con respecto al total por ejemplo si unatarea ocupa 2 GB de memoria con respecto a 10 GB totales que tiene el clusterse le asigna un dominant share del 20 la tarea se asignaraacute al nodo con menordominant share
Aislamiento de recursos
Para conseguir que tareas de diferentes entornos de trabajo y con distin-ta naturaleza se ejecuten simultaacuteneamente en un mismo nodo Mesos usa loscontenedores Linux (descritos en la seccioacuten 3)
Funcionamiento
La figura 9 muestra el esquema de la arquitectura de Apache Mesos conalta disponibilidad (tres maestros) y con dos entornos de trabajo ejecutaacutendo-se Hadoop que permite el almacenamiento y procesamiento de gran cantidadde datos para proyectos de big data y un sistema que implementa la interfazsistema de paso de mensajes MPI
Como se puede observar el sistema ZooKeeper elige a un solo maestro comoliacuteder y eacuteste orquesta el cluster comunicando los esclavos con los planificadoresde los diferentes entornos de trabajo Tambieacuten se puede observar como las tareasde los distintos entornos estaacuten distribuidas entre los tres esclavos disponibles
Figura 9 Arquitectura de Apache MesosFuente httpsmesosapacheorg
El proceso de asignacioacuten se realiza como sigue en primer lugar un usuariosolicita la ejecucioacuten de una tarea mediante la interfaz de cada entorno de traba-jo (interfaz graacutefica API HTTP ) De forma paralela un esclavo informa almaestro de los recursos que tiene libres En consecuencia eacuteste se lo notifica almoacutedulo de asignacioacuten que en funcioacuten de su configuracioacuten decide cuaacutento ofertar
9httpspeopleeecsberkeleyedu~aligpapersdrfpdf
17
y a queacute entorno de trabajo y enviacutea la oferta a los planificadores Eacutestos respondenal maestro con queacute recursos ha decidido usar para cada tarea Finalmente lastareas son enviadas al esclavo seleccionado el cual asigna los recursos indicadosal procesador (executor) quien finalmente las ejecuta
Cabriacutea pensar que esta metodologiacutea puede conducir a situaciones en lasque un entorno podriacutea quedarse con tareas sin ejecutarse a la espera de unaoferta satisfactoria para ello Mesos implementa un sistema de filtros medianteel cual los entornos especifican los requisitos miacutenimos que debe cumplir unaoferta por ejemplo se puede especificar en queacute nodos debe desplegarse la tareaEste sistema estaacute disentildeado asiacute con el objetivo de mantener lo maacutes transparenteposible esta herramientas de forma que acepte entornos de trabajo de distintasnaturalezas
512 Ejemplos de uso
Grandes empresas estaacuten usando Apache Mesos con eficacia de acuerdo a susnecesidades e infraestructuras Caben destacar
Ebay En el modelo de implementacioacuten continua en esta empresa10 cadadesarrollador cuenta con su propia instancia que se ejecuta en una maacutequinavirtual dedicada lo que ha conllevado un uso de los recursos poco eficiente Enuna prueba de concepto consiguieron realizar una herramienta de integracioacutencontinua distribuida basada en un cluster con Apache mesos y con el entornoMarathon y Jenkins
Apple Anuncioacute que el motor de su famosa herramienta de asistencia per-sonal para iPhones Siri estaacute desplegada sobre Apache Mesos11 Para ello handesarrollado su propio entorno para facilitar a los ingenieros a desplegar los ser-vicios que la herramienta necesita para resolver las peticiones de los usuarios
Twitter Desarrolloacute su propio entorno denominado Aurora y actualmentegestionan sus recursos y miden el coste de las tareas que los empleados usancon el objetivo de que sean conscientes del gasto que puede suponer un usoinadecuado de la infraestructura12
10httpwwwebaytechblogcom20140404delivering-ebays-ci-solution-with-apache-mesos-part-i11httpwwwbusinessinsidercomapple-siri-uses-apache-mesos-2015-812httpswwwlinuxcomNEWS4-UNIQUE-WAYS-UBER-TWITTER-PAYPAL-AND-HUBSPOT-USE-APACHE-MESOS
18
52 Nomad
Herramienta de coacutedigo abierto de gestioacuten de clusters creada y desarrolladapor Hashicorp13 que permite el despliegue de aplicaciones y procesos de formadistribuida
Las principales diferencias con Apache Mesos a grandes rasgos son
Arquitectura maacutes ligera Nomad soacutelo requiere de un fichero para funcionarejecutaacutendolo con las correspondientes configuraciones en todos los nodosrealiza las funciones de gestioacuten del cluster eleccioacuten de liacuteder planificacioacutende recursos y ejecucioacuten de las tareas
Centro de datos y regiones muacuteltiples Su arquitectura estaacute orientada afacilitar la gestioacuten de diferentes centros de datos geograacuteficamente distri-buidos
Entorno de ejecucioacuten Las tareas se definen y son interpretadas mediantecontroladores integrados en Nomad que se valen de los recursos y herra-mientas de los nodos clientes para ejecutarlas Esta integracioacuten dificultael desarrollo de controladores por parte de terceros a diferencia de Mesosque delega dicha responsabilidad en los entornos de trabajo externos alproyecto
Usa un planificador de estado compartido con respecto a la planificacioacutenen dos niveles de Mesos
Antes de entrar en maacutes detalle en la arquitectura es importante definir lossiguientes teacuterminos
Controlador (Driver) Software que se encarga de interpretar las definicionesde las tareas y ejecutarlas semejante a los procesadores de los entornosde trabajo de Mesos A la hora de redactar este proyecto Nomad contabacon controladores para contenedores Docker virtualizacioacuten de maacutequinasmediante el emulador QEMU aplicaciones java y archivos binarios
Grupo de trabajo (Task Group) Conjunto de tareas que se ejecutan en elmismo nodo cliente
Trabajo (Job) Conjunto loacutegico de tareas y grupos de trabajo que se despliegana la vez
Asignacioacuten (Allocation) Relacioacuten entre un grupo de trabajo y el cliente don-de se ejecuta
Evaluacioacuten (Evaluation) Proceso mediante el cual Nomad planifica y ges-tiona el registro o actualizaciones de los trabajos
13httpswwwhashicorpcom
19
Nomad sigue una arquitectura maestro-esclavo similar a la de Apache Mesosmuacuteltiples servidores acuerdan entre siacute un liacuteder que gestiona la planificacioacuten detareas en los clientes que soacutelo conocen sus asignaciones y las ejecutan
Todos los servidores participan paralelamente en tareas de planificacioacuten derecursos y asignacioacuten de tareas y ademaacutes entre ellos eligen un liacuteder que seencarga de la coordinacioacuten de la suscripcioacuten de los clientes al cluster y de lagestioacuten de las peticiones
Los clientes estaacuten configurados para comunicarse con el servidor usando lla-madas a procedimiento remoto (RPC por sus siglas en ingleacutes) que permite unordenador ejecutar coacutedigo en otra maacutequina Mediante esta tecnologiacutea los nodosclientes avisan de su estado e informa de sus asignaciones recursos y controla-dores disponibles
Existe la posibilidad de gestionar varios centros de datos agrupados en regio-nes eacutestas son independientes pero permite definir tareas o comprobar el estadode todas ellas desde cualquier punto A continuacioacuten se muestra una figura dela arquitectura a alto nivel de esta configuracioacuten
Figura 10 Arquitectura multi-regioacuten en NomadFuente httpswwwnomadprojectio
La herramienta se sustenta sobre tres protocolos fundamentales un protocolode consenso entre los servidores para compartir informacioacuten sobre su estado yel liacuteder un protocolo Gossip para la gestioacuten entre regiones y el planificador detareas
521 Protocolo de consenso Raft
El objetivo es obtener consistencia en un conjunto de nodos que comparteninformacioacuten es decir si un cliente realiza un cambio que todos los nodos veanla misma informacioacuten a la vez y ademaacutes sea tolerante a fallos Para ello se basaen el algoritmo Raft[13] que se detalla brevemente a continuacioacuten
20
Los nodos participantes en el algoritmo pueden estar en tres estados
Liacuteder (Leader) Todos los cambios que realicen en el cluster pasan por eacutel pri-mero
Seguidor (Follower) Nodo pasivo cuya responsabilidad es responder a laspeticiones del nodo liacuteder
Candidato (Candidate) Maacutequina que no ha encontrado liacuteder y solicita sueleccioacuten
Supongamos que tenemos cinco equipos que acaban de arrancar el protocoloEn la figura 11 se observan los nodos y sus respectivos registros a la derecha
Figura 11 Equipos sin consenso ejecutando el protocolo RAFTFuente httpsgithubcomongardieraftscope
Al comenzar todos los nodos son seguidores esperando recibir comunicacioacutende un nodo que actuacutee como liacuteder Cada nodo tiene un tiempo de espera aleatoriodespueacutes del cual si no es informado por un liacuteder pasa a estado candidato y pideel ldquovotordquo al resto de los participantes El algoritmo divide el tiempo en plazos uncandidato pasa a liacuteder si recibe la mayoriacutea de los votos en un plazo determinadoSe define mayoriacutea o cuoacuterum (quorum) comolceil
N2rceil
+ 1 (1)
donde N representa el nuacutemero de nodos
Para el ejemplo propuesto de 5 equipos se requieren de 3 votos Soacutelo losnodos que se encuentren en estado seguidor pueden votar una uacutenica vez a laprimera solicitud que reciba dentro de un plazo
Supoacutengase que el nodo denotado con S1 ha cumplido su tiempo de espera yrealiza la peticioacuten de voto (figura 12) A partir de este momento se pueden dartres casos
La maacutequina gana la eleccioacuten y pasa a ser liacuteder informando al resto
Otro servidor se establece como liacuteder en el mismo momento
Varios nodos pasan a ser candidatos por lo que ninguno consigue los votos
21
Figura 12 Un equipo pasa a estado candidato (RAFT)
Si un candidato recibe un aviso de un liacuteder en el mismo plazo el primeropasa a ser seguidor y se acaba la eleccioacuten de liacuteder
Por otro lado si un equipo candidato no recibe los votos en el plazo y agotasu tiempo de espera avanza al siguiente plazo y repite el proceso de votacioacutenLa tercera posibilidad puede conllevar a un estado indefinido ya que varioscandidatos pueden agotar su tiempo de espera al mismo tiempo y repartir losvotos Para solventarlo el algoritmo establece tiempos de espera aleatorios paralos candidatos
Siguiendo con el ejemplo propuesto el servidor S1 pasa a ser el liacuteder Cadacierto tiempo eacuteste debe realizar avisos a los nodos seguidores para no agotar sutiempo de espera
En este momento el cluster de servidores estaacute en ldquoconsensordquo y la informacioacutenen todos los nodos estaacute actualizada Un cambio en la informacioacuten inicia unproceso de replicacioacuten el liacuteder registra el cambio lo pasa al resto de nodos yuna vez eacutestos responden el cambio se hace efectivo
Supoacutengase que se realiza un cambio en los datos en la figura 13 en la partederecha se observa el cambio en el registro del servidor S1 que informa a losnodos seguidores En consecuencia los nodos registran el cambio y responden aS1
Figura 13 Cambio en un registro (RAFT)
Una vez el cuoacuterum (en el ejemplo tres equipos) informa al liacuteder de que
22
ha registrado el cambio el liacuteder lo hace efectivo en su sistema y notifica a losnodos que hacen lo mismo En la figura 14 el enviacuteo todaviacutea no ha llegado ala maacutequina S3 y se observa que no ha hecho efectivo el cambio (en el registroaparece punteado)
Figura 14 Aprobacioacuten del resto de equipos (RAFT)
Este protocolo funcionaraacute correctamente mientras exista un nuacutemero de nodosen funcionamiento igual o superior al cuoacuterum en el ejemplo propuesto elcuoacuterum es tres por lo que el sistema puede tolerar la caiacuteda de dos de los equipos
522 Protocolo gossip SWIM
Nomad permite la gestioacuten simultaacutenea de varios centros de datos reparti-dos en regiones geograacuteficamente separadas requiriendo de un protocolo ligeroque mantenga a los miembros actualizados sobre los participantes del conjun-to Para ello usa una ligera variante del protocolo SWIM[3] (Scalable Weakly-consistent Infection-style Process Group Membership Protocol) desarrollada porHashiCorp Estaacute clasificado como un protocolo de tipo gossip que debe su nom-bre a la semejanza con coacutemo se distribuye un rumor en una red social
SWIM se sustenta en dos caracteriacutesticas fundamentales la deteccioacuten de fallosy la distribucioacuten de la informacioacuten relativa a los miembros A continuacioacuten sedetalla el funcionamiento de ambos componentes
Deteccioacuten de fallos
Este componente tiene dos paraacutemetros el periodo de protocolo T y el nuacutemerode subgrupos de deteccioacuten de fallos k en los que se dividen los nodos Paracomprobar la comunicacioacuten entre dos maacutequinas usa la utilidad ping basadaen el protocolo ICMP La deteccioacuten de caiacuteda de un servidor sigue el siguientealgoritmo
Durante el periodo T cada miembro Mi de un subgrupo elige otro al azar Mjdel mismo subgrupo y le enviacutea un mensaje ping para comprobar su estado Enel caso de que se cumpla un tiempo de espera determinado por una estimacioacuten
23
del tiempo de ida y vuelta (RTT por sus siglas en ingleacutes) de la red y no hayarespuesta Mi le vuelve a enviar un mensaje ping indirectamente a traveacutes deun nuacutemero k de miembros escogidos aleatoriamente De no recibir ninguna res-puesta Mi establece que Mj ha sufrido un fallo y lo etiqueta como ldquosospechosordquoinformando al componente de distribucioacuten
Figura 15 Diagrama de tiempo del protocolo SWIMFuente httpswwwcscornelledu
Componente de distribucioacuten
Se encarga de informar de cualquier cambio en los miembros a todo el con-junto Los eventos de nodo caiacutedo y la unioacuten o disociacioacuten de un miembro setransmiten a todos los servidores para que actualicen sus lista Para distribuirla informacioacuten a todos los nodos se podriacutea usar el meacutetodo de multicast perosuele estar deshabilitado Por ello se utiliza una teacutecnica de transmisioacuten denomi-nada Piggybacking mediante la cual se adjunta a los propios mensajes PINGy ACK del algoritmo la informacioacuten a distribuir reduciendo asiacute la congestioacutenen la red
523 Planificacioacuten
Proceso encargado de distribuir las tareas entre los nodos clientes de acuerdoa su estado
El planificador de Nomad estaacute basado en las publicaciones de Google sobresus herramientas de gestioacuten de clusters Borg y Omega14 y entiende los trabajosdescritos por el usuario como un estado deseado es decir su despliegue en unamaacutequina cliente de forma correcta y los clientes como el estado actual esto eslo que se encuentra en ejecucioacuten El registro actualizacioacuten o cancelacioacuten de un
14httpresearchgooglecompubspub43438html
24
trabajo asiacute como el fallo de un nodo cliente implican un cambio de estado atramitar por el sistema lo que se define como evaluacioacuten (evaluation) Esto uacutelti-mo supone comparar el estado actual (clientes) con el estado deseado (conjuntode trabajos registrados) y enviarlos a los planificadores correspondientes que seencargaraacuten de asignar las tareas a los nodos clientes
Figura 16 Procedimiento de asignacioacuten en NomadFuente httpswwwnomadprojectio
En la figura 16 se observa el flujo de trabajo en el que las distintas evalua-ciones se encolan en el evaluation broker que se ejecuta en el servidor liacuteder ygestiona las evaluaciones pendientes asignaacutendoles prioridades
A continuacioacuten los nodos servidores ejecutan los scheduling workers queprocesan las evaluaciones llamando a los distintos planificadores que generanun plan de asignacioacuten esto es un conjunto de relaciones entre las tareas y losnodos clientes donde se ejecutaraacuten Este proceso se divide en dos fases primerose descartan aquellos clientes que no cumplan los requisitos y posteriormentese asigna una calificacioacuten al resto Se selecciona el nodo con mayor puntuacioacuteny se encola el plan en el gestor que se ejecuta en el servidor liacuteder Existen tresplanificadores de acuerdo al tipo de trabajo
Service Incluye aquellos trabajos que estaacuten destinados a ejecutarse en un pe-riacuteodo largo de tiempo Para realizar las asignaciones el planificador evaluacuteala mayor parte de los nodos y usa una versioacuten del algoritmo Best fit in-fluenciada por el trabajo de Google en su herramienta Borg Se trata deun algoritmo de planificacioacuten que sacrifica tiempo a cambio de maximizarel rendimiento de los clientes asignando la tarea a la maacutequina que tengala mayor carga de trabajo con el objetivo de reducir equipos en funciona-
25
miento
Batch Tareas que incluyen listas de comandos en general de menor duracioacuteny que no requieren interaccioacuten con el usuario Se vale del algoritmo deSparrow desarrollado por la universidad de Berkeley15 para limitar losnodos clientes a evaluar
System Trabajos destinados a ejecutarse en todos los nodos incluso los que seunen al cluster posteriormente
Core Mantenimiento interno de Nomad
Una vez se ha realizado el proceso de planificacioacuten el nodo liacuteder lo registra enla cola de planes (plan queue) que se encarga de asignarles prioridad y manejarcondiciones de carrera es decir que no accedan a los recursos de los clientes sincontrol y evitar que eacutestos superen su capacidad
La maacutequina liacuteder del conjunto puede de este modo aceptar una asignacioacuteny ser ejecutada por los clientes o por el contrario rechazaacutersela al planificadorlo que implicariacutea realizar un plan parcial o totalmente nuevo
Finalmente el estado de las evaluaciones se actualizan y los clientes soninformados de las asignaciones ejecutaacutendose las tareas
15httppeopleeecsberkeleyedu~keopublicationssosp13-final17pdf
26
6 Casos de uso y despliegue
Con el objetivo de mostrar las posibles utilidades que este tipo de sistemaspueden tener en las infraestructuras TI actuales se han desplegado las dos he-rramientas en la nube Microsoft Azure usando su servicio cloud de instancias demaacutequinas virtuales Linux para simular un conjunto de ordenadores conectadosentre siacute por una red LAN Sobre ellas se ha implementado dos casos de usouna aplicacioacuten web con una arquitectura con cierta orientacioacuten a microserviciosy un sistema de integracioacuten continua
El coacutedigo y todos los ficheros de configuracioacuten se pueden encontrar en elrepositorio del proyecto en GitHub16
61 Aplicacioacuten Web
Se busca simular el proceso de adaptacioacuten de una solucioacuten web para su des-pliegue en un sistema distribuido con las herramientas anteriormente descritascon el objetivo de aumentar tanto su escalabilidad como disponibilidad medianteredundancia
Se ha partido de una aplicacioacuten ya existente17 un servicio de almacenamien-to y reproduccioacuten de canciones A grandes rasgos este servicio permite crearusuarios subir canciones con sus respectivas portadas tener playlists propias yescuchar las canciones a traveacutes de un navegador web
La solucioacuten estaacute dividida en 4 partes (figura 17)
Una vista web con la loacutegica
Un almacenamiento conectado en red (NAS por sus siglas en ingleacutes)
Una API REST para gestionar las peticiones al almacenamiento
Base de datos NoSQL basada en MongoDB
La nueva tendencia de los proyectos web es su implementacioacuten en contene-dores Docker ya que facilitan su portabilidad y ofrecen un procedimiento dedespliegue raacutepido sobre todo a la hora de desarrollar y realizar pruebas en en-tornos de produccioacuten simulados Por ello en este caso se va a hacer uso de los
16httpsgithubcomAntonioAlfrzCloud-Orchestrators17httpsgithubcomsonsoleslpCDPSfy
27
motores de orquestacioacuten de contenedores de ambas herramientas Marathon enDCOS y el controlador Docker en el caso de Nomad
Figura 17 Arquitectura aplicacioacuten web
A continuacioacuten vamos detallar el despliegue en ambas herramientas de es-ta solucioacuten y observar tanto queacute dificultades se encuentran como que ventajasofrecen El objetivo final es adaptar el proyecto modificaacutendolo lo menos posiblecon objeto de analizar la capacidad de estas herramientas para desplegar cual-quier aplicacioacuten sin que eso conlleve la modificacioacuten de la arquitectura de eacutestaes decir que no sea dependiente del entorno
611 DCOS
Se ha descrito DCOS como una herramienta que se despliega sobre un con-junto de ordenadores y que permite instalar gestionar el despliegue de sistemasdistribuidos
Microsoft Azure cuenta con una plantilla para desplegar en su servicio cloudun cluster de maacutequinas virtuales con DCOS ya instalado que cuenta con
Maacutequinas maestras (1 3 o 5 a seleccionar por el usuario) configuradascomo un conjunto de disponibilidad esto eso Azure da ciertas garantiacuteasde que al menos una maacutequina estaraacute en funcionamiento
Maacutequinas agentes Por motivos de seguridad se distinguen dos roles
bull Nodos privados solo accesibles desde la red interna y configuradoscomo un conjunto de escala un recurso de Azure para gestionar ydesplegar maacutequinas con configuraciones ideacutenticas para permitir unraacutepido escalado
bull Un equipo conectado accesible desde Internet a travntildees de un balan-ceador de carga puacuteblico y situado en una subred externa
28
Dos balanceadores de carga
bull La interfaz puacuteblica del cluster que se conecta con el cliente puacuteblicobull Acceso a los equipos maestros para el administrador que soacutelo permiteconexioacuten mediante SSH y credenciales
Almacenamiento para todas las maacutequinas
Configuraciones necesarias de red y seguridad
En la figura 18 se observa un diagrama de la infraestructura
Figura 18 Infraestructura en Azure
El primer obstaacuteculo es la persistencia de estado de la aplicacioacuten que seconsigue gracias a una base de datos no relacional basada en MongoDB asiacutecomo el almacenamiento de las canciones Para implementarla tenemos variasposibilidades
Montar un sistema externo de almacenamiento conectado en red en todoslos agentes donde se ejecuten las tareas de esta manera si una tarea pasade un nodo a otro por cualquier motivo puede tener acceso a los mismosficheros (opcioacuten del caso de uso original)
Implementar un sistema de ficheros distribuidos en los agentes
Usar los servicios de almacenamiento de las nubes puacuteblicas
Aprovechar el sistema de voluacutemenes persistentes de Apache Mesos Eacutestepermite reservar recursos de un agente de forma que al arrancar una tarease crea un volumen independiente del ciclo de vida de eacutesta con ello esosrecursos donde se ha almacenado la informacioacuten pueden volver a ofrecerseal mismo entorno de tal manera que otra tarea pueda acceder a ella
DCOS aprovecha este sistema de voluacutemenes persistentes y permite instalarbases de datos distribuidas como ArangoDB o Apache Cassandra sin embargoesto implicariacutea modificar todo el coacutedigo referente al modelo de la base de datos
29
Por motivos de eficiencia y latencia asiacute como de una mayor gobernabilidadde los datos la mejor opcioacuten es usar el recurso de voluacutemenes persistentes queofrece Apache Mesos ya que de esta manera se gestionariacutea la aplicacioacuten completamediante una uacutenica herramienta Sin embargo esto implica que la informacioacutense encuentra exclusivamente en el agente donde se haya ejecutado la tarea y porlo tanto se sigue requiriendo de software externo para distribuir la informacioacutenpara que se accesible para todos los agentes A la hora de realizar este proyectose encontraba en desarrollo Flocker una solucioacuten desarrollada por ClusterHQque permite compartir los voluacutemenes de Docker a traveacutes de un cluster quesi bien es compatible con el planificador de Mesos el proyecto se encontrabatodaviacutea en fases tempranas de desarrollo y los sistemas de almacenamiento quesoporta quedaban fuera del aacutembito de este trabajo
Por todo ello dado que las maacutequinas se han desplegado en la nube puacuteblicade Azure se decidioacute usar su servicio de almacenamiento de objetos para lascanciones y otra maacutequina para desplegar MongoDB y asiacute mantener el modelode datos original de la aplicacioacuten La diferencia del almacenamiento de obje-tos con respecto a nivel de fichero es que el primero no tiene jerarquiacutea paraorganizar los archivos eacutestos se guardan como objetos (con sus metadatos) enun mismo espacio soacutelo diferenciaacutendose por un identificador uacutenico esto implicaentre otras cosas que se puede acceder a un fichero dado uacutenicamente su IDindependientemente de la localizacioacuten fiacutesica de eacuteste facilitando pues la gestioacuteny el desarrollo
El coacutedigo del proyecto se ha modificado en los siguientes apartados
Las direcciones de la base de datos y los balanceadores de carga asiacute comosus puertos estaban originalmente fijos Se han configurado como variablesde entorno para facilitar el descubrimiento del servicio y hacer transpa-rente la aplicacioacuten al entorno de despliegue
La API REST se ha adaptado al almacenamiento en Azure en vez de enlocal
Estas modificaciones no suponen un cambio sustancial pero permiten separala persistencia de las tareas ejecutadas por DCOS lo que facilita en granmedida su ejecucioacuten al ser totalmente sin estado y ademaacutes implican tenerlos datos bajo un mayor control
Para la orquestacioacuten de contenedores se va a usar el entorno Marathondesarrollado tambieacuten por Mesosphere Eacuteste se puede usar a traveacutes de una interfazgraacutefica la interfaz de liacutenea de comandos (en lo que sigue CLI por sus siglas eningleacutes) de DCOS o con su API HTTP
Primero se han publicado la imaacutegenes de los contenedores que encapsulanla interfaz web y la api de la aplicacioacuten en el repositorio puacuteblico DockerHub
Los despliegues en este entorno se describen mediante ficheros JSON en losque se detalla entre otras opciones la imagen del contenedor los puertos a usar
30
los recursos que debe ocupar en un nodo o las instrucciones de monitorizacioacuten
Para el servicio de descubrimiento DCOS ofrece la posibilidad de asignardirecciones IP virtuales (VIP por sus siglas en ingleacutes) a tareas que se compartenen todos los nodos DCOS lleva integrado un balanceador de carga a nivel TCP(el componente denominado Minuteman) que balancea entre las direccionesvirtuales de las tareas y todas las instancias de eacutestas a lo largo del cluster Estoes necesario por dos motivos equilibrar la carga de los equipos con el fin deevitar un punto de uacutenico fallo mediante redundancia y evitar la contienda dedirecciones al ejecutar las tareas en puertos aleatorios
Este balanceador de carga estaacute basado en el trabajo de Michael Mitzenma-cher The Power of Two Choices in Randomized Load Balancing18 A grandesrasgos el algoritmo mantiene una media moacutevil exponencial de latencias paracada destino (backend) ademaacutes de las caiacutedas consecutivas Si un destino noresponde a una negociacioacuten en tres pasos (three way handshake) de forma con-secutiva en un periodo inferior a 5 ms se considera caiacutedo El algoritmo iterasobre los destinos disponibles en base a su histoacuterico de fallos y escoge dos deforma aleatoria de los cuales coge el de mejor meacutetrica
Las direcciones virtuales soacutelo se pueden resolver dentro del cluster porello para implementar la interfaz puacuteblica de la aplicacioacuten esto es el balancea-dor de carga de la interfaz web usaremos un paquete de DCOS denominadomarathon-lb un balanceador basado en HAProxy y adaptado por MesosphereEn este caso equilibra la carga de todas instancias de las tareas ejecutadas porel entorno Marathon por sus etiquetas y permite ademaacutes definir como puntode entrada muacuteltiples hosts virtuales definidos por sus nombres completos dedominio (FQDN por sus siglas en ingleacutes) en nuestro caso la interfaz puacuteblicadel balanceador de Azure para los agentes
Por motivos de seguridad todas las tareas se ejecutan en los agentes privadoses decir los que son exclusivamente accesibles desde la red interna Por su partemarathon-lb se ejecuta en el agente puacuteblico que cuenta con IP puacuteblica y lospuertos 80 (HTTP) y 8080 abiertos de forma que la aplicacioacuten sea accesibledesde Internet Esto es posible debido a que Apache Mesos permite reservarrecursos mediante roles asignados a nodos para un uso especiacutefico De esta formala arquitectura vista desde la aplicacioacuten quedariacutea como en la figura 19
18httpswwweecsharvardedu~michaelmpostscriptstpds2001pdf
31
Figura 19 Arquitectura de la aplicacioacuten web en DCOS
Ejecucioacuten
A la hora de desplegar la aplicacioacuten DCOS puede gestionarse medianteuna interfaz graacutefica o una interfaz de liacutenea de comandos La primera se accedea traveacutes de un navegador web en el puerto 80 (HTTP) y permite instalar losentornos disponibles observar el estado de los nodos y las tareas que se estaacutenejecutando y los ficheros de registros que eacutestas generan
La CLI permite el control desde un nodo o una maacutequina remota (suponiendoque los maestros tienen IP puacuteblica y el puerto 80 abierto) ya que DCOS tieneun sistema de autorizacioacuten que permite tener una interfaz puacuteblica con ciertasgarantiacuteas de seguridad
Por su parte cada entorno de trabajo puede ser controlado por la CLI peroademaacutes cuenta con sus propias interfaces Marathon expone una API HTTPen el puerto 8080 de la direccioacuten puacuteblica de los maestros del cluster asiacute comootra interfaz graacutefica Para desplegar un contenedor se podriacutea usar la CLI
$ dcos marathon app add lt f i l e j songt
O la API HTTP
$ cu r l minusX POST http lt ip_maestro gt8080v2apps minusd ltf i l e jsongt minusH Contentminustype app l i c a t i o n j son
32
612 Nomad
La arquitectura de Nomad es maacutes sencilla ya que solo requiere de un ficheroejecutable en todos los nodos para funcionar Si DCOS es la base de instala-cioacuten de entornos de terceros Nomad integra todas las funcionalidades baacutesicasesto es gestor de recursos planificador y ejecutor en los nodos cliente Estaherramienta cuenta con un menor tiempo de desarrollo y en el momento deescribir este documento cuenta exclusivamente con los siguientes controladoresen comparacioacuten con los entornos de DCOS
Motor Docker es decir funcioacuten de orquestacioacuten de contenedores
Ejecucioacuten de archivos binarios como comandos de Shell
Ejecucioacuten de aplicaciones Java
Virtualizacioacuten de maacutequinas mediante tecnologiacutea QEMU
Todos ellos necesitan que la tecnologiacutea subyacente esteacute instalada en las maacute-quinas clientes (Docker Java QEMU) Actualmente no permite el registro decontroladores por parte de terceros aunque estaacute planificado en un futuro ofreceruna interfaz para su desarrollo
Nomad no cuenta con el servicio de descubrimiento sin embargo puede inte-grarse con la herramienta Consul desarrollada por la misma empresa Por otrolado para el balanceo de carga usaremos un contenedor Docker con HAProxyuna herramienta de coacutedigo abierto que ofrece tanto servicios de proxy como debalanceador y cuyos ficheros de configuracioacuten completaremos con el proyectoConsul Template19
Consul
Consul sigue la misma arquitectura que Nomad es decir un nodo servidorque orquesta un conjunto de maacutequinas clientes y permite a los procesos que seejecutan en los equipos definirlos como servicios ofreciendo diversas caracteriacutes-ticas entorno a estos de los cuales vamos a usar dos
Descubrimiento de servicio Las maacutequinas clientes publican en el cataacutelogode servicios las tareas en ejecucioacuten y Consul les asigna nombres de dominioaccesibles por todos los miembros del cluster a traveacutes de la interfaz DNSincluida en esta herramientaConsul se integra con Nomad de forma que todas las tareas que se ejecu-ten en la segunda son automaacuteticamente publicados como servicios de laprimera de esta manera no hace falta conocer la direccioacuten de la maacutequinacliente donde se esteacute ejecutando el proceso ya que se puede acceder a eacutela traveacutes de su nombre de dominio de forma transparente Por ejemplo si
19[httpsgithubcomhashicorpconsul-template]
33
ejecutamos una tarea con ID web en el puerto 8080 se puede acceder aella en la direccioacuten webserviceconsul8080Para que las direcciones propias de Consul las resuelva su propio DNS y noel que esteacute asignado por defecto en la maacutequina usaremos la herramientadnsmasq20 que permite especificar la direccioacuten de un servidor DNS paraconsultas de direcciones especiacuteficas
Monitorizacioacuten Permite realizar comprobaciones del servicio y seguir su esta-do Aprovecharemos esta funcionalidad tanto para definir el propio procesode Nomad como servicio de Consul como las tareas desplegadas
HAProxy + Consul Template
HAProxy es una solucioacuten versaacutetil de coacutedigo abierto que ofrece solucionesde balanceo de carga y proxy Existen otras herramientas en el mercado comoNGINX o ldirectord sin embargo HAProxy suponiacutea una solucioacuten sencilla deconfigurar para mostrar el caso de uso
El uso de estas herramientas se debe a dos motivos para que no existacontienda con respecto a los puertos de los clientes usados por las tareas eacutestos sevan a asignar de forma dinaacutemica lo que en principio implicariacutea que la aplicacioacutendeberiacutea realizar consultas DNS de tipo SRV (que incluye puertos) a la interfazde Consul y balancear la carga entre tareas por redundancia y capacidad
Como la direccioacuten IP y puerto son variables cada vez que las tareas seactualicen o se reasignen es necesario volver a configurar HAProxy de formamanual Por ello HashiCorp ha desarrollado un programa denominado Con-sul Template que realiza peticiones sucesivas a la interfaz HTTP de Consul delas direcciones fiacutesicas de un servicio y reinicia automaacuteticamente el proceso deHAProxy Asiacute definiendo estas tareas como servicios Consul podremos tantomonitorizarlas como escalar las tareas dinaacutemicamente sin necesidad de cambiarel balanceador A partir del contenedor Docker oficial de HAProxy se ha desa-rrollado otro con la configuracioacuten baacutesica y con Consul Template para desplegarlocomo una tarea en Nomad
Despliegue
Se ha usado el mismo coacutedigo que en el apartado anterior con la persistenciaen el servicio de almacenamiento de Azure Desde la perspectiva del hardwarese implementaraacute la misma infraestructura que en el caso de DCOS (figura 18)estos es definiremos dos tipos de maacutequinas clientes un agente que se conectaraacutecon el balanceador de carga con nombre de dominio puacuteblico y donde se desple-garaacute el balanceador de carga de la vista web y agentes privados no accesiblesdesde fuera del cluster y donde se ejecutaraacuten el resto de tareas en la red inter-na La principal diferencia radica en las tareas que ejecutan HAproxy y ConsulTemplate que sustituye a las direcciones IP virtuales que ofrece DCOS
20httpwwwthekelleysorgukdnsmasqdochtml
34
Figura 20 Despliegue en Azure de Nomad+Consul
Cabe matizar que los balanceadores basados en HAProxy se implementanpor necesidad de la aplicacioacuten para el descubrimiento del servicio a diferenciade los de Azure que se implementan por motivos de seguridad y escalabilidaddel cluster en siacute
Configuracioacuten Nomad
Los ficheros de configuracioacuten de las maacutequinas maacutester y cliente son similaresy comparten la mayoriacutea de las opciones como por ejemplo el nombre del nodoo la interfaz de red donde escucha Nomad las peticiones Sus opciones son engeneral auto-explicativas sin embargo existen dos detalles que matizar
El proceso de Nomad escucha las peticiones tanto de los protocolos deconsenso como del usuario a traveacutes de una interfaz de red que se debeindicar en el fichero de configuracioacuten
En el caso de los clientes se deben indicar las direcciones de los servidoresdel cluster sin embargo se trata de un sistema dinaacutemico en el que losnodos pueden sufrir errores y cambiar de direccioacuten Por ello se ha definidoNomad como un servicio de Consul y asiacute poder definir la direccioacuten de losservidores como un nombre de dominio no por su direccioacuten fiacutesica que elservidor DNS de Consul se encargaraacute de resolver
Por defecto Nomad usa los siguientes puertos
API HTTP 4646 Peticiones HTTP y recepcioacuten de oacuterdenes mediante laliacutenea de comandos
RPC 4647 Protocolo de consenso entre los nodos del cluster
Serf 4648 Protocolo de gossip entre los servidores de los centros de datosgobernados por Nomad
35
Los dos uacuteltimos deben ser interfaces alcanzables por otros nodos sin embargo laAPI HTTP por motivos de seguridad deberiacutea ser local ya que en caso contrariocualquier persona con acceso a ella tiene el control sobre la herramienta Eacutestasolo deberiacutea estar accesible en un servidor o gestionarlo mediante una terminalSSH por ejemplo En este trabajo al ser una prueba de concepto se ha abiertoen todos los nodos
Trabajos de Nomad
Las tareas se detallan en ficheros con formato HashiCorp Configuration Lan-guage un derivado del formato JSON creado por la empresa que le da nombrecompatible con eacuteste y que permite comentarios
En estos ficheros se puede definir
La regioacuten y el centro de datos donde se ejecutaraacute (Nomad permite lagestioacuten de centros de datos geograacuteficamente distribuidos en regiones)
La poliacutetica de actualizacioacuten de la tarea
Grupo de tareas esto es que se ejecutaraacuten en el mismo nodo
El nuacutemero de grupos a ejecutarescalar asiacute como los liacutemite que debencumplir los nodos asignados
La poliacutetica de reinicio ante fallo o error
Tareas El controlador su configuracioacuten los paraacutemetros del servicio aso-ciado a registrar en Consul asiacute como los recursos que consume (puertosmemoria)
En nuestro caso usamos sobre todo el controlador Docker esto eso orques-tacioacuten de contenedores en los nodos clientes y tres de sus opciones
Imagen del contenedor Se han subido todas las imaacutegenes del proyecto a Doc-ker Hub donde por defecto se busca la imagen
Puertos Los puertos a usar por el contenedor que pueden ser estaacuteticos asigna-dos por el usuario o dinaacutemicos siendo Nomad el que se encarga de mapearun puerto libre del nodo cliente al expuesto por el contenedor
Servidores DNS Como usamos la interfaz DNS de Consul como descubri-miento de servicio se debe configurar el contenedor para que use cualquiernodo del cluster como servidor DNS
Configuracioacuten Consul
Al ser desarrolladas por la misma empresa los ficheros de configuracioacuten deConsul y Nomad comparten muchas opciones Consul tambieacuten acepta peticionesa traveacutes de una interfaz de red siendo los puertos usados por defecto
36
RPC 8300 8400 Maneja la peticiones del resto de nodos y usuarios
Serf 8301 8302 Protocolo gossip
HTTP API 8500
HTTPS API Desactivada por defecto
Interfaz DNS 8600
Se debe asignar a los protocolos internos del cluster esto es RPC y Serf unainterfaz alcanzable por los nodos y por el contrarioasignar a los dos uacuteltimos ala interfaz de loopback por motivos de seguridad
Cabe destacar que Consul tambieacuten cuenta con una interfaz graacutefica que per-mite ver el estado de los equipos y los servicios registrados y que se encuentra enel mismo puerto que la API HTTP en la direccioacuten httpIP_EQUIPO8500ui
Ejecucioacuten
Tanto Nomad como Consul requieren de la ejecucioacuten de un fichero en todoslos nodos integrantes del cluster Como prueba de concepto se ha decidido usardos servidores para ambos aunque cabe matizar que es un nuacutemero ineficienteya que la caiacuteda de uno de ellos supondriacutea la peacuterdida del cuoacuterum y por tantodel consenso del cluster
En primer lugar se arrancan los servidores que son los encargados de ejecu-tar el protocolo de consenso y gestionar el cluster y a continuacioacuten los clientesque no tienen praacutecticamente estado y dependen de los servidores
En el caso de Consul se debe indicar el directorio donde se guardan losficheros que describen los servicios asiacute como el archivo que especifica el resto delas opciones
1 Se inicia el primer servidor en uno de los equipos
$ consu l agent minuscon f i gminusd i r e t c consu l d s e r v i c e s minuscon f i gminus f i l e consu l_server j son
2 Los siguientes equipos deben unirse al anterior por lo que antildeadimos elargumento join con la direccioacuten del primer servidor Para el caso de otrosservidores
$ consu l agent minuscon f i gminusd i r e t c consu l d s e r v i c e s minuscon f i gminus f i l e consu l_server j son minus j o i n ltIP_servidor1gt
37
Una vez los servidores han alcanzado el consenso y elegido un liacuteder en losclientes
$ consu l agent minuscon f i gminusd i r e t c consu l d s e r v i c e s minuscon f i gminus f i l e c on su l_c l i en t j son minus j o i n ltIP_cualquierServ idorgt
El proceso para iniciar Nomad es igual y los comandos similares sin embargoya no es necesario indicar una direccioacuten IP fija en los equipos sino el nombre dedominio del servicio de Nomad registrado por Consul En el primer servidor
$ nomad agent minusc on f i g nomad_server j son
Y el resto de equipos (con su fichero de configuracioacuten correspondiente)$ nomad agent minusc on f i g nomad_server j son minus j o i n nomad s e r v i c e consu l
Por uacuteltimo para desplegar la aplicacioacuten web se han escrito tres ficherosque detallan las tareas de la interfaz web API y los balanceadores de cargaMediante la CLI
$ nomad run minusaddress=http lt ip_c lus te r gt4646 lt f i l e hclgt
O mediante la API HTTP de Nomad$ cu r l minusX POST minusd ltf i l e hclgthttp lt ip_c lus te r gt4646 jobltjob_namegt
Ansible
Como se puede comprobar con el aumento del nuacutemero de equipos pasa aser inviable manejar todos los nodos a traveacutes de terminal Ademaacutes como seha comentado con anterioridad Nomad requiere que en los nodos clientes es-teacuten instalados las herramientas que soporten las tareas por ejemplo el motorde Docker Por ello para facilitar tanto el arranque como la instalacioacuten de lasdependencias vamos a usar Ansible una herramienta de coacutedigo abierto desarro-llada en Python que permite gestionar configuraciones aprovisionar recursosdespliegue de aplicaciones de forma automaacutetica
A grandes rasgos esta herramienta funciona mediante ficheros en formatoYAML denominados play-books que describen un conjunto de pasos a ejecutaren una lista de equipos remotos Estos pasos son ejecutados por moacutedulos inde-pendientes a traveacutes de SSH es decir en cualquier ordenador con conexioacuten a los
38
hosts dado su contrasentildea o clave puacuteblica puede arrancar el script y realizariacutealos pasos de forma remota gestionando el cluster desde un solo equipo
Se han desarrollado guiones para lo siguiente
Descarga de los binarios de Nomad y Consul en todos los nodos copiade los ficheros de configuracioacuten baacutesicos y modificarlos de acuerdo a cadanodo (nombre del equipo direccioacuten IP)
Instalacioacuten de las dependencias
Arranque de Nomad y Consul
Ansible extiende su funcionalidad a traveacutes de moacutedulos independientes que per-miten por ejemplo instalar paquetes mediante herramientas de gestioacuten de pa-quetes (APT yum) aprovisionar automaacuteticamente maacutequinas virtuales de Ama-zon EC2
Algunas opciones de los ficheros de configuracioacuten de Nomad y Consul sondependientes del nodo particular por ejemplo la interfaz de red Para estetrabajo se ha realizado un moacutedulo para modificar los ficheros de configuracioacutende forma automaacutetica En el repositorio del proyecto se encuentra una carpetadonde se encuentran todos los ficheros necesarios para desplegar un clustertotalmente funcional solo requiere de una liacutenea de terminal con Ansible
$ ans ib l eminusplaybook minus i hos t s minusk ltssh_passgt minusu ltnode_usergt s i t e yml
39
62 Servicio de integracioacuten continua
Se ha implementado un sistema de integracioacuten continua que permite ejecu-tar tareas de compilacioacuten y pruebas de forma distribuida aumentando asiacute elrendimiento de los equipos En primer lugar se detallaraacute los motivos por los quepuede resultar beneficioso para las empresas una implementacioacuten de este tipo alo que seguiraacute los detalles del despliegue
621 DevOps
Metodologiacutea que defiende la comunicacioacuten y colaboracioacuten entre desarrolla-dores de software y los profesionales de operaciones a lo largo de todo el ciclo devida de una aplicacioacuten Estaacute muy relacionado con el desarrollo aacutegil de softwareesto es un enfoque para los proyectos que defiende el desarrollo iterativo e in-cremental donde los requisitos y soluciones evolucionan con el tiempo seguacuten lanecesidad del proyecto DevOps extiende esta filosofiacutea a todas los componentesde un servicio incluyendo sistemas y operaciones
Se trata de un concepto que cada organizacioacuten o empresa adapta a suspropias necesidades y procesos de negocio en este proyecto nos vamos a centraren la integracioacuten continua una praacutectica fundamental tanto del desarrollo aacutegilcomo de esta filosofiacutea
622 Integracioacuten Continua
Se define como una praacutectica de desarrollo software donde los miembros delequipo ponen en comuacuten su trabajo frecuentemente al menos una vez al diacutea21Cada integracioacuten se verifica con una compilacioacuten automaacutetica que incluye laejecucioacuten de pruebas para detectar errores de integracioacuten tan pronto como seaposible
Desde el punto de vista operativo esto supone automatizar la configuracioacutende equipos o el despliegue de maacutequinas virtuales donde compilar el proyecto yejecutar las pruebas y posteriormente eliminarlas Este flujo de trabajo se vebeneficiado en entornos distribuidos ya que el objetivo del desarrollador es com-probar el resultado de las pruebas raacutepidamente sin preocuparse del despliegueo los propios equipos
Para esta prueba de concepto vamos a usar Jenkins un servidor de integra-cioacuten continua escrito en Java que nos permite definir trabajos que contendraacutenla descripcioacuten tanto del entorno como su ejecucioacuten
Este sigue una estructura maestro-esclavo muy similar al de los gestores declusters usados en este proyecto el maestro contiene toda la loacutegica del servicio
21httpmartinfowlercomarticlescontinuousIntegrationhtml
40
trabajos autenticacioacuten y los esclavos son los encargados de la ejecucioacuten ensiacute Jenkins tiene varias viacuteas para aprovisionar los uacuteltimos
Mediante SSH
Interfaz graacutefica
Desarrollar un script propio
Ejecucioacuten de un fichero java
La ventaja de usar planificadores es que el despliegue de esclavos es dinaacutemicoes decir no tener una maacutequina especiacuteficamente configurada para ello DCOS yNomad se encargaraacuten de configurar estos despliegues en sus maacutequinas y poste-riormente eliminarlos Para ello se ha usado la uacuteltima opcioacuten definiendo tareasque descarguen el fichero java Con todo ello se consigue un entorno de inte-gracioacuten continua eficiente que ademaacutes permite la ejecucioacuten de otros servicios deforma independiente
Jenkins permite la creacioacuten de plugins que extienden sus funcionalidadesTanto Nomad22 como Apache Mesos cuentan con uno que permite su integra-cioacuten
Para esta prueba se va a usar el mismo proyecto que para el caso de usode orquestacioacuten de contenedores la aplicacioacuten web al que se le ha antildeadido untest para comprobar que se conecta correctamente a la base de datos medianteMocha un framework de Nodejs Por otro lado se antildeade el plugin de git ya queel coacutedigo se obtiene de GitHub el repositorio remoto de control de versiones delproyecto
El proceso general de ejecucioacuten seriacutea como sigue
1 Se ejecuta el maestro de Jenkins como tarea Docker partiendo de la imagenoficial
2 Al arrancar un trabajo se manda una tarea a los planificadores que laasignaraacuten a un nodo cliente Esta tarea consiste en la descarga del ficherode configuracioacuten Java y arrancarlo configurando el equipo como un clientede Jenkins temporalmente
3 Jenkins ejecuta el trabajo en el nuevo cliente en este caso iniciar la apli-cacioacuten web iniciar las pruebas y generar un informe
4 Se elimina el cliente
A continuacioacuten se detallan los matices de cada herramienta a la hora de imple-mentar este servicio
22Desarrollado por Ivo Verberk httpwwwivoverberknl
41
623 Jenkins con Nomad
El plugin permite la ejecucioacuten del fichero Java mediante dos controladorescontenedores Docker y Java En este proyecto nos hemos decantado por el pri-mero ya que nos ahorra instalar la maacutequina virtual de java en todos los nodoscliente Por ello se ha construido un contenedor base con Java para la ejecucioacutendel fichero de configuracioacuten y Nodejs para lanzar la aplicacioacuten web
El plugin se configura con la direccioacuten IP del cluster y el contenedor queejecuta el esclavo Jenkins Por su parte el trabajo en Jenkins se define conel repositorio en GitHub donde se aloja el coacutedigo del proyecto a probar y loscomandos a ejecutar en este caso npm update y npm test
624 Jenkins con DCOS
En el caso de DCOS su sistema de paquetes incluye Jenkins por lo queal instalarlo ya se tiene la configuracioacuten de Mesos totalmente funcional Sinembargo para ejecutar la aplicacioacuten en particular y las pruebas se requiere deNodejs en los equipos esclavos por ello debemos antildeadir un plugin de Jenkinsque permite instalar este entorno antes de ejecutar el trabajo Una vez hechoesto soacutelo queda definir la tarea igual que en el caso anterior
Cabe destacar que Mesosphere tambieacuten ha desarrollado un plugin que per-mite hacer despliegues en Marathon de tal manera que permitiriacutea con cadacommit del coacutedigo compilar la imagen del contenedor Docker y desplegarlaautomaacuteticamente aunque en este proyecto no se ha hecho pruebas de esta fun-cionalidad
42
7 Escalando la infraestructura
Uno de los factores clave que se busca a la hora de implementar sistemasdistribuidos es el poder escalar la infraestructura de forma maacutes sencilla estoes detectar que las maacutequinas estaacuten alcanzando el liacutemite de su capacidad yaumentar eacutesta ya sea mejorando sus caracteriacutesticas teacutecnicas o antildeadiendo maacutesnodos al cluster
El coacutedigo y todos los ficheros de configuracioacuten de esta seccioacuten tambieacuten sepueden encontrar en el repositorio del proyecto en GitHub23
71 Disentildeo
Microsoft Azure permite organizar los servicios cloud de forma loacutegica a traveacutesde grupos de recursos y asiacute poder crear o eliminar eacutestos en conjunto parauna aplicacioacuten determinada (por ejemplo una aplicacioacuten web suele requerir demaacutequinas virtuales bases de datos almacenamiento) Ademaacutes dispone dela opcioacuten de crear plantillas en formato JSON que permite al desarrolladordefinir los recursos y su interrelacioacuten para desplegar de forma automaacutetica unainfraestructura TI en la nube
Azure tambieacuten ofrece la posibilidad de monitorizar el estado de las maacutequinasvirtuales a traveacutes de extensiones lo que permite configurar el escalado automaacute-tico al alcanzar cierto liacutemite definido por el operador Eacutesta es a priori la formaen que deberiacutea implementarse hablando en teacuterminos de eficiencia sin embargoesta aproximacioacuten es totalmente dependiente de la plataforma es decir no sepuede extrapolar a otro proveedor o sobre recursos propios sin realizar un nue-vo disentildeo En este proyecto las tareas que son ejecutadas por estos equipos notienen estado ya que todo lo relativo a la persistencia lo hemos asignado fueradel cluster esto permite escalar la plataforma a traveacutes de otra aproximaciones
Las plantillas aceptan una serie de variables a indicar por el usuario entreotras los conjuntos de escala para definir los nodos aceptan una variable quedefine el nuacutemero de maacutequinas que los componen Por otro lado Azure ofreceuna API REST y kits de desarrollo software (SDK por sus siglas en ingleacutes) quepermiten su despliegue de forma programaacutetica Aprovechando estas facilidadesen este proyecto se va a aproximar la escalabilidad con el sucesivo desplieguede la infraestructura de forma automaacutetica se monitorizan los equipos y si sedetecta una maacutequina excesivamente cargada se aumenta el nuacutemero de equiposen la plantilla y se vuelve a desplegar
23httpsgithubcomAntonioAlfrzCloud-Orchestrators
43
En este proyecto se han disentildeado las plantillas para desplegar la arquitec-tura necesaria tanto de Nomad como de DCOS En el caso de la primera eldespliegue es maacutes descriptivo ya que incluye maacutequinas virtuales grupos de se-guridad redes En el caso de DCOS Azure cuenta con un servicio especiacuteficopara clusters gobernados por DCOS denominado Azure Container Service queincluye los componentes necesarios y la instalacioacuten ya realizada
72 Implementacioacuten
En primer lugar para monitorizar el estado de los equipos se va a usar laherramienta Nagios un sistema que permite controlar el estado del hardwarey los servicios de un equipo Se trata de una herramienta muy completa de laque se va a usar su capacidad para ejecutar comandos (plugins) en los nodospara detectar picos de carga generar alertas y ejecutar programas para estoseventos
Se ha desplegado una maacutequina virtual con esta herramienta en ambos siste-mas y se ha instalado una extensioacuten de Nagios (Nagios Remote Plugin Executor)en todos los nodos que permite ejecutar comprobaciones remotamente en con-creto para esta prueba de concepto medir el nivel de saturacioacuten de la unidadcentral de procesamiento (CPU por sus siglas del ingleacutes) Cuando sucede uncambio de estado de una maacutequina esto es cuando este paraacutemetro supera el liacutemi-te definido por el operador Nagios permite actuar en consecuencia ejecutandoprogramas por ello se ha desarrollado un script que ejecuta lo siguiente
Un programa desarrollado en Python con el SDK de Azure que modificalas plantillas y despliega los recursos
Un guioacuten de Ansible para instalar todos los componentes necesarios en lasnuevas maacutequinas y arrancar de nuevo el cluster y las aplicaciones
44
8 Resultados y conclusiones
En este uacuteltimo apartado se da una visioacuten global del proyecto asiacute como a lasconclusiones maacutes importantes a las que se ha llegado y posibles temas futurosde desarrollo
81 Comparacioacuten
Ambas herramientas ofrecen las funcionalidades para gestionar los recursoseficientemente ofreciendo a los desarrolladores una plataforma donde desplegarsus aplicaciones de forma distribuida independientemente de los equipos fiacutesicosy el hardware que las soporten
DCOS es una herramienta que en un comienzo fue privativa pero cuyos res-ponsables la empresa Mesosphere decidieron publicar una versioacuten de coacutedigoEacutesta nos permite gestionar un cluster de una forma sencilla y usable ademaacutes decomplementarlo con otras herramientas como el balanceador de carga integradoo la autenticacioacuten de usuarios ademaacutes estaacute basada en Apache Mesos un pro-yecto de relativa madurez y con el soporte de la Apache Software FoundationDe forma resumida DCOS ofrece muchas posibilidades y servicios a cambiode una arquitectura e instalacioacuten maacutes compleja
Por su parte HashiCorp con menor tiempo de desarrollo ha conseguidouna herramienta muy sencilla de desplegar que ademaacutes cumple con todas lasfuncionalidades baacutesicas ejecutando un simple binario en cada nodo se puededesplegar un gestor de clusters totalmente funcional Sin embargo no cuentacon todas las posibilidades de Mesos (Nomad cuenta con menos controladoresque entornos posibles de Mesos) ni con los antildeadidos de DCOS lo que implicael uso de otras herramientas para complementar el servicio (Consul HAProxy)
De entre las dificultades encontradas al usar estas herramientas y desplegaraplicaciones sobre ellas se puede destacar la depuracioacuten en ocasiones se desco-noce si un error viene de la propia herramienta de la aplicacioacuten desplegada o delequipo fiacutesico si no se cuenta con un sistema de procesamiento de registro unose puede encontrar con muacuteltiples terminales abiertas inspeccionando numerososficheros de registro buscando posibles errores Ademaacutes no dejan de ser solucio-nes que para usar eficientemente se debe conocer parte de su funcionamientoy sintaxis a la hora de describir la tareas lo que supone un esfuerzo antildeadido yaque cada una tiene sus particularidades y liacutemites
45
82 Conclusiones
En una sociedad cada vez maacutes digital las empresas deben adaptarse a unmercado cuya demanda de contenido no deja de crecer Las nuevas arquitecturascomo microservicios asiacute como la gran cantidad de datos generada implica queuna mejor gestioacuten de los recursos y la rapidez para desplegar o escalar solucionesdando valor al cliente lo maacutes raacutepido posible es uno de los objetivos de todas lasempresas de base tecnoloacutegica
Las ventajas que ofrecen los planificadores con aplicaciones distribuidas sonnumerosas sin ir maacutes lejos empresas tan punteras como Google llevan maacutesde 10 antildeos orquestando contenedores24 Por un lado permiten aumentar elrendimiento de los equipos propios y por otro implementar un servicio comoplataforma para despliegues distribuidos sobre cualquier conjunto hardware deesta forma se provee un servicio similar al de la nube puacuteblica pero con laprincipal diferencia de que se elimina la independencia con el proveedor (vendorlock-in) esto es las aplicaciones no tienen limitaciones impuestas por eacuteste talescomo lenguaje de programacioacuten o herramientas y permite despliegues hiacutebridosentre recursos propios y la nube
83 Objetivos conseguidos
Implementacioacuten de los planificadores propuestos en la nube Se ha en-tendido y detallado el funcionamiento de estas herramientas y se hanimplementado en el servicio de infraestructura de Microsoft Azure
Despliegue de aplicaciones y servicios distribuidos Servicios que se usanactualmente en la industria del desarrollo software asiacute como una aplica-cioacuten web con una arquitectura moderna han sido desplegados de formadistribuida en los equipos cumpliendo con la funcionalidad esperada ade-maacutes de consiguiendo una alta disponibilidad
Aproximacioacuten de arquitectura escalable Se ha hecho una aproximacioacutende infraestructura escalable de forma que sea parcialmente extrapolable aotros proveedores
24httpwwwnextplatformcom20160322decade-container-control-google
46
84 Liacuteneas de investigacioacuten
Siguiendo con la materia de este proyecto se presentan posibles liacuteneas deinvestigacioacuten
Analizar el despliegue con estas herramientas de aplicaciones de Big Datay comparar la eficiencia con respecto a soluciones especializadas
Analizar el rendimiento de los algoritmos de planificacioacuten antes pruebasde estreacutes y situaciones de alta contienda
Comparar el uso de estas herramientas con las praacutecticas actuales de laindustria o implementacioacuten en un sistema de produccioacuten real
47
Referencias
[1] LA Barroso y U Houmllzle laquoThe Datacenter as a Computer An Introduc-tion to the Design of Warehouse-Scale Machinesraquo En Morgan amp ClaypoolPublishers ()
[2] Systems Research Group ndash NetOS (University of Cambridge) The evolu-tion of cluster scheduler architectures 2016 url httpswwwclcamacukresearchsrgnetoscamsasblog2016-03-09-scheduler-architectureshtml
[3] A Das I Gupta y A Motivala SWIM Scalable Weakly-consistent Infection-style Process Group Membership Protocol Inf teacutec Dept of ComputerScience Cornell University url https www cs cornell edu ~asdasresearchdsn02-swimpdf
[4] D Dubhashi y A Das Mastering Mesos PACKT Publishing mayo de2016
[5] The Apache Software Foundation Apache Mesos documentation urlhttpsmesosapacheorg
[6] David Greenberg Building Applications on Mesos OrsquoReilly Media 2016[7] Armand Grillet Comparison of Container Schedulers Inf teacutec Technische
Universitaumlt Berlin[8] HashiCorp Consul documentation url httpswwwconsulio[9] HashiCorp Nomad documentation url httpsdcosio[10] Dan C Marinescu Cloud computing theory and practice Morgan Kauf-
mann 2013[11] Mesosphere DCOS documentation url httpswwwnomadproject
io[12] Microsoft Azure documentation url httpsazuremicrosoftcom
es-esdocumentation[13] D Ongaro y J Ousterhout In Search of an Understandable Consensus
Algorithm Inf teacutec Stanford University url httpsraftgithubioraftpdf
[14] Fei Teng laquoRessource allocation and schelduling models for cloud compu-tingraquo Tesis de mtriacutea Ecole Centrale Paris 2011
[15] A Williams y col Automation and Orchestration with Docker and Contai-ners A Comprehensive Overview of the Docker and Container Ecosystem3 The New Stack 2016
48
- Resumen
- Summary
- Iacutendice de figuras
- Introduccioacuten y objetivos
-
- Contexto
- Objetivos
- Estructura del documento
-
- Cloud Computing
- Nuevas cargas de trabajo
- Gestioacuten de recursos Planificadores
-
- Sistemas distribuidos
-
- Clasificacioacuten
-
- Herramientas
-
- DCOS
-
- Apache Mesos
- Ejemplos de uso
-
- Nomad
-
- Protocolo de consenso Raft
- Protocolo gossip SWIM
- Planificacioacuten
-
- Casos de uso y despliegue
-
- Aplicacioacuten Web
-
- DCOS
- Nomad
-
- Servicio de integracioacuten continua
-
- DevOps
- Integracioacuten Continua
- Jenkins con Nomad
- Jenkins con DCOS
-
- Escalando la infraestructura
-
- Disentildeo
- Implementacioacuten
-
- Resultados y conclusiones
-
- Comparacioacuten
- Conclusiones
- Objetivos conseguidos
- Liacuteneas de investigacioacuten
-
Arquitectura
Mesos se basa en la asignacioacuten de dos roles diferentes a los nodos
Maestros (Masters) Se encargan de la gestioacuten y reparticioacuten de los recursospara los diferentes entornos de trabajo mediante ldquoofertas de recursosrdquo deacuerdo a los disponibles y a la poliacutetica de asignacioacuten (planificacioacuten en dosniveles)
Esclavos (Slaves) Ordenadores donde se ejecutaraacuten las aplicaciones y cu-yos recursos son ofertados por los maestros
En el caso de fallo del maestro las tareas pueden seguir ejecutaacutendose perono se podraacute asignar nuevos recursos ni tareas por ello pueden existir varios enel cluster para configuraciones de alta disponibilidad pero soacutelo uno orquesta alos esclavos
Para la eleccioacuten del master liacuteder Mesos usa Apache ZooKeeper un proyectode software desarrollado por la misma fundacioacuten cuyo objetivo es proveer deun servicio de configuracioacuten centralizado y registro de nombres8
Por otra parte los entornos de trabajo son los programas que deciden final-mente queacute recursos se van a usar y se encargan de que los esclavos ejecuten lastareas Eacutestos se ejecutan sobre Mesos y constan de dos componentes
Planificador (Scheduler) Optimiza y decide los recursos a utilizar de losofertados informando a los Masters
Procesador (Executor) Ejecuta las aplicaciones o servicios en los esclavos
El objetivo final es conseguir una interfaz liviana tolerante a fallos paracualquier tipo de entorno de trabajo de tal manera que en los esclavos del clusterpuedan ejecutarse simultaacuteneamente tareas con necesidades y duracioacuten diferentesPara ello se basa en dos conceptos asignacioacuten y aislamiento de recursos
Asignacioacuten de recursos
En el cluster pueden coexistir entornos de trabajo con tareas de larga dura-cioacuten y con gran consumo de recursos con tareas cortas que los ocupan y liberancon rapidez El maestro integra un moacutedulo de asignacioacuten de recursos (allocationmodule) que se encarga del algoritmo de distribucioacuten
En el momento de escribir este proyecto estaban desarrollados dos moacutedulosuno mediante el cual el usuario puede asignar prioridades y otro que implementa
8httpszookeeperapacheorg
16
el algoritmo Dominant Resource Fairness9 a grandes rasgos se determina entodos los esclavos la tarea en ejecucioacuten que necesita maacutes recursos y se calcula laproporcioacuten del recurso de mayor peso con respecto al total por ejemplo si unatarea ocupa 2 GB de memoria con respecto a 10 GB totales que tiene el clusterse le asigna un dominant share del 20 la tarea se asignaraacute al nodo con menordominant share
Aislamiento de recursos
Para conseguir que tareas de diferentes entornos de trabajo y con distin-ta naturaleza se ejecuten simultaacuteneamente en un mismo nodo Mesos usa loscontenedores Linux (descritos en la seccioacuten 3)
Funcionamiento
La figura 9 muestra el esquema de la arquitectura de Apache Mesos conalta disponibilidad (tres maestros) y con dos entornos de trabajo ejecutaacutendo-se Hadoop que permite el almacenamiento y procesamiento de gran cantidadde datos para proyectos de big data y un sistema que implementa la interfazsistema de paso de mensajes MPI
Como se puede observar el sistema ZooKeeper elige a un solo maestro comoliacuteder y eacuteste orquesta el cluster comunicando los esclavos con los planificadoresde los diferentes entornos de trabajo Tambieacuten se puede observar como las tareasde los distintos entornos estaacuten distribuidas entre los tres esclavos disponibles
Figura 9 Arquitectura de Apache MesosFuente httpsmesosapacheorg
El proceso de asignacioacuten se realiza como sigue en primer lugar un usuariosolicita la ejecucioacuten de una tarea mediante la interfaz de cada entorno de traba-jo (interfaz graacutefica API HTTP ) De forma paralela un esclavo informa almaestro de los recursos que tiene libres En consecuencia eacuteste se lo notifica almoacutedulo de asignacioacuten que en funcioacuten de su configuracioacuten decide cuaacutento ofertar
9httpspeopleeecsberkeleyedu~aligpapersdrfpdf
17
y a queacute entorno de trabajo y enviacutea la oferta a los planificadores Eacutestos respondenal maestro con queacute recursos ha decidido usar para cada tarea Finalmente lastareas son enviadas al esclavo seleccionado el cual asigna los recursos indicadosal procesador (executor) quien finalmente las ejecuta
Cabriacutea pensar que esta metodologiacutea puede conducir a situaciones en lasque un entorno podriacutea quedarse con tareas sin ejecutarse a la espera de unaoferta satisfactoria para ello Mesos implementa un sistema de filtros medianteel cual los entornos especifican los requisitos miacutenimos que debe cumplir unaoferta por ejemplo se puede especificar en queacute nodos debe desplegarse la tareaEste sistema estaacute disentildeado asiacute con el objetivo de mantener lo maacutes transparenteposible esta herramientas de forma que acepte entornos de trabajo de distintasnaturalezas
512 Ejemplos de uso
Grandes empresas estaacuten usando Apache Mesos con eficacia de acuerdo a susnecesidades e infraestructuras Caben destacar
Ebay En el modelo de implementacioacuten continua en esta empresa10 cadadesarrollador cuenta con su propia instancia que se ejecuta en una maacutequinavirtual dedicada lo que ha conllevado un uso de los recursos poco eficiente Enuna prueba de concepto consiguieron realizar una herramienta de integracioacutencontinua distribuida basada en un cluster con Apache mesos y con el entornoMarathon y Jenkins
Apple Anuncioacute que el motor de su famosa herramienta de asistencia per-sonal para iPhones Siri estaacute desplegada sobre Apache Mesos11 Para ello handesarrollado su propio entorno para facilitar a los ingenieros a desplegar los ser-vicios que la herramienta necesita para resolver las peticiones de los usuarios
Twitter Desarrolloacute su propio entorno denominado Aurora y actualmentegestionan sus recursos y miden el coste de las tareas que los empleados usancon el objetivo de que sean conscientes del gasto que puede suponer un usoinadecuado de la infraestructura12
10httpwwwebaytechblogcom20140404delivering-ebays-ci-solution-with-apache-mesos-part-i11httpwwwbusinessinsidercomapple-siri-uses-apache-mesos-2015-812httpswwwlinuxcomNEWS4-UNIQUE-WAYS-UBER-TWITTER-PAYPAL-AND-HUBSPOT-USE-APACHE-MESOS
18
52 Nomad
Herramienta de coacutedigo abierto de gestioacuten de clusters creada y desarrolladapor Hashicorp13 que permite el despliegue de aplicaciones y procesos de formadistribuida
Las principales diferencias con Apache Mesos a grandes rasgos son
Arquitectura maacutes ligera Nomad soacutelo requiere de un fichero para funcionarejecutaacutendolo con las correspondientes configuraciones en todos los nodosrealiza las funciones de gestioacuten del cluster eleccioacuten de liacuteder planificacioacutende recursos y ejecucioacuten de las tareas
Centro de datos y regiones muacuteltiples Su arquitectura estaacute orientada afacilitar la gestioacuten de diferentes centros de datos geograacuteficamente distri-buidos
Entorno de ejecucioacuten Las tareas se definen y son interpretadas mediantecontroladores integrados en Nomad que se valen de los recursos y herra-mientas de los nodos clientes para ejecutarlas Esta integracioacuten dificultael desarrollo de controladores por parte de terceros a diferencia de Mesosque delega dicha responsabilidad en los entornos de trabajo externos alproyecto
Usa un planificador de estado compartido con respecto a la planificacioacutenen dos niveles de Mesos
Antes de entrar en maacutes detalle en la arquitectura es importante definir lossiguientes teacuterminos
Controlador (Driver) Software que se encarga de interpretar las definicionesde las tareas y ejecutarlas semejante a los procesadores de los entornosde trabajo de Mesos A la hora de redactar este proyecto Nomad contabacon controladores para contenedores Docker virtualizacioacuten de maacutequinasmediante el emulador QEMU aplicaciones java y archivos binarios
Grupo de trabajo (Task Group) Conjunto de tareas que se ejecutan en elmismo nodo cliente
Trabajo (Job) Conjunto loacutegico de tareas y grupos de trabajo que se despliegana la vez
Asignacioacuten (Allocation) Relacioacuten entre un grupo de trabajo y el cliente don-de se ejecuta
Evaluacioacuten (Evaluation) Proceso mediante el cual Nomad planifica y ges-tiona el registro o actualizaciones de los trabajos
13httpswwwhashicorpcom
19
Nomad sigue una arquitectura maestro-esclavo similar a la de Apache Mesosmuacuteltiples servidores acuerdan entre siacute un liacuteder que gestiona la planificacioacuten detareas en los clientes que soacutelo conocen sus asignaciones y las ejecutan
Todos los servidores participan paralelamente en tareas de planificacioacuten derecursos y asignacioacuten de tareas y ademaacutes entre ellos eligen un liacuteder que seencarga de la coordinacioacuten de la suscripcioacuten de los clientes al cluster y de lagestioacuten de las peticiones
Los clientes estaacuten configurados para comunicarse con el servidor usando lla-madas a procedimiento remoto (RPC por sus siglas en ingleacutes) que permite unordenador ejecutar coacutedigo en otra maacutequina Mediante esta tecnologiacutea los nodosclientes avisan de su estado e informa de sus asignaciones recursos y controla-dores disponibles
Existe la posibilidad de gestionar varios centros de datos agrupados en regio-nes eacutestas son independientes pero permite definir tareas o comprobar el estadode todas ellas desde cualquier punto A continuacioacuten se muestra una figura dela arquitectura a alto nivel de esta configuracioacuten
Figura 10 Arquitectura multi-regioacuten en NomadFuente httpswwwnomadprojectio
La herramienta se sustenta sobre tres protocolos fundamentales un protocolode consenso entre los servidores para compartir informacioacuten sobre su estado yel liacuteder un protocolo Gossip para la gestioacuten entre regiones y el planificador detareas
521 Protocolo de consenso Raft
El objetivo es obtener consistencia en un conjunto de nodos que comparteninformacioacuten es decir si un cliente realiza un cambio que todos los nodos veanla misma informacioacuten a la vez y ademaacutes sea tolerante a fallos Para ello se basaen el algoritmo Raft[13] que se detalla brevemente a continuacioacuten
20
Los nodos participantes en el algoritmo pueden estar en tres estados
Liacuteder (Leader) Todos los cambios que realicen en el cluster pasan por eacutel pri-mero
Seguidor (Follower) Nodo pasivo cuya responsabilidad es responder a laspeticiones del nodo liacuteder
Candidato (Candidate) Maacutequina que no ha encontrado liacuteder y solicita sueleccioacuten
Supongamos que tenemos cinco equipos que acaban de arrancar el protocoloEn la figura 11 se observan los nodos y sus respectivos registros a la derecha
Figura 11 Equipos sin consenso ejecutando el protocolo RAFTFuente httpsgithubcomongardieraftscope
Al comenzar todos los nodos son seguidores esperando recibir comunicacioacutende un nodo que actuacutee como liacuteder Cada nodo tiene un tiempo de espera aleatoriodespueacutes del cual si no es informado por un liacuteder pasa a estado candidato y pideel ldquovotordquo al resto de los participantes El algoritmo divide el tiempo en plazos uncandidato pasa a liacuteder si recibe la mayoriacutea de los votos en un plazo determinadoSe define mayoriacutea o cuoacuterum (quorum) comolceil
N2rceil
+ 1 (1)
donde N representa el nuacutemero de nodos
Para el ejemplo propuesto de 5 equipos se requieren de 3 votos Soacutelo losnodos que se encuentren en estado seguidor pueden votar una uacutenica vez a laprimera solicitud que reciba dentro de un plazo
Supoacutengase que el nodo denotado con S1 ha cumplido su tiempo de espera yrealiza la peticioacuten de voto (figura 12) A partir de este momento se pueden dartres casos
La maacutequina gana la eleccioacuten y pasa a ser liacuteder informando al resto
Otro servidor se establece como liacuteder en el mismo momento
Varios nodos pasan a ser candidatos por lo que ninguno consigue los votos
21
Figura 12 Un equipo pasa a estado candidato (RAFT)
Si un candidato recibe un aviso de un liacuteder en el mismo plazo el primeropasa a ser seguidor y se acaba la eleccioacuten de liacuteder
Por otro lado si un equipo candidato no recibe los votos en el plazo y agotasu tiempo de espera avanza al siguiente plazo y repite el proceso de votacioacutenLa tercera posibilidad puede conllevar a un estado indefinido ya que varioscandidatos pueden agotar su tiempo de espera al mismo tiempo y repartir losvotos Para solventarlo el algoritmo establece tiempos de espera aleatorios paralos candidatos
Siguiendo con el ejemplo propuesto el servidor S1 pasa a ser el liacuteder Cadacierto tiempo eacuteste debe realizar avisos a los nodos seguidores para no agotar sutiempo de espera
En este momento el cluster de servidores estaacute en ldquoconsensordquo y la informacioacutenen todos los nodos estaacute actualizada Un cambio en la informacioacuten inicia unproceso de replicacioacuten el liacuteder registra el cambio lo pasa al resto de nodos yuna vez eacutestos responden el cambio se hace efectivo
Supoacutengase que se realiza un cambio en los datos en la figura 13 en la partederecha se observa el cambio en el registro del servidor S1 que informa a losnodos seguidores En consecuencia los nodos registran el cambio y responden aS1
Figura 13 Cambio en un registro (RAFT)
Una vez el cuoacuterum (en el ejemplo tres equipos) informa al liacuteder de que
22
ha registrado el cambio el liacuteder lo hace efectivo en su sistema y notifica a losnodos que hacen lo mismo En la figura 14 el enviacuteo todaviacutea no ha llegado ala maacutequina S3 y se observa que no ha hecho efectivo el cambio (en el registroaparece punteado)
Figura 14 Aprobacioacuten del resto de equipos (RAFT)
Este protocolo funcionaraacute correctamente mientras exista un nuacutemero de nodosen funcionamiento igual o superior al cuoacuterum en el ejemplo propuesto elcuoacuterum es tres por lo que el sistema puede tolerar la caiacuteda de dos de los equipos
522 Protocolo gossip SWIM
Nomad permite la gestioacuten simultaacutenea de varios centros de datos reparti-dos en regiones geograacuteficamente separadas requiriendo de un protocolo ligeroque mantenga a los miembros actualizados sobre los participantes del conjun-to Para ello usa una ligera variante del protocolo SWIM[3] (Scalable Weakly-consistent Infection-style Process Group Membership Protocol) desarrollada porHashiCorp Estaacute clasificado como un protocolo de tipo gossip que debe su nom-bre a la semejanza con coacutemo se distribuye un rumor en una red social
SWIM se sustenta en dos caracteriacutesticas fundamentales la deteccioacuten de fallosy la distribucioacuten de la informacioacuten relativa a los miembros A continuacioacuten sedetalla el funcionamiento de ambos componentes
Deteccioacuten de fallos
Este componente tiene dos paraacutemetros el periodo de protocolo T y el nuacutemerode subgrupos de deteccioacuten de fallos k en los que se dividen los nodos Paracomprobar la comunicacioacuten entre dos maacutequinas usa la utilidad ping basadaen el protocolo ICMP La deteccioacuten de caiacuteda de un servidor sigue el siguientealgoritmo
Durante el periodo T cada miembro Mi de un subgrupo elige otro al azar Mjdel mismo subgrupo y le enviacutea un mensaje ping para comprobar su estado Enel caso de que se cumpla un tiempo de espera determinado por una estimacioacuten
23
del tiempo de ida y vuelta (RTT por sus siglas en ingleacutes) de la red y no hayarespuesta Mi le vuelve a enviar un mensaje ping indirectamente a traveacutes deun nuacutemero k de miembros escogidos aleatoriamente De no recibir ninguna res-puesta Mi establece que Mj ha sufrido un fallo y lo etiqueta como ldquosospechosordquoinformando al componente de distribucioacuten
Figura 15 Diagrama de tiempo del protocolo SWIMFuente httpswwwcscornelledu
Componente de distribucioacuten
Se encarga de informar de cualquier cambio en los miembros a todo el con-junto Los eventos de nodo caiacutedo y la unioacuten o disociacioacuten de un miembro setransmiten a todos los servidores para que actualicen sus lista Para distribuirla informacioacuten a todos los nodos se podriacutea usar el meacutetodo de multicast perosuele estar deshabilitado Por ello se utiliza una teacutecnica de transmisioacuten denomi-nada Piggybacking mediante la cual se adjunta a los propios mensajes PINGy ACK del algoritmo la informacioacuten a distribuir reduciendo asiacute la congestioacutenen la red
523 Planificacioacuten
Proceso encargado de distribuir las tareas entre los nodos clientes de acuerdoa su estado
El planificador de Nomad estaacute basado en las publicaciones de Google sobresus herramientas de gestioacuten de clusters Borg y Omega14 y entiende los trabajosdescritos por el usuario como un estado deseado es decir su despliegue en unamaacutequina cliente de forma correcta y los clientes como el estado actual esto eslo que se encuentra en ejecucioacuten El registro actualizacioacuten o cancelacioacuten de un
14httpresearchgooglecompubspub43438html
24
trabajo asiacute como el fallo de un nodo cliente implican un cambio de estado atramitar por el sistema lo que se define como evaluacioacuten (evaluation) Esto uacutelti-mo supone comparar el estado actual (clientes) con el estado deseado (conjuntode trabajos registrados) y enviarlos a los planificadores correspondientes que seencargaraacuten de asignar las tareas a los nodos clientes
Figura 16 Procedimiento de asignacioacuten en NomadFuente httpswwwnomadprojectio
En la figura 16 se observa el flujo de trabajo en el que las distintas evalua-ciones se encolan en el evaluation broker que se ejecuta en el servidor liacuteder ygestiona las evaluaciones pendientes asignaacutendoles prioridades
A continuacioacuten los nodos servidores ejecutan los scheduling workers queprocesan las evaluaciones llamando a los distintos planificadores que generanun plan de asignacioacuten esto es un conjunto de relaciones entre las tareas y losnodos clientes donde se ejecutaraacuten Este proceso se divide en dos fases primerose descartan aquellos clientes que no cumplan los requisitos y posteriormentese asigna una calificacioacuten al resto Se selecciona el nodo con mayor puntuacioacuteny se encola el plan en el gestor que se ejecuta en el servidor liacuteder Existen tresplanificadores de acuerdo al tipo de trabajo
Service Incluye aquellos trabajos que estaacuten destinados a ejecutarse en un pe-riacuteodo largo de tiempo Para realizar las asignaciones el planificador evaluacuteala mayor parte de los nodos y usa una versioacuten del algoritmo Best fit in-fluenciada por el trabajo de Google en su herramienta Borg Se trata deun algoritmo de planificacioacuten que sacrifica tiempo a cambio de maximizarel rendimiento de los clientes asignando la tarea a la maacutequina que tengala mayor carga de trabajo con el objetivo de reducir equipos en funciona-
25
miento
Batch Tareas que incluyen listas de comandos en general de menor duracioacuteny que no requieren interaccioacuten con el usuario Se vale del algoritmo deSparrow desarrollado por la universidad de Berkeley15 para limitar losnodos clientes a evaluar
System Trabajos destinados a ejecutarse en todos los nodos incluso los que seunen al cluster posteriormente
Core Mantenimiento interno de Nomad
Una vez se ha realizado el proceso de planificacioacuten el nodo liacuteder lo registra enla cola de planes (plan queue) que se encarga de asignarles prioridad y manejarcondiciones de carrera es decir que no accedan a los recursos de los clientes sincontrol y evitar que eacutestos superen su capacidad
La maacutequina liacuteder del conjunto puede de este modo aceptar una asignacioacuteny ser ejecutada por los clientes o por el contrario rechazaacutersela al planificadorlo que implicariacutea realizar un plan parcial o totalmente nuevo
Finalmente el estado de las evaluaciones se actualizan y los clientes soninformados de las asignaciones ejecutaacutendose las tareas
15httppeopleeecsberkeleyedu~keopublicationssosp13-final17pdf
26
6 Casos de uso y despliegue
Con el objetivo de mostrar las posibles utilidades que este tipo de sistemaspueden tener en las infraestructuras TI actuales se han desplegado las dos he-rramientas en la nube Microsoft Azure usando su servicio cloud de instancias demaacutequinas virtuales Linux para simular un conjunto de ordenadores conectadosentre siacute por una red LAN Sobre ellas se ha implementado dos casos de usouna aplicacioacuten web con una arquitectura con cierta orientacioacuten a microserviciosy un sistema de integracioacuten continua
El coacutedigo y todos los ficheros de configuracioacuten se pueden encontrar en elrepositorio del proyecto en GitHub16
61 Aplicacioacuten Web
Se busca simular el proceso de adaptacioacuten de una solucioacuten web para su des-pliegue en un sistema distribuido con las herramientas anteriormente descritascon el objetivo de aumentar tanto su escalabilidad como disponibilidad medianteredundancia
Se ha partido de una aplicacioacuten ya existente17 un servicio de almacenamien-to y reproduccioacuten de canciones A grandes rasgos este servicio permite crearusuarios subir canciones con sus respectivas portadas tener playlists propias yescuchar las canciones a traveacutes de un navegador web
La solucioacuten estaacute dividida en 4 partes (figura 17)
Una vista web con la loacutegica
Un almacenamiento conectado en red (NAS por sus siglas en ingleacutes)
Una API REST para gestionar las peticiones al almacenamiento
Base de datos NoSQL basada en MongoDB
La nueva tendencia de los proyectos web es su implementacioacuten en contene-dores Docker ya que facilitan su portabilidad y ofrecen un procedimiento dedespliegue raacutepido sobre todo a la hora de desarrollar y realizar pruebas en en-tornos de produccioacuten simulados Por ello en este caso se va a hacer uso de los
16httpsgithubcomAntonioAlfrzCloud-Orchestrators17httpsgithubcomsonsoleslpCDPSfy
27
motores de orquestacioacuten de contenedores de ambas herramientas Marathon enDCOS y el controlador Docker en el caso de Nomad
Figura 17 Arquitectura aplicacioacuten web
A continuacioacuten vamos detallar el despliegue en ambas herramientas de es-ta solucioacuten y observar tanto queacute dificultades se encuentran como que ventajasofrecen El objetivo final es adaptar el proyecto modificaacutendolo lo menos posiblecon objeto de analizar la capacidad de estas herramientas para desplegar cual-quier aplicacioacuten sin que eso conlleve la modificacioacuten de la arquitectura de eacutestaes decir que no sea dependiente del entorno
611 DCOS
Se ha descrito DCOS como una herramienta que se despliega sobre un con-junto de ordenadores y que permite instalar gestionar el despliegue de sistemasdistribuidos
Microsoft Azure cuenta con una plantilla para desplegar en su servicio cloudun cluster de maacutequinas virtuales con DCOS ya instalado que cuenta con
Maacutequinas maestras (1 3 o 5 a seleccionar por el usuario) configuradascomo un conjunto de disponibilidad esto eso Azure da ciertas garantiacuteasde que al menos una maacutequina estaraacute en funcionamiento
Maacutequinas agentes Por motivos de seguridad se distinguen dos roles
bull Nodos privados solo accesibles desde la red interna y configuradoscomo un conjunto de escala un recurso de Azure para gestionar ydesplegar maacutequinas con configuraciones ideacutenticas para permitir unraacutepido escalado
bull Un equipo conectado accesible desde Internet a travntildees de un balan-ceador de carga puacuteblico y situado en una subred externa
28
Dos balanceadores de carga
bull La interfaz puacuteblica del cluster que se conecta con el cliente puacuteblicobull Acceso a los equipos maestros para el administrador que soacutelo permiteconexioacuten mediante SSH y credenciales
Almacenamiento para todas las maacutequinas
Configuraciones necesarias de red y seguridad
En la figura 18 se observa un diagrama de la infraestructura
Figura 18 Infraestructura en Azure
El primer obstaacuteculo es la persistencia de estado de la aplicacioacuten que seconsigue gracias a una base de datos no relacional basada en MongoDB asiacutecomo el almacenamiento de las canciones Para implementarla tenemos variasposibilidades
Montar un sistema externo de almacenamiento conectado en red en todoslos agentes donde se ejecuten las tareas de esta manera si una tarea pasade un nodo a otro por cualquier motivo puede tener acceso a los mismosficheros (opcioacuten del caso de uso original)
Implementar un sistema de ficheros distribuidos en los agentes
Usar los servicios de almacenamiento de las nubes puacuteblicas
Aprovechar el sistema de voluacutemenes persistentes de Apache Mesos Eacutestepermite reservar recursos de un agente de forma que al arrancar una tarease crea un volumen independiente del ciclo de vida de eacutesta con ello esosrecursos donde se ha almacenado la informacioacuten pueden volver a ofrecerseal mismo entorno de tal manera que otra tarea pueda acceder a ella
DCOS aprovecha este sistema de voluacutemenes persistentes y permite instalarbases de datos distribuidas como ArangoDB o Apache Cassandra sin embargoesto implicariacutea modificar todo el coacutedigo referente al modelo de la base de datos
29
Por motivos de eficiencia y latencia asiacute como de una mayor gobernabilidadde los datos la mejor opcioacuten es usar el recurso de voluacutemenes persistentes queofrece Apache Mesos ya que de esta manera se gestionariacutea la aplicacioacuten completamediante una uacutenica herramienta Sin embargo esto implica que la informacioacutense encuentra exclusivamente en el agente donde se haya ejecutado la tarea y porlo tanto se sigue requiriendo de software externo para distribuir la informacioacutenpara que se accesible para todos los agentes A la hora de realizar este proyectose encontraba en desarrollo Flocker una solucioacuten desarrollada por ClusterHQque permite compartir los voluacutemenes de Docker a traveacutes de un cluster quesi bien es compatible con el planificador de Mesos el proyecto se encontrabatodaviacutea en fases tempranas de desarrollo y los sistemas de almacenamiento quesoporta quedaban fuera del aacutembito de este trabajo
Por todo ello dado que las maacutequinas se han desplegado en la nube puacuteblicade Azure se decidioacute usar su servicio de almacenamiento de objetos para lascanciones y otra maacutequina para desplegar MongoDB y asiacute mantener el modelode datos original de la aplicacioacuten La diferencia del almacenamiento de obje-tos con respecto a nivel de fichero es que el primero no tiene jerarquiacutea paraorganizar los archivos eacutestos se guardan como objetos (con sus metadatos) enun mismo espacio soacutelo diferenciaacutendose por un identificador uacutenico esto implicaentre otras cosas que se puede acceder a un fichero dado uacutenicamente su IDindependientemente de la localizacioacuten fiacutesica de eacuteste facilitando pues la gestioacuteny el desarrollo
El coacutedigo del proyecto se ha modificado en los siguientes apartados
Las direcciones de la base de datos y los balanceadores de carga asiacute comosus puertos estaban originalmente fijos Se han configurado como variablesde entorno para facilitar el descubrimiento del servicio y hacer transpa-rente la aplicacioacuten al entorno de despliegue
La API REST se ha adaptado al almacenamiento en Azure en vez de enlocal
Estas modificaciones no suponen un cambio sustancial pero permiten separala persistencia de las tareas ejecutadas por DCOS lo que facilita en granmedida su ejecucioacuten al ser totalmente sin estado y ademaacutes implican tenerlos datos bajo un mayor control
Para la orquestacioacuten de contenedores se va a usar el entorno Marathondesarrollado tambieacuten por Mesosphere Eacuteste se puede usar a traveacutes de una interfazgraacutefica la interfaz de liacutenea de comandos (en lo que sigue CLI por sus siglas eningleacutes) de DCOS o con su API HTTP
Primero se han publicado la imaacutegenes de los contenedores que encapsulanla interfaz web y la api de la aplicacioacuten en el repositorio puacuteblico DockerHub
Los despliegues en este entorno se describen mediante ficheros JSON en losque se detalla entre otras opciones la imagen del contenedor los puertos a usar
30
los recursos que debe ocupar en un nodo o las instrucciones de monitorizacioacuten
Para el servicio de descubrimiento DCOS ofrece la posibilidad de asignardirecciones IP virtuales (VIP por sus siglas en ingleacutes) a tareas que se compartenen todos los nodos DCOS lleva integrado un balanceador de carga a nivel TCP(el componente denominado Minuteman) que balancea entre las direccionesvirtuales de las tareas y todas las instancias de eacutestas a lo largo del cluster Estoes necesario por dos motivos equilibrar la carga de los equipos con el fin deevitar un punto de uacutenico fallo mediante redundancia y evitar la contienda dedirecciones al ejecutar las tareas en puertos aleatorios
Este balanceador de carga estaacute basado en el trabajo de Michael Mitzenma-cher The Power of Two Choices in Randomized Load Balancing18 A grandesrasgos el algoritmo mantiene una media moacutevil exponencial de latencias paracada destino (backend) ademaacutes de las caiacutedas consecutivas Si un destino noresponde a una negociacioacuten en tres pasos (three way handshake) de forma con-secutiva en un periodo inferior a 5 ms se considera caiacutedo El algoritmo iterasobre los destinos disponibles en base a su histoacuterico de fallos y escoge dos deforma aleatoria de los cuales coge el de mejor meacutetrica
Las direcciones virtuales soacutelo se pueden resolver dentro del cluster porello para implementar la interfaz puacuteblica de la aplicacioacuten esto es el balancea-dor de carga de la interfaz web usaremos un paquete de DCOS denominadomarathon-lb un balanceador basado en HAProxy y adaptado por MesosphereEn este caso equilibra la carga de todas instancias de las tareas ejecutadas porel entorno Marathon por sus etiquetas y permite ademaacutes definir como puntode entrada muacuteltiples hosts virtuales definidos por sus nombres completos dedominio (FQDN por sus siglas en ingleacutes) en nuestro caso la interfaz puacuteblicadel balanceador de Azure para los agentes
Por motivos de seguridad todas las tareas se ejecutan en los agentes privadoses decir los que son exclusivamente accesibles desde la red interna Por su partemarathon-lb se ejecuta en el agente puacuteblico que cuenta con IP puacuteblica y lospuertos 80 (HTTP) y 8080 abiertos de forma que la aplicacioacuten sea accesibledesde Internet Esto es posible debido a que Apache Mesos permite reservarrecursos mediante roles asignados a nodos para un uso especiacutefico De esta formala arquitectura vista desde la aplicacioacuten quedariacutea como en la figura 19
18httpswwweecsharvardedu~michaelmpostscriptstpds2001pdf
31
Figura 19 Arquitectura de la aplicacioacuten web en DCOS
Ejecucioacuten
A la hora de desplegar la aplicacioacuten DCOS puede gestionarse medianteuna interfaz graacutefica o una interfaz de liacutenea de comandos La primera se accedea traveacutes de un navegador web en el puerto 80 (HTTP) y permite instalar losentornos disponibles observar el estado de los nodos y las tareas que se estaacutenejecutando y los ficheros de registros que eacutestas generan
La CLI permite el control desde un nodo o una maacutequina remota (suponiendoque los maestros tienen IP puacuteblica y el puerto 80 abierto) ya que DCOS tieneun sistema de autorizacioacuten que permite tener una interfaz puacuteblica con ciertasgarantiacuteas de seguridad
Por su parte cada entorno de trabajo puede ser controlado por la CLI peroademaacutes cuenta con sus propias interfaces Marathon expone una API HTTPen el puerto 8080 de la direccioacuten puacuteblica de los maestros del cluster asiacute comootra interfaz graacutefica Para desplegar un contenedor se podriacutea usar la CLI
$ dcos marathon app add lt f i l e j songt
O la API HTTP
$ cu r l minusX POST http lt ip_maestro gt8080v2apps minusd ltf i l e jsongt minusH Contentminustype app l i c a t i o n j son
32
612 Nomad
La arquitectura de Nomad es maacutes sencilla ya que solo requiere de un ficheroejecutable en todos los nodos para funcionar Si DCOS es la base de instala-cioacuten de entornos de terceros Nomad integra todas las funcionalidades baacutesicasesto es gestor de recursos planificador y ejecutor en los nodos cliente Estaherramienta cuenta con un menor tiempo de desarrollo y en el momento deescribir este documento cuenta exclusivamente con los siguientes controladoresen comparacioacuten con los entornos de DCOS
Motor Docker es decir funcioacuten de orquestacioacuten de contenedores
Ejecucioacuten de archivos binarios como comandos de Shell
Ejecucioacuten de aplicaciones Java
Virtualizacioacuten de maacutequinas mediante tecnologiacutea QEMU
Todos ellos necesitan que la tecnologiacutea subyacente esteacute instalada en las maacute-quinas clientes (Docker Java QEMU) Actualmente no permite el registro decontroladores por parte de terceros aunque estaacute planificado en un futuro ofreceruna interfaz para su desarrollo
Nomad no cuenta con el servicio de descubrimiento sin embargo puede inte-grarse con la herramienta Consul desarrollada por la misma empresa Por otrolado para el balanceo de carga usaremos un contenedor Docker con HAProxyuna herramienta de coacutedigo abierto que ofrece tanto servicios de proxy como debalanceador y cuyos ficheros de configuracioacuten completaremos con el proyectoConsul Template19
Consul
Consul sigue la misma arquitectura que Nomad es decir un nodo servidorque orquesta un conjunto de maacutequinas clientes y permite a los procesos que seejecutan en los equipos definirlos como servicios ofreciendo diversas caracteriacutes-ticas entorno a estos de los cuales vamos a usar dos
Descubrimiento de servicio Las maacutequinas clientes publican en el cataacutelogode servicios las tareas en ejecucioacuten y Consul les asigna nombres de dominioaccesibles por todos los miembros del cluster a traveacutes de la interfaz DNSincluida en esta herramientaConsul se integra con Nomad de forma que todas las tareas que se ejecu-ten en la segunda son automaacuteticamente publicados como servicios de laprimera de esta manera no hace falta conocer la direccioacuten de la maacutequinacliente donde se esteacute ejecutando el proceso ya que se puede acceder a eacutela traveacutes de su nombre de dominio de forma transparente Por ejemplo si
19[httpsgithubcomhashicorpconsul-template]
33
ejecutamos una tarea con ID web en el puerto 8080 se puede acceder aella en la direccioacuten webserviceconsul8080Para que las direcciones propias de Consul las resuelva su propio DNS y noel que esteacute asignado por defecto en la maacutequina usaremos la herramientadnsmasq20 que permite especificar la direccioacuten de un servidor DNS paraconsultas de direcciones especiacuteficas
Monitorizacioacuten Permite realizar comprobaciones del servicio y seguir su esta-do Aprovecharemos esta funcionalidad tanto para definir el propio procesode Nomad como servicio de Consul como las tareas desplegadas
HAProxy + Consul Template
HAProxy es una solucioacuten versaacutetil de coacutedigo abierto que ofrece solucionesde balanceo de carga y proxy Existen otras herramientas en el mercado comoNGINX o ldirectord sin embargo HAProxy suponiacutea una solucioacuten sencilla deconfigurar para mostrar el caso de uso
El uso de estas herramientas se debe a dos motivos para que no existacontienda con respecto a los puertos de los clientes usados por las tareas eacutestos sevan a asignar de forma dinaacutemica lo que en principio implicariacutea que la aplicacioacutendeberiacutea realizar consultas DNS de tipo SRV (que incluye puertos) a la interfazde Consul y balancear la carga entre tareas por redundancia y capacidad
Como la direccioacuten IP y puerto son variables cada vez que las tareas seactualicen o se reasignen es necesario volver a configurar HAProxy de formamanual Por ello HashiCorp ha desarrollado un programa denominado Con-sul Template que realiza peticiones sucesivas a la interfaz HTTP de Consul delas direcciones fiacutesicas de un servicio y reinicia automaacuteticamente el proceso deHAProxy Asiacute definiendo estas tareas como servicios Consul podremos tantomonitorizarlas como escalar las tareas dinaacutemicamente sin necesidad de cambiarel balanceador A partir del contenedor Docker oficial de HAProxy se ha desa-rrollado otro con la configuracioacuten baacutesica y con Consul Template para desplegarlocomo una tarea en Nomad
Despliegue
Se ha usado el mismo coacutedigo que en el apartado anterior con la persistenciaen el servicio de almacenamiento de Azure Desde la perspectiva del hardwarese implementaraacute la misma infraestructura que en el caso de DCOS (figura 18)estos es definiremos dos tipos de maacutequinas clientes un agente que se conectaraacutecon el balanceador de carga con nombre de dominio puacuteblico y donde se desple-garaacute el balanceador de carga de la vista web y agentes privados no accesiblesdesde fuera del cluster y donde se ejecutaraacuten el resto de tareas en la red inter-na La principal diferencia radica en las tareas que ejecutan HAproxy y ConsulTemplate que sustituye a las direcciones IP virtuales que ofrece DCOS
20httpwwwthekelleysorgukdnsmasqdochtml
34
Figura 20 Despliegue en Azure de Nomad+Consul
Cabe matizar que los balanceadores basados en HAProxy se implementanpor necesidad de la aplicacioacuten para el descubrimiento del servicio a diferenciade los de Azure que se implementan por motivos de seguridad y escalabilidaddel cluster en siacute
Configuracioacuten Nomad
Los ficheros de configuracioacuten de las maacutequinas maacutester y cliente son similaresy comparten la mayoriacutea de las opciones como por ejemplo el nombre del nodoo la interfaz de red donde escucha Nomad las peticiones Sus opciones son engeneral auto-explicativas sin embargo existen dos detalles que matizar
El proceso de Nomad escucha las peticiones tanto de los protocolos deconsenso como del usuario a traveacutes de una interfaz de red que se debeindicar en el fichero de configuracioacuten
En el caso de los clientes se deben indicar las direcciones de los servidoresdel cluster sin embargo se trata de un sistema dinaacutemico en el que losnodos pueden sufrir errores y cambiar de direccioacuten Por ello se ha definidoNomad como un servicio de Consul y asiacute poder definir la direccioacuten de losservidores como un nombre de dominio no por su direccioacuten fiacutesica que elservidor DNS de Consul se encargaraacute de resolver
Por defecto Nomad usa los siguientes puertos
API HTTP 4646 Peticiones HTTP y recepcioacuten de oacuterdenes mediante laliacutenea de comandos
RPC 4647 Protocolo de consenso entre los nodos del cluster
Serf 4648 Protocolo de gossip entre los servidores de los centros de datosgobernados por Nomad
35
Los dos uacuteltimos deben ser interfaces alcanzables por otros nodos sin embargo laAPI HTTP por motivos de seguridad deberiacutea ser local ya que en caso contrariocualquier persona con acceso a ella tiene el control sobre la herramienta Eacutestasolo deberiacutea estar accesible en un servidor o gestionarlo mediante una terminalSSH por ejemplo En este trabajo al ser una prueba de concepto se ha abiertoen todos los nodos
Trabajos de Nomad
Las tareas se detallan en ficheros con formato HashiCorp Configuration Lan-guage un derivado del formato JSON creado por la empresa que le da nombrecompatible con eacuteste y que permite comentarios
En estos ficheros se puede definir
La regioacuten y el centro de datos donde se ejecutaraacute (Nomad permite lagestioacuten de centros de datos geograacuteficamente distribuidos en regiones)
La poliacutetica de actualizacioacuten de la tarea
Grupo de tareas esto es que se ejecutaraacuten en el mismo nodo
El nuacutemero de grupos a ejecutarescalar asiacute como los liacutemite que debencumplir los nodos asignados
La poliacutetica de reinicio ante fallo o error
Tareas El controlador su configuracioacuten los paraacutemetros del servicio aso-ciado a registrar en Consul asiacute como los recursos que consume (puertosmemoria)
En nuestro caso usamos sobre todo el controlador Docker esto eso orques-tacioacuten de contenedores en los nodos clientes y tres de sus opciones
Imagen del contenedor Se han subido todas las imaacutegenes del proyecto a Doc-ker Hub donde por defecto se busca la imagen
Puertos Los puertos a usar por el contenedor que pueden ser estaacuteticos asigna-dos por el usuario o dinaacutemicos siendo Nomad el que se encarga de mapearun puerto libre del nodo cliente al expuesto por el contenedor
Servidores DNS Como usamos la interfaz DNS de Consul como descubri-miento de servicio se debe configurar el contenedor para que use cualquiernodo del cluster como servidor DNS
Configuracioacuten Consul
Al ser desarrolladas por la misma empresa los ficheros de configuracioacuten deConsul y Nomad comparten muchas opciones Consul tambieacuten acepta peticionesa traveacutes de una interfaz de red siendo los puertos usados por defecto
36
RPC 8300 8400 Maneja la peticiones del resto de nodos y usuarios
Serf 8301 8302 Protocolo gossip
HTTP API 8500
HTTPS API Desactivada por defecto
Interfaz DNS 8600
Se debe asignar a los protocolos internos del cluster esto es RPC y Serf unainterfaz alcanzable por los nodos y por el contrarioasignar a los dos uacuteltimos ala interfaz de loopback por motivos de seguridad
Cabe destacar que Consul tambieacuten cuenta con una interfaz graacutefica que per-mite ver el estado de los equipos y los servicios registrados y que se encuentra enel mismo puerto que la API HTTP en la direccioacuten httpIP_EQUIPO8500ui
Ejecucioacuten
Tanto Nomad como Consul requieren de la ejecucioacuten de un fichero en todoslos nodos integrantes del cluster Como prueba de concepto se ha decidido usardos servidores para ambos aunque cabe matizar que es un nuacutemero ineficienteya que la caiacuteda de uno de ellos supondriacutea la peacuterdida del cuoacuterum y por tantodel consenso del cluster
En primer lugar se arrancan los servidores que son los encargados de ejecu-tar el protocolo de consenso y gestionar el cluster y a continuacioacuten los clientesque no tienen praacutecticamente estado y dependen de los servidores
En el caso de Consul se debe indicar el directorio donde se guardan losficheros que describen los servicios asiacute como el archivo que especifica el resto delas opciones
1 Se inicia el primer servidor en uno de los equipos
$ consu l agent minuscon f i gminusd i r e t c consu l d s e r v i c e s minuscon f i gminus f i l e consu l_server j son
2 Los siguientes equipos deben unirse al anterior por lo que antildeadimos elargumento join con la direccioacuten del primer servidor Para el caso de otrosservidores
$ consu l agent minuscon f i gminusd i r e t c consu l d s e r v i c e s minuscon f i gminus f i l e consu l_server j son minus j o i n ltIP_servidor1gt
37
Una vez los servidores han alcanzado el consenso y elegido un liacuteder en losclientes
$ consu l agent minuscon f i gminusd i r e t c consu l d s e r v i c e s minuscon f i gminus f i l e c on su l_c l i en t j son minus j o i n ltIP_cualquierServ idorgt
El proceso para iniciar Nomad es igual y los comandos similares sin embargoya no es necesario indicar una direccioacuten IP fija en los equipos sino el nombre dedominio del servicio de Nomad registrado por Consul En el primer servidor
$ nomad agent minusc on f i g nomad_server j son
Y el resto de equipos (con su fichero de configuracioacuten correspondiente)$ nomad agent minusc on f i g nomad_server j son minus j o i n nomad s e r v i c e consu l
Por uacuteltimo para desplegar la aplicacioacuten web se han escrito tres ficherosque detallan las tareas de la interfaz web API y los balanceadores de cargaMediante la CLI
$ nomad run minusaddress=http lt ip_c lus te r gt4646 lt f i l e hclgt
O mediante la API HTTP de Nomad$ cu r l minusX POST minusd ltf i l e hclgthttp lt ip_c lus te r gt4646 jobltjob_namegt
Ansible
Como se puede comprobar con el aumento del nuacutemero de equipos pasa aser inviable manejar todos los nodos a traveacutes de terminal Ademaacutes como seha comentado con anterioridad Nomad requiere que en los nodos clientes es-teacuten instalados las herramientas que soporten las tareas por ejemplo el motorde Docker Por ello para facilitar tanto el arranque como la instalacioacuten de lasdependencias vamos a usar Ansible una herramienta de coacutedigo abierto desarro-llada en Python que permite gestionar configuraciones aprovisionar recursosdespliegue de aplicaciones de forma automaacutetica
A grandes rasgos esta herramienta funciona mediante ficheros en formatoYAML denominados play-books que describen un conjunto de pasos a ejecutaren una lista de equipos remotos Estos pasos son ejecutados por moacutedulos inde-pendientes a traveacutes de SSH es decir en cualquier ordenador con conexioacuten a los
38
hosts dado su contrasentildea o clave puacuteblica puede arrancar el script y realizariacutealos pasos de forma remota gestionando el cluster desde un solo equipo
Se han desarrollado guiones para lo siguiente
Descarga de los binarios de Nomad y Consul en todos los nodos copiade los ficheros de configuracioacuten baacutesicos y modificarlos de acuerdo a cadanodo (nombre del equipo direccioacuten IP)
Instalacioacuten de las dependencias
Arranque de Nomad y Consul
Ansible extiende su funcionalidad a traveacutes de moacutedulos independientes que per-miten por ejemplo instalar paquetes mediante herramientas de gestioacuten de pa-quetes (APT yum) aprovisionar automaacuteticamente maacutequinas virtuales de Ama-zon EC2
Algunas opciones de los ficheros de configuracioacuten de Nomad y Consul sondependientes del nodo particular por ejemplo la interfaz de red Para estetrabajo se ha realizado un moacutedulo para modificar los ficheros de configuracioacutende forma automaacutetica En el repositorio del proyecto se encuentra una carpetadonde se encuentran todos los ficheros necesarios para desplegar un clustertotalmente funcional solo requiere de una liacutenea de terminal con Ansible
$ ans ib l eminusplaybook minus i hos t s minusk ltssh_passgt minusu ltnode_usergt s i t e yml
39
62 Servicio de integracioacuten continua
Se ha implementado un sistema de integracioacuten continua que permite ejecu-tar tareas de compilacioacuten y pruebas de forma distribuida aumentando asiacute elrendimiento de los equipos En primer lugar se detallaraacute los motivos por los quepuede resultar beneficioso para las empresas una implementacioacuten de este tipo alo que seguiraacute los detalles del despliegue
621 DevOps
Metodologiacutea que defiende la comunicacioacuten y colaboracioacuten entre desarrolla-dores de software y los profesionales de operaciones a lo largo de todo el ciclo devida de una aplicacioacuten Estaacute muy relacionado con el desarrollo aacutegil de softwareesto es un enfoque para los proyectos que defiende el desarrollo iterativo e in-cremental donde los requisitos y soluciones evolucionan con el tiempo seguacuten lanecesidad del proyecto DevOps extiende esta filosofiacutea a todas los componentesde un servicio incluyendo sistemas y operaciones
Se trata de un concepto que cada organizacioacuten o empresa adapta a suspropias necesidades y procesos de negocio en este proyecto nos vamos a centraren la integracioacuten continua una praacutectica fundamental tanto del desarrollo aacutegilcomo de esta filosofiacutea
622 Integracioacuten Continua
Se define como una praacutectica de desarrollo software donde los miembros delequipo ponen en comuacuten su trabajo frecuentemente al menos una vez al diacutea21Cada integracioacuten se verifica con una compilacioacuten automaacutetica que incluye laejecucioacuten de pruebas para detectar errores de integracioacuten tan pronto como seaposible
Desde el punto de vista operativo esto supone automatizar la configuracioacutende equipos o el despliegue de maacutequinas virtuales donde compilar el proyecto yejecutar las pruebas y posteriormente eliminarlas Este flujo de trabajo se vebeneficiado en entornos distribuidos ya que el objetivo del desarrollador es com-probar el resultado de las pruebas raacutepidamente sin preocuparse del despliegueo los propios equipos
Para esta prueba de concepto vamos a usar Jenkins un servidor de integra-cioacuten continua escrito en Java que nos permite definir trabajos que contendraacutenla descripcioacuten tanto del entorno como su ejecucioacuten
Este sigue una estructura maestro-esclavo muy similar al de los gestores declusters usados en este proyecto el maestro contiene toda la loacutegica del servicio
21httpmartinfowlercomarticlescontinuousIntegrationhtml
40
trabajos autenticacioacuten y los esclavos son los encargados de la ejecucioacuten ensiacute Jenkins tiene varias viacuteas para aprovisionar los uacuteltimos
Mediante SSH
Interfaz graacutefica
Desarrollar un script propio
Ejecucioacuten de un fichero java
La ventaja de usar planificadores es que el despliegue de esclavos es dinaacutemicoes decir no tener una maacutequina especiacuteficamente configurada para ello DCOS yNomad se encargaraacuten de configurar estos despliegues en sus maacutequinas y poste-riormente eliminarlos Para ello se ha usado la uacuteltima opcioacuten definiendo tareasque descarguen el fichero java Con todo ello se consigue un entorno de inte-gracioacuten continua eficiente que ademaacutes permite la ejecucioacuten de otros servicios deforma independiente
Jenkins permite la creacioacuten de plugins que extienden sus funcionalidadesTanto Nomad22 como Apache Mesos cuentan con uno que permite su integra-cioacuten
Para esta prueba se va a usar el mismo proyecto que para el caso de usode orquestacioacuten de contenedores la aplicacioacuten web al que se le ha antildeadido untest para comprobar que se conecta correctamente a la base de datos medianteMocha un framework de Nodejs Por otro lado se antildeade el plugin de git ya queel coacutedigo se obtiene de GitHub el repositorio remoto de control de versiones delproyecto
El proceso general de ejecucioacuten seriacutea como sigue
1 Se ejecuta el maestro de Jenkins como tarea Docker partiendo de la imagenoficial
2 Al arrancar un trabajo se manda una tarea a los planificadores que laasignaraacuten a un nodo cliente Esta tarea consiste en la descarga del ficherode configuracioacuten Java y arrancarlo configurando el equipo como un clientede Jenkins temporalmente
3 Jenkins ejecuta el trabajo en el nuevo cliente en este caso iniciar la apli-cacioacuten web iniciar las pruebas y generar un informe
4 Se elimina el cliente
A continuacioacuten se detallan los matices de cada herramienta a la hora de imple-mentar este servicio
22Desarrollado por Ivo Verberk httpwwwivoverberknl
41
623 Jenkins con Nomad
El plugin permite la ejecucioacuten del fichero Java mediante dos controladorescontenedores Docker y Java En este proyecto nos hemos decantado por el pri-mero ya que nos ahorra instalar la maacutequina virtual de java en todos los nodoscliente Por ello se ha construido un contenedor base con Java para la ejecucioacutendel fichero de configuracioacuten y Nodejs para lanzar la aplicacioacuten web
El plugin se configura con la direccioacuten IP del cluster y el contenedor queejecuta el esclavo Jenkins Por su parte el trabajo en Jenkins se define conel repositorio en GitHub donde se aloja el coacutedigo del proyecto a probar y loscomandos a ejecutar en este caso npm update y npm test
624 Jenkins con DCOS
En el caso de DCOS su sistema de paquetes incluye Jenkins por lo queal instalarlo ya se tiene la configuracioacuten de Mesos totalmente funcional Sinembargo para ejecutar la aplicacioacuten en particular y las pruebas se requiere deNodejs en los equipos esclavos por ello debemos antildeadir un plugin de Jenkinsque permite instalar este entorno antes de ejecutar el trabajo Una vez hechoesto soacutelo queda definir la tarea igual que en el caso anterior
Cabe destacar que Mesosphere tambieacuten ha desarrollado un plugin que per-mite hacer despliegues en Marathon de tal manera que permitiriacutea con cadacommit del coacutedigo compilar la imagen del contenedor Docker y desplegarlaautomaacuteticamente aunque en este proyecto no se ha hecho pruebas de esta fun-cionalidad
42
7 Escalando la infraestructura
Uno de los factores clave que se busca a la hora de implementar sistemasdistribuidos es el poder escalar la infraestructura de forma maacutes sencilla estoes detectar que las maacutequinas estaacuten alcanzando el liacutemite de su capacidad yaumentar eacutesta ya sea mejorando sus caracteriacutesticas teacutecnicas o antildeadiendo maacutesnodos al cluster
El coacutedigo y todos los ficheros de configuracioacuten de esta seccioacuten tambieacuten sepueden encontrar en el repositorio del proyecto en GitHub23
71 Disentildeo
Microsoft Azure permite organizar los servicios cloud de forma loacutegica a traveacutesde grupos de recursos y asiacute poder crear o eliminar eacutestos en conjunto parauna aplicacioacuten determinada (por ejemplo una aplicacioacuten web suele requerir demaacutequinas virtuales bases de datos almacenamiento) Ademaacutes dispone dela opcioacuten de crear plantillas en formato JSON que permite al desarrolladordefinir los recursos y su interrelacioacuten para desplegar de forma automaacutetica unainfraestructura TI en la nube
Azure tambieacuten ofrece la posibilidad de monitorizar el estado de las maacutequinasvirtuales a traveacutes de extensiones lo que permite configurar el escalado automaacute-tico al alcanzar cierto liacutemite definido por el operador Eacutesta es a priori la formaen que deberiacutea implementarse hablando en teacuterminos de eficiencia sin embargoesta aproximacioacuten es totalmente dependiente de la plataforma es decir no sepuede extrapolar a otro proveedor o sobre recursos propios sin realizar un nue-vo disentildeo En este proyecto las tareas que son ejecutadas por estos equipos notienen estado ya que todo lo relativo a la persistencia lo hemos asignado fueradel cluster esto permite escalar la plataforma a traveacutes de otra aproximaciones
Las plantillas aceptan una serie de variables a indicar por el usuario entreotras los conjuntos de escala para definir los nodos aceptan una variable quedefine el nuacutemero de maacutequinas que los componen Por otro lado Azure ofreceuna API REST y kits de desarrollo software (SDK por sus siglas en ingleacutes) quepermiten su despliegue de forma programaacutetica Aprovechando estas facilidadesen este proyecto se va a aproximar la escalabilidad con el sucesivo desplieguede la infraestructura de forma automaacutetica se monitorizan los equipos y si sedetecta una maacutequina excesivamente cargada se aumenta el nuacutemero de equiposen la plantilla y se vuelve a desplegar
23httpsgithubcomAntonioAlfrzCloud-Orchestrators
43
En este proyecto se han disentildeado las plantillas para desplegar la arquitec-tura necesaria tanto de Nomad como de DCOS En el caso de la primera eldespliegue es maacutes descriptivo ya que incluye maacutequinas virtuales grupos de se-guridad redes En el caso de DCOS Azure cuenta con un servicio especiacuteficopara clusters gobernados por DCOS denominado Azure Container Service queincluye los componentes necesarios y la instalacioacuten ya realizada
72 Implementacioacuten
En primer lugar para monitorizar el estado de los equipos se va a usar laherramienta Nagios un sistema que permite controlar el estado del hardwarey los servicios de un equipo Se trata de una herramienta muy completa de laque se va a usar su capacidad para ejecutar comandos (plugins) en los nodospara detectar picos de carga generar alertas y ejecutar programas para estoseventos
Se ha desplegado una maacutequina virtual con esta herramienta en ambos siste-mas y se ha instalado una extensioacuten de Nagios (Nagios Remote Plugin Executor)en todos los nodos que permite ejecutar comprobaciones remotamente en con-creto para esta prueba de concepto medir el nivel de saturacioacuten de la unidadcentral de procesamiento (CPU por sus siglas del ingleacutes) Cuando sucede uncambio de estado de una maacutequina esto es cuando este paraacutemetro supera el liacutemi-te definido por el operador Nagios permite actuar en consecuencia ejecutandoprogramas por ello se ha desarrollado un script que ejecuta lo siguiente
Un programa desarrollado en Python con el SDK de Azure que modificalas plantillas y despliega los recursos
Un guioacuten de Ansible para instalar todos los componentes necesarios en lasnuevas maacutequinas y arrancar de nuevo el cluster y las aplicaciones
44
8 Resultados y conclusiones
En este uacuteltimo apartado se da una visioacuten global del proyecto asiacute como a lasconclusiones maacutes importantes a las que se ha llegado y posibles temas futurosde desarrollo
81 Comparacioacuten
Ambas herramientas ofrecen las funcionalidades para gestionar los recursoseficientemente ofreciendo a los desarrolladores una plataforma donde desplegarsus aplicaciones de forma distribuida independientemente de los equipos fiacutesicosy el hardware que las soporten
DCOS es una herramienta que en un comienzo fue privativa pero cuyos res-ponsables la empresa Mesosphere decidieron publicar una versioacuten de coacutedigoEacutesta nos permite gestionar un cluster de una forma sencilla y usable ademaacutes decomplementarlo con otras herramientas como el balanceador de carga integradoo la autenticacioacuten de usuarios ademaacutes estaacute basada en Apache Mesos un pro-yecto de relativa madurez y con el soporte de la Apache Software FoundationDe forma resumida DCOS ofrece muchas posibilidades y servicios a cambiode una arquitectura e instalacioacuten maacutes compleja
Por su parte HashiCorp con menor tiempo de desarrollo ha conseguidouna herramienta muy sencilla de desplegar que ademaacutes cumple con todas lasfuncionalidades baacutesicas ejecutando un simple binario en cada nodo se puededesplegar un gestor de clusters totalmente funcional Sin embargo no cuentacon todas las posibilidades de Mesos (Nomad cuenta con menos controladoresque entornos posibles de Mesos) ni con los antildeadidos de DCOS lo que implicael uso de otras herramientas para complementar el servicio (Consul HAProxy)
De entre las dificultades encontradas al usar estas herramientas y desplegaraplicaciones sobre ellas se puede destacar la depuracioacuten en ocasiones se desco-noce si un error viene de la propia herramienta de la aplicacioacuten desplegada o delequipo fiacutesico si no se cuenta con un sistema de procesamiento de registro unose puede encontrar con muacuteltiples terminales abiertas inspeccionando numerososficheros de registro buscando posibles errores Ademaacutes no dejan de ser solucio-nes que para usar eficientemente se debe conocer parte de su funcionamientoy sintaxis a la hora de describir la tareas lo que supone un esfuerzo antildeadido yaque cada una tiene sus particularidades y liacutemites
45
82 Conclusiones
En una sociedad cada vez maacutes digital las empresas deben adaptarse a unmercado cuya demanda de contenido no deja de crecer Las nuevas arquitecturascomo microservicios asiacute como la gran cantidad de datos generada implica queuna mejor gestioacuten de los recursos y la rapidez para desplegar o escalar solucionesdando valor al cliente lo maacutes raacutepido posible es uno de los objetivos de todas lasempresas de base tecnoloacutegica
Las ventajas que ofrecen los planificadores con aplicaciones distribuidas sonnumerosas sin ir maacutes lejos empresas tan punteras como Google llevan maacutesde 10 antildeos orquestando contenedores24 Por un lado permiten aumentar elrendimiento de los equipos propios y por otro implementar un servicio comoplataforma para despliegues distribuidos sobre cualquier conjunto hardware deesta forma se provee un servicio similar al de la nube puacuteblica pero con laprincipal diferencia de que se elimina la independencia con el proveedor (vendorlock-in) esto es las aplicaciones no tienen limitaciones impuestas por eacuteste talescomo lenguaje de programacioacuten o herramientas y permite despliegues hiacutebridosentre recursos propios y la nube
83 Objetivos conseguidos
Implementacioacuten de los planificadores propuestos en la nube Se ha en-tendido y detallado el funcionamiento de estas herramientas y se hanimplementado en el servicio de infraestructura de Microsoft Azure
Despliegue de aplicaciones y servicios distribuidos Servicios que se usanactualmente en la industria del desarrollo software asiacute como una aplica-cioacuten web con una arquitectura moderna han sido desplegados de formadistribuida en los equipos cumpliendo con la funcionalidad esperada ade-maacutes de consiguiendo una alta disponibilidad
Aproximacioacuten de arquitectura escalable Se ha hecho una aproximacioacutende infraestructura escalable de forma que sea parcialmente extrapolable aotros proveedores
24httpwwwnextplatformcom20160322decade-container-control-google
46
84 Liacuteneas de investigacioacuten
Siguiendo con la materia de este proyecto se presentan posibles liacuteneas deinvestigacioacuten
Analizar el despliegue con estas herramientas de aplicaciones de Big Datay comparar la eficiencia con respecto a soluciones especializadas
Analizar el rendimiento de los algoritmos de planificacioacuten antes pruebasde estreacutes y situaciones de alta contienda
Comparar el uso de estas herramientas con las praacutecticas actuales de laindustria o implementacioacuten en un sistema de produccioacuten real
47
Referencias
[1] LA Barroso y U Houmllzle laquoThe Datacenter as a Computer An Introduc-tion to the Design of Warehouse-Scale Machinesraquo En Morgan amp ClaypoolPublishers ()
[2] Systems Research Group ndash NetOS (University of Cambridge) The evolu-tion of cluster scheduler architectures 2016 url httpswwwclcamacukresearchsrgnetoscamsasblog2016-03-09-scheduler-architectureshtml
[3] A Das I Gupta y A Motivala SWIM Scalable Weakly-consistent Infection-style Process Group Membership Protocol Inf teacutec Dept of ComputerScience Cornell University url https www cs cornell edu ~asdasresearchdsn02-swimpdf
[4] D Dubhashi y A Das Mastering Mesos PACKT Publishing mayo de2016
[5] The Apache Software Foundation Apache Mesos documentation urlhttpsmesosapacheorg
[6] David Greenberg Building Applications on Mesos OrsquoReilly Media 2016[7] Armand Grillet Comparison of Container Schedulers Inf teacutec Technische
Universitaumlt Berlin[8] HashiCorp Consul documentation url httpswwwconsulio[9] HashiCorp Nomad documentation url httpsdcosio[10] Dan C Marinescu Cloud computing theory and practice Morgan Kauf-
mann 2013[11] Mesosphere DCOS documentation url httpswwwnomadproject
io[12] Microsoft Azure documentation url httpsazuremicrosoftcom
es-esdocumentation[13] D Ongaro y J Ousterhout In Search of an Understandable Consensus
Algorithm Inf teacutec Stanford University url httpsraftgithubioraftpdf
[14] Fei Teng laquoRessource allocation and schelduling models for cloud compu-tingraquo Tesis de mtriacutea Ecole Centrale Paris 2011
[15] A Williams y col Automation and Orchestration with Docker and Contai-ners A Comprehensive Overview of the Docker and Container Ecosystem3 The New Stack 2016
48
- Resumen
- Summary
- Iacutendice de figuras
- Introduccioacuten y objetivos
-
- Contexto
- Objetivos
- Estructura del documento
-
- Cloud Computing
- Nuevas cargas de trabajo
- Gestioacuten de recursos Planificadores
-
- Sistemas distribuidos
-
- Clasificacioacuten
-
- Herramientas
-
- DCOS
-
- Apache Mesos
- Ejemplos de uso
-
- Nomad
-
- Protocolo de consenso Raft
- Protocolo gossip SWIM
- Planificacioacuten
-
- Casos de uso y despliegue
-
- Aplicacioacuten Web
-
- DCOS
- Nomad
-
- Servicio de integracioacuten continua
-
- DevOps
- Integracioacuten Continua
- Jenkins con Nomad
- Jenkins con DCOS
-
- Escalando la infraestructura
-
- Disentildeo
- Implementacioacuten
-
- Resultados y conclusiones
-
- Comparacioacuten
- Conclusiones
- Objetivos conseguidos
- Liacuteneas de investigacioacuten
-
el algoritmo Dominant Resource Fairness9 a grandes rasgos se determina entodos los esclavos la tarea en ejecucioacuten que necesita maacutes recursos y se calcula laproporcioacuten del recurso de mayor peso con respecto al total por ejemplo si unatarea ocupa 2 GB de memoria con respecto a 10 GB totales que tiene el clusterse le asigna un dominant share del 20 la tarea se asignaraacute al nodo con menordominant share
Aislamiento de recursos
Para conseguir que tareas de diferentes entornos de trabajo y con distin-ta naturaleza se ejecuten simultaacuteneamente en un mismo nodo Mesos usa loscontenedores Linux (descritos en la seccioacuten 3)
Funcionamiento
La figura 9 muestra el esquema de la arquitectura de Apache Mesos conalta disponibilidad (tres maestros) y con dos entornos de trabajo ejecutaacutendo-se Hadoop que permite el almacenamiento y procesamiento de gran cantidadde datos para proyectos de big data y un sistema que implementa la interfazsistema de paso de mensajes MPI
Como se puede observar el sistema ZooKeeper elige a un solo maestro comoliacuteder y eacuteste orquesta el cluster comunicando los esclavos con los planificadoresde los diferentes entornos de trabajo Tambieacuten se puede observar como las tareasde los distintos entornos estaacuten distribuidas entre los tres esclavos disponibles
Figura 9 Arquitectura de Apache MesosFuente httpsmesosapacheorg
El proceso de asignacioacuten se realiza como sigue en primer lugar un usuariosolicita la ejecucioacuten de una tarea mediante la interfaz de cada entorno de traba-jo (interfaz graacutefica API HTTP ) De forma paralela un esclavo informa almaestro de los recursos que tiene libres En consecuencia eacuteste se lo notifica almoacutedulo de asignacioacuten que en funcioacuten de su configuracioacuten decide cuaacutento ofertar
9httpspeopleeecsberkeleyedu~aligpapersdrfpdf
17
y a queacute entorno de trabajo y enviacutea la oferta a los planificadores Eacutestos respondenal maestro con queacute recursos ha decidido usar para cada tarea Finalmente lastareas son enviadas al esclavo seleccionado el cual asigna los recursos indicadosal procesador (executor) quien finalmente las ejecuta
Cabriacutea pensar que esta metodologiacutea puede conducir a situaciones en lasque un entorno podriacutea quedarse con tareas sin ejecutarse a la espera de unaoferta satisfactoria para ello Mesos implementa un sistema de filtros medianteel cual los entornos especifican los requisitos miacutenimos que debe cumplir unaoferta por ejemplo se puede especificar en queacute nodos debe desplegarse la tareaEste sistema estaacute disentildeado asiacute con el objetivo de mantener lo maacutes transparenteposible esta herramientas de forma que acepte entornos de trabajo de distintasnaturalezas
512 Ejemplos de uso
Grandes empresas estaacuten usando Apache Mesos con eficacia de acuerdo a susnecesidades e infraestructuras Caben destacar
Ebay En el modelo de implementacioacuten continua en esta empresa10 cadadesarrollador cuenta con su propia instancia que se ejecuta en una maacutequinavirtual dedicada lo que ha conllevado un uso de los recursos poco eficiente Enuna prueba de concepto consiguieron realizar una herramienta de integracioacutencontinua distribuida basada en un cluster con Apache mesos y con el entornoMarathon y Jenkins
Apple Anuncioacute que el motor de su famosa herramienta de asistencia per-sonal para iPhones Siri estaacute desplegada sobre Apache Mesos11 Para ello handesarrollado su propio entorno para facilitar a los ingenieros a desplegar los ser-vicios que la herramienta necesita para resolver las peticiones de los usuarios
Twitter Desarrolloacute su propio entorno denominado Aurora y actualmentegestionan sus recursos y miden el coste de las tareas que los empleados usancon el objetivo de que sean conscientes del gasto que puede suponer un usoinadecuado de la infraestructura12
10httpwwwebaytechblogcom20140404delivering-ebays-ci-solution-with-apache-mesos-part-i11httpwwwbusinessinsidercomapple-siri-uses-apache-mesos-2015-812httpswwwlinuxcomNEWS4-UNIQUE-WAYS-UBER-TWITTER-PAYPAL-AND-HUBSPOT-USE-APACHE-MESOS
18
52 Nomad
Herramienta de coacutedigo abierto de gestioacuten de clusters creada y desarrolladapor Hashicorp13 que permite el despliegue de aplicaciones y procesos de formadistribuida
Las principales diferencias con Apache Mesos a grandes rasgos son
Arquitectura maacutes ligera Nomad soacutelo requiere de un fichero para funcionarejecutaacutendolo con las correspondientes configuraciones en todos los nodosrealiza las funciones de gestioacuten del cluster eleccioacuten de liacuteder planificacioacutende recursos y ejecucioacuten de las tareas
Centro de datos y regiones muacuteltiples Su arquitectura estaacute orientada afacilitar la gestioacuten de diferentes centros de datos geograacuteficamente distri-buidos
Entorno de ejecucioacuten Las tareas se definen y son interpretadas mediantecontroladores integrados en Nomad que se valen de los recursos y herra-mientas de los nodos clientes para ejecutarlas Esta integracioacuten dificultael desarrollo de controladores por parte de terceros a diferencia de Mesosque delega dicha responsabilidad en los entornos de trabajo externos alproyecto
Usa un planificador de estado compartido con respecto a la planificacioacutenen dos niveles de Mesos
Antes de entrar en maacutes detalle en la arquitectura es importante definir lossiguientes teacuterminos
Controlador (Driver) Software que se encarga de interpretar las definicionesde las tareas y ejecutarlas semejante a los procesadores de los entornosde trabajo de Mesos A la hora de redactar este proyecto Nomad contabacon controladores para contenedores Docker virtualizacioacuten de maacutequinasmediante el emulador QEMU aplicaciones java y archivos binarios
Grupo de trabajo (Task Group) Conjunto de tareas que se ejecutan en elmismo nodo cliente
Trabajo (Job) Conjunto loacutegico de tareas y grupos de trabajo que se despliegana la vez
Asignacioacuten (Allocation) Relacioacuten entre un grupo de trabajo y el cliente don-de se ejecuta
Evaluacioacuten (Evaluation) Proceso mediante el cual Nomad planifica y ges-tiona el registro o actualizaciones de los trabajos
13httpswwwhashicorpcom
19
Nomad sigue una arquitectura maestro-esclavo similar a la de Apache Mesosmuacuteltiples servidores acuerdan entre siacute un liacuteder que gestiona la planificacioacuten detareas en los clientes que soacutelo conocen sus asignaciones y las ejecutan
Todos los servidores participan paralelamente en tareas de planificacioacuten derecursos y asignacioacuten de tareas y ademaacutes entre ellos eligen un liacuteder que seencarga de la coordinacioacuten de la suscripcioacuten de los clientes al cluster y de lagestioacuten de las peticiones
Los clientes estaacuten configurados para comunicarse con el servidor usando lla-madas a procedimiento remoto (RPC por sus siglas en ingleacutes) que permite unordenador ejecutar coacutedigo en otra maacutequina Mediante esta tecnologiacutea los nodosclientes avisan de su estado e informa de sus asignaciones recursos y controla-dores disponibles
Existe la posibilidad de gestionar varios centros de datos agrupados en regio-nes eacutestas son independientes pero permite definir tareas o comprobar el estadode todas ellas desde cualquier punto A continuacioacuten se muestra una figura dela arquitectura a alto nivel de esta configuracioacuten
Figura 10 Arquitectura multi-regioacuten en NomadFuente httpswwwnomadprojectio
La herramienta se sustenta sobre tres protocolos fundamentales un protocolode consenso entre los servidores para compartir informacioacuten sobre su estado yel liacuteder un protocolo Gossip para la gestioacuten entre regiones y el planificador detareas
521 Protocolo de consenso Raft
El objetivo es obtener consistencia en un conjunto de nodos que comparteninformacioacuten es decir si un cliente realiza un cambio que todos los nodos veanla misma informacioacuten a la vez y ademaacutes sea tolerante a fallos Para ello se basaen el algoritmo Raft[13] que se detalla brevemente a continuacioacuten
20
Los nodos participantes en el algoritmo pueden estar en tres estados
Liacuteder (Leader) Todos los cambios que realicen en el cluster pasan por eacutel pri-mero
Seguidor (Follower) Nodo pasivo cuya responsabilidad es responder a laspeticiones del nodo liacuteder
Candidato (Candidate) Maacutequina que no ha encontrado liacuteder y solicita sueleccioacuten
Supongamos que tenemos cinco equipos que acaban de arrancar el protocoloEn la figura 11 se observan los nodos y sus respectivos registros a la derecha
Figura 11 Equipos sin consenso ejecutando el protocolo RAFTFuente httpsgithubcomongardieraftscope
Al comenzar todos los nodos son seguidores esperando recibir comunicacioacutende un nodo que actuacutee como liacuteder Cada nodo tiene un tiempo de espera aleatoriodespueacutes del cual si no es informado por un liacuteder pasa a estado candidato y pideel ldquovotordquo al resto de los participantes El algoritmo divide el tiempo en plazos uncandidato pasa a liacuteder si recibe la mayoriacutea de los votos en un plazo determinadoSe define mayoriacutea o cuoacuterum (quorum) comolceil
N2rceil
+ 1 (1)
donde N representa el nuacutemero de nodos
Para el ejemplo propuesto de 5 equipos se requieren de 3 votos Soacutelo losnodos que se encuentren en estado seguidor pueden votar una uacutenica vez a laprimera solicitud que reciba dentro de un plazo
Supoacutengase que el nodo denotado con S1 ha cumplido su tiempo de espera yrealiza la peticioacuten de voto (figura 12) A partir de este momento se pueden dartres casos
La maacutequina gana la eleccioacuten y pasa a ser liacuteder informando al resto
Otro servidor se establece como liacuteder en el mismo momento
Varios nodos pasan a ser candidatos por lo que ninguno consigue los votos
21
Figura 12 Un equipo pasa a estado candidato (RAFT)
Si un candidato recibe un aviso de un liacuteder en el mismo plazo el primeropasa a ser seguidor y se acaba la eleccioacuten de liacuteder
Por otro lado si un equipo candidato no recibe los votos en el plazo y agotasu tiempo de espera avanza al siguiente plazo y repite el proceso de votacioacutenLa tercera posibilidad puede conllevar a un estado indefinido ya que varioscandidatos pueden agotar su tiempo de espera al mismo tiempo y repartir losvotos Para solventarlo el algoritmo establece tiempos de espera aleatorios paralos candidatos
Siguiendo con el ejemplo propuesto el servidor S1 pasa a ser el liacuteder Cadacierto tiempo eacuteste debe realizar avisos a los nodos seguidores para no agotar sutiempo de espera
En este momento el cluster de servidores estaacute en ldquoconsensordquo y la informacioacutenen todos los nodos estaacute actualizada Un cambio en la informacioacuten inicia unproceso de replicacioacuten el liacuteder registra el cambio lo pasa al resto de nodos yuna vez eacutestos responden el cambio se hace efectivo
Supoacutengase que se realiza un cambio en los datos en la figura 13 en la partederecha se observa el cambio en el registro del servidor S1 que informa a losnodos seguidores En consecuencia los nodos registran el cambio y responden aS1
Figura 13 Cambio en un registro (RAFT)
Una vez el cuoacuterum (en el ejemplo tres equipos) informa al liacuteder de que
22
ha registrado el cambio el liacuteder lo hace efectivo en su sistema y notifica a losnodos que hacen lo mismo En la figura 14 el enviacuteo todaviacutea no ha llegado ala maacutequina S3 y se observa que no ha hecho efectivo el cambio (en el registroaparece punteado)
Figura 14 Aprobacioacuten del resto de equipos (RAFT)
Este protocolo funcionaraacute correctamente mientras exista un nuacutemero de nodosen funcionamiento igual o superior al cuoacuterum en el ejemplo propuesto elcuoacuterum es tres por lo que el sistema puede tolerar la caiacuteda de dos de los equipos
522 Protocolo gossip SWIM
Nomad permite la gestioacuten simultaacutenea de varios centros de datos reparti-dos en regiones geograacuteficamente separadas requiriendo de un protocolo ligeroque mantenga a los miembros actualizados sobre los participantes del conjun-to Para ello usa una ligera variante del protocolo SWIM[3] (Scalable Weakly-consistent Infection-style Process Group Membership Protocol) desarrollada porHashiCorp Estaacute clasificado como un protocolo de tipo gossip que debe su nom-bre a la semejanza con coacutemo se distribuye un rumor en una red social
SWIM se sustenta en dos caracteriacutesticas fundamentales la deteccioacuten de fallosy la distribucioacuten de la informacioacuten relativa a los miembros A continuacioacuten sedetalla el funcionamiento de ambos componentes
Deteccioacuten de fallos
Este componente tiene dos paraacutemetros el periodo de protocolo T y el nuacutemerode subgrupos de deteccioacuten de fallos k en los que se dividen los nodos Paracomprobar la comunicacioacuten entre dos maacutequinas usa la utilidad ping basadaen el protocolo ICMP La deteccioacuten de caiacuteda de un servidor sigue el siguientealgoritmo
Durante el periodo T cada miembro Mi de un subgrupo elige otro al azar Mjdel mismo subgrupo y le enviacutea un mensaje ping para comprobar su estado Enel caso de que se cumpla un tiempo de espera determinado por una estimacioacuten
23
del tiempo de ida y vuelta (RTT por sus siglas en ingleacutes) de la red y no hayarespuesta Mi le vuelve a enviar un mensaje ping indirectamente a traveacutes deun nuacutemero k de miembros escogidos aleatoriamente De no recibir ninguna res-puesta Mi establece que Mj ha sufrido un fallo y lo etiqueta como ldquosospechosordquoinformando al componente de distribucioacuten
Figura 15 Diagrama de tiempo del protocolo SWIMFuente httpswwwcscornelledu
Componente de distribucioacuten
Se encarga de informar de cualquier cambio en los miembros a todo el con-junto Los eventos de nodo caiacutedo y la unioacuten o disociacioacuten de un miembro setransmiten a todos los servidores para que actualicen sus lista Para distribuirla informacioacuten a todos los nodos se podriacutea usar el meacutetodo de multicast perosuele estar deshabilitado Por ello se utiliza una teacutecnica de transmisioacuten denomi-nada Piggybacking mediante la cual se adjunta a los propios mensajes PINGy ACK del algoritmo la informacioacuten a distribuir reduciendo asiacute la congestioacutenen la red
523 Planificacioacuten
Proceso encargado de distribuir las tareas entre los nodos clientes de acuerdoa su estado
El planificador de Nomad estaacute basado en las publicaciones de Google sobresus herramientas de gestioacuten de clusters Borg y Omega14 y entiende los trabajosdescritos por el usuario como un estado deseado es decir su despliegue en unamaacutequina cliente de forma correcta y los clientes como el estado actual esto eslo que se encuentra en ejecucioacuten El registro actualizacioacuten o cancelacioacuten de un
14httpresearchgooglecompubspub43438html
24
trabajo asiacute como el fallo de un nodo cliente implican un cambio de estado atramitar por el sistema lo que se define como evaluacioacuten (evaluation) Esto uacutelti-mo supone comparar el estado actual (clientes) con el estado deseado (conjuntode trabajos registrados) y enviarlos a los planificadores correspondientes que seencargaraacuten de asignar las tareas a los nodos clientes
Figura 16 Procedimiento de asignacioacuten en NomadFuente httpswwwnomadprojectio
En la figura 16 se observa el flujo de trabajo en el que las distintas evalua-ciones se encolan en el evaluation broker que se ejecuta en el servidor liacuteder ygestiona las evaluaciones pendientes asignaacutendoles prioridades
A continuacioacuten los nodos servidores ejecutan los scheduling workers queprocesan las evaluaciones llamando a los distintos planificadores que generanun plan de asignacioacuten esto es un conjunto de relaciones entre las tareas y losnodos clientes donde se ejecutaraacuten Este proceso se divide en dos fases primerose descartan aquellos clientes que no cumplan los requisitos y posteriormentese asigna una calificacioacuten al resto Se selecciona el nodo con mayor puntuacioacuteny se encola el plan en el gestor que se ejecuta en el servidor liacuteder Existen tresplanificadores de acuerdo al tipo de trabajo
Service Incluye aquellos trabajos que estaacuten destinados a ejecutarse en un pe-riacuteodo largo de tiempo Para realizar las asignaciones el planificador evaluacuteala mayor parte de los nodos y usa una versioacuten del algoritmo Best fit in-fluenciada por el trabajo de Google en su herramienta Borg Se trata deun algoritmo de planificacioacuten que sacrifica tiempo a cambio de maximizarel rendimiento de los clientes asignando la tarea a la maacutequina que tengala mayor carga de trabajo con el objetivo de reducir equipos en funciona-
25
miento
Batch Tareas que incluyen listas de comandos en general de menor duracioacuteny que no requieren interaccioacuten con el usuario Se vale del algoritmo deSparrow desarrollado por la universidad de Berkeley15 para limitar losnodos clientes a evaluar
System Trabajos destinados a ejecutarse en todos los nodos incluso los que seunen al cluster posteriormente
Core Mantenimiento interno de Nomad
Una vez se ha realizado el proceso de planificacioacuten el nodo liacuteder lo registra enla cola de planes (plan queue) que se encarga de asignarles prioridad y manejarcondiciones de carrera es decir que no accedan a los recursos de los clientes sincontrol y evitar que eacutestos superen su capacidad
La maacutequina liacuteder del conjunto puede de este modo aceptar una asignacioacuteny ser ejecutada por los clientes o por el contrario rechazaacutersela al planificadorlo que implicariacutea realizar un plan parcial o totalmente nuevo
Finalmente el estado de las evaluaciones se actualizan y los clientes soninformados de las asignaciones ejecutaacutendose las tareas
15httppeopleeecsberkeleyedu~keopublicationssosp13-final17pdf
26
6 Casos de uso y despliegue
Con el objetivo de mostrar las posibles utilidades que este tipo de sistemaspueden tener en las infraestructuras TI actuales se han desplegado las dos he-rramientas en la nube Microsoft Azure usando su servicio cloud de instancias demaacutequinas virtuales Linux para simular un conjunto de ordenadores conectadosentre siacute por una red LAN Sobre ellas se ha implementado dos casos de usouna aplicacioacuten web con una arquitectura con cierta orientacioacuten a microserviciosy un sistema de integracioacuten continua
El coacutedigo y todos los ficheros de configuracioacuten se pueden encontrar en elrepositorio del proyecto en GitHub16
61 Aplicacioacuten Web
Se busca simular el proceso de adaptacioacuten de una solucioacuten web para su des-pliegue en un sistema distribuido con las herramientas anteriormente descritascon el objetivo de aumentar tanto su escalabilidad como disponibilidad medianteredundancia
Se ha partido de una aplicacioacuten ya existente17 un servicio de almacenamien-to y reproduccioacuten de canciones A grandes rasgos este servicio permite crearusuarios subir canciones con sus respectivas portadas tener playlists propias yescuchar las canciones a traveacutes de un navegador web
La solucioacuten estaacute dividida en 4 partes (figura 17)
Una vista web con la loacutegica
Un almacenamiento conectado en red (NAS por sus siglas en ingleacutes)
Una API REST para gestionar las peticiones al almacenamiento
Base de datos NoSQL basada en MongoDB
La nueva tendencia de los proyectos web es su implementacioacuten en contene-dores Docker ya que facilitan su portabilidad y ofrecen un procedimiento dedespliegue raacutepido sobre todo a la hora de desarrollar y realizar pruebas en en-tornos de produccioacuten simulados Por ello en este caso se va a hacer uso de los
16httpsgithubcomAntonioAlfrzCloud-Orchestrators17httpsgithubcomsonsoleslpCDPSfy
27
motores de orquestacioacuten de contenedores de ambas herramientas Marathon enDCOS y el controlador Docker en el caso de Nomad
Figura 17 Arquitectura aplicacioacuten web
A continuacioacuten vamos detallar el despliegue en ambas herramientas de es-ta solucioacuten y observar tanto queacute dificultades se encuentran como que ventajasofrecen El objetivo final es adaptar el proyecto modificaacutendolo lo menos posiblecon objeto de analizar la capacidad de estas herramientas para desplegar cual-quier aplicacioacuten sin que eso conlleve la modificacioacuten de la arquitectura de eacutestaes decir que no sea dependiente del entorno
611 DCOS
Se ha descrito DCOS como una herramienta que se despliega sobre un con-junto de ordenadores y que permite instalar gestionar el despliegue de sistemasdistribuidos
Microsoft Azure cuenta con una plantilla para desplegar en su servicio cloudun cluster de maacutequinas virtuales con DCOS ya instalado que cuenta con
Maacutequinas maestras (1 3 o 5 a seleccionar por el usuario) configuradascomo un conjunto de disponibilidad esto eso Azure da ciertas garantiacuteasde que al menos una maacutequina estaraacute en funcionamiento
Maacutequinas agentes Por motivos de seguridad se distinguen dos roles
bull Nodos privados solo accesibles desde la red interna y configuradoscomo un conjunto de escala un recurso de Azure para gestionar ydesplegar maacutequinas con configuraciones ideacutenticas para permitir unraacutepido escalado
bull Un equipo conectado accesible desde Internet a travntildees de un balan-ceador de carga puacuteblico y situado en una subred externa
28
Dos balanceadores de carga
bull La interfaz puacuteblica del cluster que se conecta con el cliente puacuteblicobull Acceso a los equipos maestros para el administrador que soacutelo permiteconexioacuten mediante SSH y credenciales
Almacenamiento para todas las maacutequinas
Configuraciones necesarias de red y seguridad
En la figura 18 se observa un diagrama de la infraestructura
Figura 18 Infraestructura en Azure
El primer obstaacuteculo es la persistencia de estado de la aplicacioacuten que seconsigue gracias a una base de datos no relacional basada en MongoDB asiacutecomo el almacenamiento de las canciones Para implementarla tenemos variasposibilidades
Montar un sistema externo de almacenamiento conectado en red en todoslos agentes donde se ejecuten las tareas de esta manera si una tarea pasade un nodo a otro por cualquier motivo puede tener acceso a los mismosficheros (opcioacuten del caso de uso original)
Implementar un sistema de ficheros distribuidos en los agentes
Usar los servicios de almacenamiento de las nubes puacuteblicas
Aprovechar el sistema de voluacutemenes persistentes de Apache Mesos Eacutestepermite reservar recursos de un agente de forma que al arrancar una tarease crea un volumen independiente del ciclo de vida de eacutesta con ello esosrecursos donde se ha almacenado la informacioacuten pueden volver a ofrecerseal mismo entorno de tal manera que otra tarea pueda acceder a ella
DCOS aprovecha este sistema de voluacutemenes persistentes y permite instalarbases de datos distribuidas como ArangoDB o Apache Cassandra sin embargoesto implicariacutea modificar todo el coacutedigo referente al modelo de la base de datos
29
Por motivos de eficiencia y latencia asiacute como de una mayor gobernabilidadde los datos la mejor opcioacuten es usar el recurso de voluacutemenes persistentes queofrece Apache Mesos ya que de esta manera se gestionariacutea la aplicacioacuten completamediante una uacutenica herramienta Sin embargo esto implica que la informacioacutense encuentra exclusivamente en el agente donde se haya ejecutado la tarea y porlo tanto se sigue requiriendo de software externo para distribuir la informacioacutenpara que se accesible para todos los agentes A la hora de realizar este proyectose encontraba en desarrollo Flocker una solucioacuten desarrollada por ClusterHQque permite compartir los voluacutemenes de Docker a traveacutes de un cluster quesi bien es compatible con el planificador de Mesos el proyecto se encontrabatodaviacutea en fases tempranas de desarrollo y los sistemas de almacenamiento quesoporta quedaban fuera del aacutembito de este trabajo
Por todo ello dado que las maacutequinas se han desplegado en la nube puacuteblicade Azure se decidioacute usar su servicio de almacenamiento de objetos para lascanciones y otra maacutequina para desplegar MongoDB y asiacute mantener el modelode datos original de la aplicacioacuten La diferencia del almacenamiento de obje-tos con respecto a nivel de fichero es que el primero no tiene jerarquiacutea paraorganizar los archivos eacutestos se guardan como objetos (con sus metadatos) enun mismo espacio soacutelo diferenciaacutendose por un identificador uacutenico esto implicaentre otras cosas que se puede acceder a un fichero dado uacutenicamente su IDindependientemente de la localizacioacuten fiacutesica de eacuteste facilitando pues la gestioacuteny el desarrollo
El coacutedigo del proyecto se ha modificado en los siguientes apartados
Las direcciones de la base de datos y los balanceadores de carga asiacute comosus puertos estaban originalmente fijos Se han configurado como variablesde entorno para facilitar el descubrimiento del servicio y hacer transpa-rente la aplicacioacuten al entorno de despliegue
La API REST se ha adaptado al almacenamiento en Azure en vez de enlocal
Estas modificaciones no suponen un cambio sustancial pero permiten separala persistencia de las tareas ejecutadas por DCOS lo que facilita en granmedida su ejecucioacuten al ser totalmente sin estado y ademaacutes implican tenerlos datos bajo un mayor control
Para la orquestacioacuten de contenedores se va a usar el entorno Marathondesarrollado tambieacuten por Mesosphere Eacuteste se puede usar a traveacutes de una interfazgraacutefica la interfaz de liacutenea de comandos (en lo que sigue CLI por sus siglas eningleacutes) de DCOS o con su API HTTP
Primero se han publicado la imaacutegenes de los contenedores que encapsulanla interfaz web y la api de la aplicacioacuten en el repositorio puacuteblico DockerHub
Los despliegues en este entorno se describen mediante ficheros JSON en losque se detalla entre otras opciones la imagen del contenedor los puertos a usar
30
los recursos que debe ocupar en un nodo o las instrucciones de monitorizacioacuten
Para el servicio de descubrimiento DCOS ofrece la posibilidad de asignardirecciones IP virtuales (VIP por sus siglas en ingleacutes) a tareas que se compartenen todos los nodos DCOS lleva integrado un balanceador de carga a nivel TCP(el componente denominado Minuteman) que balancea entre las direccionesvirtuales de las tareas y todas las instancias de eacutestas a lo largo del cluster Estoes necesario por dos motivos equilibrar la carga de los equipos con el fin deevitar un punto de uacutenico fallo mediante redundancia y evitar la contienda dedirecciones al ejecutar las tareas en puertos aleatorios
Este balanceador de carga estaacute basado en el trabajo de Michael Mitzenma-cher The Power of Two Choices in Randomized Load Balancing18 A grandesrasgos el algoritmo mantiene una media moacutevil exponencial de latencias paracada destino (backend) ademaacutes de las caiacutedas consecutivas Si un destino noresponde a una negociacioacuten en tres pasos (three way handshake) de forma con-secutiva en un periodo inferior a 5 ms se considera caiacutedo El algoritmo iterasobre los destinos disponibles en base a su histoacuterico de fallos y escoge dos deforma aleatoria de los cuales coge el de mejor meacutetrica
Las direcciones virtuales soacutelo se pueden resolver dentro del cluster porello para implementar la interfaz puacuteblica de la aplicacioacuten esto es el balancea-dor de carga de la interfaz web usaremos un paquete de DCOS denominadomarathon-lb un balanceador basado en HAProxy y adaptado por MesosphereEn este caso equilibra la carga de todas instancias de las tareas ejecutadas porel entorno Marathon por sus etiquetas y permite ademaacutes definir como puntode entrada muacuteltiples hosts virtuales definidos por sus nombres completos dedominio (FQDN por sus siglas en ingleacutes) en nuestro caso la interfaz puacuteblicadel balanceador de Azure para los agentes
Por motivos de seguridad todas las tareas se ejecutan en los agentes privadoses decir los que son exclusivamente accesibles desde la red interna Por su partemarathon-lb se ejecuta en el agente puacuteblico que cuenta con IP puacuteblica y lospuertos 80 (HTTP) y 8080 abiertos de forma que la aplicacioacuten sea accesibledesde Internet Esto es posible debido a que Apache Mesos permite reservarrecursos mediante roles asignados a nodos para un uso especiacutefico De esta formala arquitectura vista desde la aplicacioacuten quedariacutea como en la figura 19
18httpswwweecsharvardedu~michaelmpostscriptstpds2001pdf
31
Figura 19 Arquitectura de la aplicacioacuten web en DCOS
Ejecucioacuten
A la hora de desplegar la aplicacioacuten DCOS puede gestionarse medianteuna interfaz graacutefica o una interfaz de liacutenea de comandos La primera se accedea traveacutes de un navegador web en el puerto 80 (HTTP) y permite instalar losentornos disponibles observar el estado de los nodos y las tareas que se estaacutenejecutando y los ficheros de registros que eacutestas generan
La CLI permite el control desde un nodo o una maacutequina remota (suponiendoque los maestros tienen IP puacuteblica y el puerto 80 abierto) ya que DCOS tieneun sistema de autorizacioacuten que permite tener una interfaz puacuteblica con ciertasgarantiacuteas de seguridad
Por su parte cada entorno de trabajo puede ser controlado por la CLI peroademaacutes cuenta con sus propias interfaces Marathon expone una API HTTPen el puerto 8080 de la direccioacuten puacuteblica de los maestros del cluster asiacute comootra interfaz graacutefica Para desplegar un contenedor se podriacutea usar la CLI
$ dcos marathon app add lt f i l e j songt
O la API HTTP
$ cu r l minusX POST http lt ip_maestro gt8080v2apps minusd ltf i l e jsongt minusH Contentminustype app l i c a t i o n j son
32
612 Nomad
La arquitectura de Nomad es maacutes sencilla ya que solo requiere de un ficheroejecutable en todos los nodos para funcionar Si DCOS es la base de instala-cioacuten de entornos de terceros Nomad integra todas las funcionalidades baacutesicasesto es gestor de recursos planificador y ejecutor en los nodos cliente Estaherramienta cuenta con un menor tiempo de desarrollo y en el momento deescribir este documento cuenta exclusivamente con los siguientes controladoresen comparacioacuten con los entornos de DCOS
Motor Docker es decir funcioacuten de orquestacioacuten de contenedores
Ejecucioacuten de archivos binarios como comandos de Shell
Ejecucioacuten de aplicaciones Java
Virtualizacioacuten de maacutequinas mediante tecnologiacutea QEMU
Todos ellos necesitan que la tecnologiacutea subyacente esteacute instalada en las maacute-quinas clientes (Docker Java QEMU) Actualmente no permite el registro decontroladores por parte de terceros aunque estaacute planificado en un futuro ofreceruna interfaz para su desarrollo
Nomad no cuenta con el servicio de descubrimiento sin embargo puede inte-grarse con la herramienta Consul desarrollada por la misma empresa Por otrolado para el balanceo de carga usaremos un contenedor Docker con HAProxyuna herramienta de coacutedigo abierto que ofrece tanto servicios de proxy como debalanceador y cuyos ficheros de configuracioacuten completaremos con el proyectoConsul Template19
Consul
Consul sigue la misma arquitectura que Nomad es decir un nodo servidorque orquesta un conjunto de maacutequinas clientes y permite a los procesos que seejecutan en los equipos definirlos como servicios ofreciendo diversas caracteriacutes-ticas entorno a estos de los cuales vamos a usar dos
Descubrimiento de servicio Las maacutequinas clientes publican en el cataacutelogode servicios las tareas en ejecucioacuten y Consul les asigna nombres de dominioaccesibles por todos los miembros del cluster a traveacutes de la interfaz DNSincluida en esta herramientaConsul se integra con Nomad de forma que todas las tareas que se ejecu-ten en la segunda son automaacuteticamente publicados como servicios de laprimera de esta manera no hace falta conocer la direccioacuten de la maacutequinacliente donde se esteacute ejecutando el proceso ya que se puede acceder a eacutela traveacutes de su nombre de dominio de forma transparente Por ejemplo si
19[httpsgithubcomhashicorpconsul-template]
33
ejecutamos una tarea con ID web en el puerto 8080 se puede acceder aella en la direccioacuten webserviceconsul8080Para que las direcciones propias de Consul las resuelva su propio DNS y noel que esteacute asignado por defecto en la maacutequina usaremos la herramientadnsmasq20 que permite especificar la direccioacuten de un servidor DNS paraconsultas de direcciones especiacuteficas
Monitorizacioacuten Permite realizar comprobaciones del servicio y seguir su esta-do Aprovecharemos esta funcionalidad tanto para definir el propio procesode Nomad como servicio de Consul como las tareas desplegadas
HAProxy + Consul Template
HAProxy es una solucioacuten versaacutetil de coacutedigo abierto que ofrece solucionesde balanceo de carga y proxy Existen otras herramientas en el mercado comoNGINX o ldirectord sin embargo HAProxy suponiacutea una solucioacuten sencilla deconfigurar para mostrar el caso de uso
El uso de estas herramientas se debe a dos motivos para que no existacontienda con respecto a los puertos de los clientes usados por las tareas eacutestos sevan a asignar de forma dinaacutemica lo que en principio implicariacutea que la aplicacioacutendeberiacutea realizar consultas DNS de tipo SRV (que incluye puertos) a la interfazde Consul y balancear la carga entre tareas por redundancia y capacidad
Como la direccioacuten IP y puerto son variables cada vez que las tareas seactualicen o se reasignen es necesario volver a configurar HAProxy de formamanual Por ello HashiCorp ha desarrollado un programa denominado Con-sul Template que realiza peticiones sucesivas a la interfaz HTTP de Consul delas direcciones fiacutesicas de un servicio y reinicia automaacuteticamente el proceso deHAProxy Asiacute definiendo estas tareas como servicios Consul podremos tantomonitorizarlas como escalar las tareas dinaacutemicamente sin necesidad de cambiarel balanceador A partir del contenedor Docker oficial de HAProxy se ha desa-rrollado otro con la configuracioacuten baacutesica y con Consul Template para desplegarlocomo una tarea en Nomad
Despliegue
Se ha usado el mismo coacutedigo que en el apartado anterior con la persistenciaen el servicio de almacenamiento de Azure Desde la perspectiva del hardwarese implementaraacute la misma infraestructura que en el caso de DCOS (figura 18)estos es definiremos dos tipos de maacutequinas clientes un agente que se conectaraacutecon el balanceador de carga con nombre de dominio puacuteblico y donde se desple-garaacute el balanceador de carga de la vista web y agentes privados no accesiblesdesde fuera del cluster y donde se ejecutaraacuten el resto de tareas en la red inter-na La principal diferencia radica en las tareas que ejecutan HAproxy y ConsulTemplate que sustituye a las direcciones IP virtuales que ofrece DCOS
20httpwwwthekelleysorgukdnsmasqdochtml
34
Figura 20 Despliegue en Azure de Nomad+Consul
Cabe matizar que los balanceadores basados en HAProxy se implementanpor necesidad de la aplicacioacuten para el descubrimiento del servicio a diferenciade los de Azure que se implementan por motivos de seguridad y escalabilidaddel cluster en siacute
Configuracioacuten Nomad
Los ficheros de configuracioacuten de las maacutequinas maacutester y cliente son similaresy comparten la mayoriacutea de las opciones como por ejemplo el nombre del nodoo la interfaz de red donde escucha Nomad las peticiones Sus opciones son engeneral auto-explicativas sin embargo existen dos detalles que matizar
El proceso de Nomad escucha las peticiones tanto de los protocolos deconsenso como del usuario a traveacutes de una interfaz de red que se debeindicar en el fichero de configuracioacuten
En el caso de los clientes se deben indicar las direcciones de los servidoresdel cluster sin embargo se trata de un sistema dinaacutemico en el que losnodos pueden sufrir errores y cambiar de direccioacuten Por ello se ha definidoNomad como un servicio de Consul y asiacute poder definir la direccioacuten de losservidores como un nombre de dominio no por su direccioacuten fiacutesica que elservidor DNS de Consul se encargaraacute de resolver
Por defecto Nomad usa los siguientes puertos
API HTTP 4646 Peticiones HTTP y recepcioacuten de oacuterdenes mediante laliacutenea de comandos
RPC 4647 Protocolo de consenso entre los nodos del cluster
Serf 4648 Protocolo de gossip entre los servidores de los centros de datosgobernados por Nomad
35
Los dos uacuteltimos deben ser interfaces alcanzables por otros nodos sin embargo laAPI HTTP por motivos de seguridad deberiacutea ser local ya que en caso contrariocualquier persona con acceso a ella tiene el control sobre la herramienta Eacutestasolo deberiacutea estar accesible en un servidor o gestionarlo mediante una terminalSSH por ejemplo En este trabajo al ser una prueba de concepto se ha abiertoen todos los nodos
Trabajos de Nomad
Las tareas se detallan en ficheros con formato HashiCorp Configuration Lan-guage un derivado del formato JSON creado por la empresa que le da nombrecompatible con eacuteste y que permite comentarios
En estos ficheros se puede definir
La regioacuten y el centro de datos donde se ejecutaraacute (Nomad permite lagestioacuten de centros de datos geograacuteficamente distribuidos en regiones)
La poliacutetica de actualizacioacuten de la tarea
Grupo de tareas esto es que se ejecutaraacuten en el mismo nodo
El nuacutemero de grupos a ejecutarescalar asiacute como los liacutemite que debencumplir los nodos asignados
La poliacutetica de reinicio ante fallo o error
Tareas El controlador su configuracioacuten los paraacutemetros del servicio aso-ciado a registrar en Consul asiacute como los recursos que consume (puertosmemoria)
En nuestro caso usamos sobre todo el controlador Docker esto eso orques-tacioacuten de contenedores en los nodos clientes y tres de sus opciones
Imagen del contenedor Se han subido todas las imaacutegenes del proyecto a Doc-ker Hub donde por defecto se busca la imagen
Puertos Los puertos a usar por el contenedor que pueden ser estaacuteticos asigna-dos por el usuario o dinaacutemicos siendo Nomad el que se encarga de mapearun puerto libre del nodo cliente al expuesto por el contenedor
Servidores DNS Como usamos la interfaz DNS de Consul como descubri-miento de servicio se debe configurar el contenedor para que use cualquiernodo del cluster como servidor DNS
Configuracioacuten Consul
Al ser desarrolladas por la misma empresa los ficheros de configuracioacuten deConsul y Nomad comparten muchas opciones Consul tambieacuten acepta peticionesa traveacutes de una interfaz de red siendo los puertos usados por defecto
36
RPC 8300 8400 Maneja la peticiones del resto de nodos y usuarios
Serf 8301 8302 Protocolo gossip
HTTP API 8500
HTTPS API Desactivada por defecto
Interfaz DNS 8600
Se debe asignar a los protocolos internos del cluster esto es RPC y Serf unainterfaz alcanzable por los nodos y por el contrarioasignar a los dos uacuteltimos ala interfaz de loopback por motivos de seguridad
Cabe destacar que Consul tambieacuten cuenta con una interfaz graacutefica que per-mite ver el estado de los equipos y los servicios registrados y que se encuentra enel mismo puerto que la API HTTP en la direccioacuten httpIP_EQUIPO8500ui
Ejecucioacuten
Tanto Nomad como Consul requieren de la ejecucioacuten de un fichero en todoslos nodos integrantes del cluster Como prueba de concepto se ha decidido usardos servidores para ambos aunque cabe matizar que es un nuacutemero ineficienteya que la caiacuteda de uno de ellos supondriacutea la peacuterdida del cuoacuterum y por tantodel consenso del cluster
En primer lugar se arrancan los servidores que son los encargados de ejecu-tar el protocolo de consenso y gestionar el cluster y a continuacioacuten los clientesque no tienen praacutecticamente estado y dependen de los servidores
En el caso de Consul se debe indicar el directorio donde se guardan losficheros que describen los servicios asiacute como el archivo que especifica el resto delas opciones
1 Se inicia el primer servidor en uno de los equipos
$ consu l agent minuscon f i gminusd i r e t c consu l d s e r v i c e s minuscon f i gminus f i l e consu l_server j son
2 Los siguientes equipos deben unirse al anterior por lo que antildeadimos elargumento join con la direccioacuten del primer servidor Para el caso de otrosservidores
$ consu l agent minuscon f i gminusd i r e t c consu l d s e r v i c e s minuscon f i gminus f i l e consu l_server j son minus j o i n ltIP_servidor1gt
37
Una vez los servidores han alcanzado el consenso y elegido un liacuteder en losclientes
$ consu l agent minuscon f i gminusd i r e t c consu l d s e r v i c e s minuscon f i gminus f i l e c on su l_c l i en t j son minus j o i n ltIP_cualquierServ idorgt
El proceso para iniciar Nomad es igual y los comandos similares sin embargoya no es necesario indicar una direccioacuten IP fija en los equipos sino el nombre dedominio del servicio de Nomad registrado por Consul En el primer servidor
$ nomad agent minusc on f i g nomad_server j son
Y el resto de equipos (con su fichero de configuracioacuten correspondiente)$ nomad agent minusc on f i g nomad_server j son minus j o i n nomad s e r v i c e consu l
Por uacuteltimo para desplegar la aplicacioacuten web se han escrito tres ficherosque detallan las tareas de la interfaz web API y los balanceadores de cargaMediante la CLI
$ nomad run minusaddress=http lt ip_c lus te r gt4646 lt f i l e hclgt
O mediante la API HTTP de Nomad$ cu r l minusX POST minusd ltf i l e hclgthttp lt ip_c lus te r gt4646 jobltjob_namegt
Ansible
Como se puede comprobar con el aumento del nuacutemero de equipos pasa aser inviable manejar todos los nodos a traveacutes de terminal Ademaacutes como seha comentado con anterioridad Nomad requiere que en los nodos clientes es-teacuten instalados las herramientas que soporten las tareas por ejemplo el motorde Docker Por ello para facilitar tanto el arranque como la instalacioacuten de lasdependencias vamos a usar Ansible una herramienta de coacutedigo abierto desarro-llada en Python que permite gestionar configuraciones aprovisionar recursosdespliegue de aplicaciones de forma automaacutetica
A grandes rasgos esta herramienta funciona mediante ficheros en formatoYAML denominados play-books que describen un conjunto de pasos a ejecutaren una lista de equipos remotos Estos pasos son ejecutados por moacutedulos inde-pendientes a traveacutes de SSH es decir en cualquier ordenador con conexioacuten a los
38
hosts dado su contrasentildea o clave puacuteblica puede arrancar el script y realizariacutealos pasos de forma remota gestionando el cluster desde un solo equipo
Se han desarrollado guiones para lo siguiente
Descarga de los binarios de Nomad y Consul en todos los nodos copiade los ficheros de configuracioacuten baacutesicos y modificarlos de acuerdo a cadanodo (nombre del equipo direccioacuten IP)
Instalacioacuten de las dependencias
Arranque de Nomad y Consul
Ansible extiende su funcionalidad a traveacutes de moacutedulos independientes que per-miten por ejemplo instalar paquetes mediante herramientas de gestioacuten de pa-quetes (APT yum) aprovisionar automaacuteticamente maacutequinas virtuales de Ama-zon EC2
Algunas opciones de los ficheros de configuracioacuten de Nomad y Consul sondependientes del nodo particular por ejemplo la interfaz de red Para estetrabajo se ha realizado un moacutedulo para modificar los ficheros de configuracioacutende forma automaacutetica En el repositorio del proyecto se encuentra una carpetadonde se encuentran todos los ficheros necesarios para desplegar un clustertotalmente funcional solo requiere de una liacutenea de terminal con Ansible
$ ans ib l eminusplaybook minus i hos t s minusk ltssh_passgt minusu ltnode_usergt s i t e yml
39
62 Servicio de integracioacuten continua
Se ha implementado un sistema de integracioacuten continua que permite ejecu-tar tareas de compilacioacuten y pruebas de forma distribuida aumentando asiacute elrendimiento de los equipos En primer lugar se detallaraacute los motivos por los quepuede resultar beneficioso para las empresas una implementacioacuten de este tipo alo que seguiraacute los detalles del despliegue
621 DevOps
Metodologiacutea que defiende la comunicacioacuten y colaboracioacuten entre desarrolla-dores de software y los profesionales de operaciones a lo largo de todo el ciclo devida de una aplicacioacuten Estaacute muy relacionado con el desarrollo aacutegil de softwareesto es un enfoque para los proyectos que defiende el desarrollo iterativo e in-cremental donde los requisitos y soluciones evolucionan con el tiempo seguacuten lanecesidad del proyecto DevOps extiende esta filosofiacutea a todas los componentesde un servicio incluyendo sistemas y operaciones
Se trata de un concepto que cada organizacioacuten o empresa adapta a suspropias necesidades y procesos de negocio en este proyecto nos vamos a centraren la integracioacuten continua una praacutectica fundamental tanto del desarrollo aacutegilcomo de esta filosofiacutea
622 Integracioacuten Continua
Se define como una praacutectica de desarrollo software donde los miembros delequipo ponen en comuacuten su trabajo frecuentemente al menos una vez al diacutea21Cada integracioacuten se verifica con una compilacioacuten automaacutetica que incluye laejecucioacuten de pruebas para detectar errores de integracioacuten tan pronto como seaposible
Desde el punto de vista operativo esto supone automatizar la configuracioacutende equipos o el despliegue de maacutequinas virtuales donde compilar el proyecto yejecutar las pruebas y posteriormente eliminarlas Este flujo de trabajo se vebeneficiado en entornos distribuidos ya que el objetivo del desarrollador es com-probar el resultado de las pruebas raacutepidamente sin preocuparse del despliegueo los propios equipos
Para esta prueba de concepto vamos a usar Jenkins un servidor de integra-cioacuten continua escrito en Java que nos permite definir trabajos que contendraacutenla descripcioacuten tanto del entorno como su ejecucioacuten
Este sigue una estructura maestro-esclavo muy similar al de los gestores declusters usados en este proyecto el maestro contiene toda la loacutegica del servicio
21httpmartinfowlercomarticlescontinuousIntegrationhtml
40
trabajos autenticacioacuten y los esclavos son los encargados de la ejecucioacuten ensiacute Jenkins tiene varias viacuteas para aprovisionar los uacuteltimos
Mediante SSH
Interfaz graacutefica
Desarrollar un script propio
Ejecucioacuten de un fichero java
La ventaja de usar planificadores es que el despliegue de esclavos es dinaacutemicoes decir no tener una maacutequina especiacuteficamente configurada para ello DCOS yNomad se encargaraacuten de configurar estos despliegues en sus maacutequinas y poste-riormente eliminarlos Para ello se ha usado la uacuteltima opcioacuten definiendo tareasque descarguen el fichero java Con todo ello se consigue un entorno de inte-gracioacuten continua eficiente que ademaacutes permite la ejecucioacuten de otros servicios deforma independiente
Jenkins permite la creacioacuten de plugins que extienden sus funcionalidadesTanto Nomad22 como Apache Mesos cuentan con uno que permite su integra-cioacuten
Para esta prueba se va a usar el mismo proyecto que para el caso de usode orquestacioacuten de contenedores la aplicacioacuten web al que se le ha antildeadido untest para comprobar que se conecta correctamente a la base de datos medianteMocha un framework de Nodejs Por otro lado se antildeade el plugin de git ya queel coacutedigo se obtiene de GitHub el repositorio remoto de control de versiones delproyecto
El proceso general de ejecucioacuten seriacutea como sigue
1 Se ejecuta el maestro de Jenkins como tarea Docker partiendo de la imagenoficial
2 Al arrancar un trabajo se manda una tarea a los planificadores que laasignaraacuten a un nodo cliente Esta tarea consiste en la descarga del ficherode configuracioacuten Java y arrancarlo configurando el equipo como un clientede Jenkins temporalmente
3 Jenkins ejecuta el trabajo en el nuevo cliente en este caso iniciar la apli-cacioacuten web iniciar las pruebas y generar un informe
4 Se elimina el cliente
A continuacioacuten se detallan los matices de cada herramienta a la hora de imple-mentar este servicio
22Desarrollado por Ivo Verberk httpwwwivoverberknl
41
623 Jenkins con Nomad
El plugin permite la ejecucioacuten del fichero Java mediante dos controladorescontenedores Docker y Java En este proyecto nos hemos decantado por el pri-mero ya que nos ahorra instalar la maacutequina virtual de java en todos los nodoscliente Por ello se ha construido un contenedor base con Java para la ejecucioacutendel fichero de configuracioacuten y Nodejs para lanzar la aplicacioacuten web
El plugin se configura con la direccioacuten IP del cluster y el contenedor queejecuta el esclavo Jenkins Por su parte el trabajo en Jenkins se define conel repositorio en GitHub donde se aloja el coacutedigo del proyecto a probar y loscomandos a ejecutar en este caso npm update y npm test
624 Jenkins con DCOS
En el caso de DCOS su sistema de paquetes incluye Jenkins por lo queal instalarlo ya se tiene la configuracioacuten de Mesos totalmente funcional Sinembargo para ejecutar la aplicacioacuten en particular y las pruebas se requiere deNodejs en los equipos esclavos por ello debemos antildeadir un plugin de Jenkinsque permite instalar este entorno antes de ejecutar el trabajo Una vez hechoesto soacutelo queda definir la tarea igual que en el caso anterior
Cabe destacar que Mesosphere tambieacuten ha desarrollado un plugin que per-mite hacer despliegues en Marathon de tal manera que permitiriacutea con cadacommit del coacutedigo compilar la imagen del contenedor Docker y desplegarlaautomaacuteticamente aunque en este proyecto no se ha hecho pruebas de esta fun-cionalidad
42
7 Escalando la infraestructura
Uno de los factores clave que se busca a la hora de implementar sistemasdistribuidos es el poder escalar la infraestructura de forma maacutes sencilla estoes detectar que las maacutequinas estaacuten alcanzando el liacutemite de su capacidad yaumentar eacutesta ya sea mejorando sus caracteriacutesticas teacutecnicas o antildeadiendo maacutesnodos al cluster
El coacutedigo y todos los ficheros de configuracioacuten de esta seccioacuten tambieacuten sepueden encontrar en el repositorio del proyecto en GitHub23
71 Disentildeo
Microsoft Azure permite organizar los servicios cloud de forma loacutegica a traveacutesde grupos de recursos y asiacute poder crear o eliminar eacutestos en conjunto parauna aplicacioacuten determinada (por ejemplo una aplicacioacuten web suele requerir demaacutequinas virtuales bases de datos almacenamiento) Ademaacutes dispone dela opcioacuten de crear plantillas en formato JSON que permite al desarrolladordefinir los recursos y su interrelacioacuten para desplegar de forma automaacutetica unainfraestructura TI en la nube
Azure tambieacuten ofrece la posibilidad de monitorizar el estado de las maacutequinasvirtuales a traveacutes de extensiones lo que permite configurar el escalado automaacute-tico al alcanzar cierto liacutemite definido por el operador Eacutesta es a priori la formaen que deberiacutea implementarse hablando en teacuterminos de eficiencia sin embargoesta aproximacioacuten es totalmente dependiente de la plataforma es decir no sepuede extrapolar a otro proveedor o sobre recursos propios sin realizar un nue-vo disentildeo En este proyecto las tareas que son ejecutadas por estos equipos notienen estado ya que todo lo relativo a la persistencia lo hemos asignado fueradel cluster esto permite escalar la plataforma a traveacutes de otra aproximaciones
Las plantillas aceptan una serie de variables a indicar por el usuario entreotras los conjuntos de escala para definir los nodos aceptan una variable quedefine el nuacutemero de maacutequinas que los componen Por otro lado Azure ofreceuna API REST y kits de desarrollo software (SDK por sus siglas en ingleacutes) quepermiten su despliegue de forma programaacutetica Aprovechando estas facilidadesen este proyecto se va a aproximar la escalabilidad con el sucesivo desplieguede la infraestructura de forma automaacutetica se monitorizan los equipos y si sedetecta una maacutequina excesivamente cargada se aumenta el nuacutemero de equiposen la plantilla y se vuelve a desplegar
23httpsgithubcomAntonioAlfrzCloud-Orchestrators
43
En este proyecto se han disentildeado las plantillas para desplegar la arquitec-tura necesaria tanto de Nomad como de DCOS En el caso de la primera eldespliegue es maacutes descriptivo ya que incluye maacutequinas virtuales grupos de se-guridad redes En el caso de DCOS Azure cuenta con un servicio especiacuteficopara clusters gobernados por DCOS denominado Azure Container Service queincluye los componentes necesarios y la instalacioacuten ya realizada
72 Implementacioacuten
En primer lugar para monitorizar el estado de los equipos se va a usar laherramienta Nagios un sistema que permite controlar el estado del hardwarey los servicios de un equipo Se trata de una herramienta muy completa de laque se va a usar su capacidad para ejecutar comandos (plugins) en los nodospara detectar picos de carga generar alertas y ejecutar programas para estoseventos
Se ha desplegado una maacutequina virtual con esta herramienta en ambos siste-mas y se ha instalado una extensioacuten de Nagios (Nagios Remote Plugin Executor)en todos los nodos que permite ejecutar comprobaciones remotamente en con-creto para esta prueba de concepto medir el nivel de saturacioacuten de la unidadcentral de procesamiento (CPU por sus siglas del ingleacutes) Cuando sucede uncambio de estado de una maacutequina esto es cuando este paraacutemetro supera el liacutemi-te definido por el operador Nagios permite actuar en consecuencia ejecutandoprogramas por ello se ha desarrollado un script que ejecuta lo siguiente
Un programa desarrollado en Python con el SDK de Azure que modificalas plantillas y despliega los recursos
Un guioacuten de Ansible para instalar todos los componentes necesarios en lasnuevas maacutequinas y arrancar de nuevo el cluster y las aplicaciones
44
8 Resultados y conclusiones
En este uacuteltimo apartado se da una visioacuten global del proyecto asiacute como a lasconclusiones maacutes importantes a las que se ha llegado y posibles temas futurosde desarrollo
81 Comparacioacuten
Ambas herramientas ofrecen las funcionalidades para gestionar los recursoseficientemente ofreciendo a los desarrolladores una plataforma donde desplegarsus aplicaciones de forma distribuida independientemente de los equipos fiacutesicosy el hardware que las soporten
DCOS es una herramienta que en un comienzo fue privativa pero cuyos res-ponsables la empresa Mesosphere decidieron publicar una versioacuten de coacutedigoEacutesta nos permite gestionar un cluster de una forma sencilla y usable ademaacutes decomplementarlo con otras herramientas como el balanceador de carga integradoo la autenticacioacuten de usuarios ademaacutes estaacute basada en Apache Mesos un pro-yecto de relativa madurez y con el soporte de la Apache Software FoundationDe forma resumida DCOS ofrece muchas posibilidades y servicios a cambiode una arquitectura e instalacioacuten maacutes compleja
Por su parte HashiCorp con menor tiempo de desarrollo ha conseguidouna herramienta muy sencilla de desplegar que ademaacutes cumple con todas lasfuncionalidades baacutesicas ejecutando un simple binario en cada nodo se puededesplegar un gestor de clusters totalmente funcional Sin embargo no cuentacon todas las posibilidades de Mesos (Nomad cuenta con menos controladoresque entornos posibles de Mesos) ni con los antildeadidos de DCOS lo que implicael uso de otras herramientas para complementar el servicio (Consul HAProxy)
De entre las dificultades encontradas al usar estas herramientas y desplegaraplicaciones sobre ellas se puede destacar la depuracioacuten en ocasiones se desco-noce si un error viene de la propia herramienta de la aplicacioacuten desplegada o delequipo fiacutesico si no se cuenta con un sistema de procesamiento de registro unose puede encontrar con muacuteltiples terminales abiertas inspeccionando numerososficheros de registro buscando posibles errores Ademaacutes no dejan de ser solucio-nes que para usar eficientemente se debe conocer parte de su funcionamientoy sintaxis a la hora de describir la tareas lo que supone un esfuerzo antildeadido yaque cada una tiene sus particularidades y liacutemites
45
82 Conclusiones
En una sociedad cada vez maacutes digital las empresas deben adaptarse a unmercado cuya demanda de contenido no deja de crecer Las nuevas arquitecturascomo microservicios asiacute como la gran cantidad de datos generada implica queuna mejor gestioacuten de los recursos y la rapidez para desplegar o escalar solucionesdando valor al cliente lo maacutes raacutepido posible es uno de los objetivos de todas lasempresas de base tecnoloacutegica
Las ventajas que ofrecen los planificadores con aplicaciones distribuidas sonnumerosas sin ir maacutes lejos empresas tan punteras como Google llevan maacutesde 10 antildeos orquestando contenedores24 Por un lado permiten aumentar elrendimiento de los equipos propios y por otro implementar un servicio comoplataforma para despliegues distribuidos sobre cualquier conjunto hardware deesta forma se provee un servicio similar al de la nube puacuteblica pero con laprincipal diferencia de que se elimina la independencia con el proveedor (vendorlock-in) esto es las aplicaciones no tienen limitaciones impuestas por eacuteste talescomo lenguaje de programacioacuten o herramientas y permite despliegues hiacutebridosentre recursos propios y la nube
83 Objetivos conseguidos
Implementacioacuten de los planificadores propuestos en la nube Se ha en-tendido y detallado el funcionamiento de estas herramientas y se hanimplementado en el servicio de infraestructura de Microsoft Azure
Despliegue de aplicaciones y servicios distribuidos Servicios que se usanactualmente en la industria del desarrollo software asiacute como una aplica-cioacuten web con una arquitectura moderna han sido desplegados de formadistribuida en los equipos cumpliendo con la funcionalidad esperada ade-maacutes de consiguiendo una alta disponibilidad
Aproximacioacuten de arquitectura escalable Se ha hecho una aproximacioacutende infraestructura escalable de forma que sea parcialmente extrapolable aotros proveedores
24httpwwwnextplatformcom20160322decade-container-control-google
46
84 Liacuteneas de investigacioacuten
Siguiendo con la materia de este proyecto se presentan posibles liacuteneas deinvestigacioacuten
Analizar el despliegue con estas herramientas de aplicaciones de Big Datay comparar la eficiencia con respecto a soluciones especializadas
Analizar el rendimiento de los algoritmos de planificacioacuten antes pruebasde estreacutes y situaciones de alta contienda
Comparar el uso de estas herramientas con las praacutecticas actuales de laindustria o implementacioacuten en un sistema de produccioacuten real
47
Referencias
[1] LA Barroso y U Houmllzle laquoThe Datacenter as a Computer An Introduc-tion to the Design of Warehouse-Scale Machinesraquo En Morgan amp ClaypoolPublishers ()
[2] Systems Research Group ndash NetOS (University of Cambridge) The evolu-tion of cluster scheduler architectures 2016 url httpswwwclcamacukresearchsrgnetoscamsasblog2016-03-09-scheduler-architectureshtml
[3] A Das I Gupta y A Motivala SWIM Scalable Weakly-consistent Infection-style Process Group Membership Protocol Inf teacutec Dept of ComputerScience Cornell University url https www cs cornell edu ~asdasresearchdsn02-swimpdf
[4] D Dubhashi y A Das Mastering Mesos PACKT Publishing mayo de2016
[5] The Apache Software Foundation Apache Mesos documentation urlhttpsmesosapacheorg
[6] David Greenberg Building Applications on Mesos OrsquoReilly Media 2016[7] Armand Grillet Comparison of Container Schedulers Inf teacutec Technische
Universitaumlt Berlin[8] HashiCorp Consul documentation url httpswwwconsulio[9] HashiCorp Nomad documentation url httpsdcosio[10] Dan C Marinescu Cloud computing theory and practice Morgan Kauf-
mann 2013[11] Mesosphere DCOS documentation url httpswwwnomadproject
io[12] Microsoft Azure documentation url httpsazuremicrosoftcom
es-esdocumentation[13] D Ongaro y J Ousterhout In Search of an Understandable Consensus
Algorithm Inf teacutec Stanford University url httpsraftgithubioraftpdf
[14] Fei Teng laquoRessource allocation and schelduling models for cloud compu-tingraquo Tesis de mtriacutea Ecole Centrale Paris 2011
[15] A Williams y col Automation and Orchestration with Docker and Contai-ners A Comprehensive Overview of the Docker and Container Ecosystem3 The New Stack 2016
48
- Resumen
- Summary
- Iacutendice de figuras
- Introduccioacuten y objetivos
-
- Contexto
- Objetivos
- Estructura del documento
-
- Cloud Computing
- Nuevas cargas de trabajo
- Gestioacuten de recursos Planificadores
-
- Sistemas distribuidos
-
- Clasificacioacuten
-
- Herramientas
-
- DCOS
-
- Apache Mesos
- Ejemplos de uso
-
- Nomad
-
- Protocolo de consenso Raft
- Protocolo gossip SWIM
- Planificacioacuten
-
- Casos de uso y despliegue
-
- Aplicacioacuten Web
-
- DCOS
- Nomad
-
- Servicio de integracioacuten continua
-
- DevOps
- Integracioacuten Continua
- Jenkins con Nomad
- Jenkins con DCOS
-
- Escalando la infraestructura
-
- Disentildeo
- Implementacioacuten
-
- Resultados y conclusiones
-
- Comparacioacuten
- Conclusiones
- Objetivos conseguidos
- Liacuteneas de investigacioacuten
-
y a queacute entorno de trabajo y enviacutea la oferta a los planificadores Eacutestos respondenal maestro con queacute recursos ha decidido usar para cada tarea Finalmente lastareas son enviadas al esclavo seleccionado el cual asigna los recursos indicadosal procesador (executor) quien finalmente las ejecuta
Cabriacutea pensar que esta metodologiacutea puede conducir a situaciones en lasque un entorno podriacutea quedarse con tareas sin ejecutarse a la espera de unaoferta satisfactoria para ello Mesos implementa un sistema de filtros medianteel cual los entornos especifican los requisitos miacutenimos que debe cumplir unaoferta por ejemplo se puede especificar en queacute nodos debe desplegarse la tareaEste sistema estaacute disentildeado asiacute con el objetivo de mantener lo maacutes transparenteposible esta herramientas de forma que acepte entornos de trabajo de distintasnaturalezas
512 Ejemplos de uso
Grandes empresas estaacuten usando Apache Mesos con eficacia de acuerdo a susnecesidades e infraestructuras Caben destacar
Ebay En el modelo de implementacioacuten continua en esta empresa10 cadadesarrollador cuenta con su propia instancia que se ejecuta en una maacutequinavirtual dedicada lo que ha conllevado un uso de los recursos poco eficiente Enuna prueba de concepto consiguieron realizar una herramienta de integracioacutencontinua distribuida basada en un cluster con Apache mesos y con el entornoMarathon y Jenkins
Apple Anuncioacute que el motor de su famosa herramienta de asistencia per-sonal para iPhones Siri estaacute desplegada sobre Apache Mesos11 Para ello handesarrollado su propio entorno para facilitar a los ingenieros a desplegar los ser-vicios que la herramienta necesita para resolver las peticiones de los usuarios
Twitter Desarrolloacute su propio entorno denominado Aurora y actualmentegestionan sus recursos y miden el coste de las tareas que los empleados usancon el objetivo de que sean conscientes del gasto que puede suponer un usoinadecuado de la infraestructura12
10httpwwwebaytechblogcom20140404delivering-ebays-ci-solution-with-apache-mesos-part-i11httpwwwbusinessinsidercomapple-siri-uses-apache-mesos-2015-812httpswwwlinuxcomNEWS4-UNIQUE-WAYS-UBER-TWITTER-PAYPAL-AND-HUBSPOT-USE-APACHE-MESOS
18
52 Nomad
Herramienta de coacutedigo abierto de gestioacuten de clusters creada y desarrolladapor Hashicorp13 que permite el despliegue de aplicaciones y procesos de formadistribuida
Las principales diferencias con Apache Mesos a grandes rasgos son
Arquitectura maacutes ligera Nomad soacutelo requiere de un fichero para funcionarejecutaacutendolo con las correspondientes configuraciones en todos los nodosrealiza las funciones de gestioacuten del cluster eleccioacuten de liacuteder planificacioacutende recursos y ejecucioacuten de las tareas
Centro de datos y regiones muacuteltiples Su arquitectura estaacute orientada afacilitar la gestioacuten de diferentes centros de datos geograacuteficamente distri-buidos
Entorno de ejecucioacuten Las tareas se definen y son interpretadas mediantecontroladores integrados en Nomad que se valen de los recursos y herra-mientas de los nodos clientes para ejecutarlas Esta integracioacuten dificultael desarrollo de controladores por parte de terceros a diferencia de Mesosque delega dicha responsabilidad en los entornos de trabajo externos alproyecto
Usa un planificador de estado compartido con respecto a la planificacioacutenen dos niveles de Mesos
Antes de entrar en maacutes detalle en la arquitectura es importante definir lossiguientes teacuterminos
Controlador (Driver) Software que se encarga de interpretar las definicionesde las tareas y ejecutarlas semejante a los procesadores de los entornosde trabajo de Mesos A la hora de redactar este proyecto Nomad contabacon controladores para contenedores Docker virtualizacioacuten de maacutequinasmediante el emulador QEMU aplicaciones java y archivos binarios
Grupo de trabajo (Task Group) Conjunto de tareas que se ejecutan en elmismo nodo cliente
Trabajo (Job) Conjunto loacutegico de tareas y grupos de trabajo que se despliegana la vez
Asignacioacuten (Allocation) Relacioacuten entre un grupo de trabajo y el cliente don-de se ejecuta
Evaluacioacuten (Evaluation) Proceso mediante el cual Nomad planifica y ges-tiona el registro o actualizaciones de los trabajos
13httpswwwhashicorpcom
19
Nomad sigue una arquitectura maestro-esclavo similar a la de Apache Mesosmuacuteltiples servidores acuerdan entre siacute un liacuteder que gestiona la planificacioacuten detareas en los clientes que soacutelo conocen sus asignaciones y las ejecutan
Todos los servidores participan paralelamente en tareas de planificacioacuten derecursos y asignacioacuten de tareas y ademaacutes entre ellos eligen un liacuteder que seencarga de la coordinacioacuten de la suscripcioacuten de los clientes al cluster y de lagestioacuten de las peticiones
Los clientes estaacuten configurados para comunicarse con el servidor usando lla-madas a procedimiento remoto (RPC por sus siglas en ingleacutes) que permite unordenador ejecutar coacutedigo en otra maacutequina Mediante esta tecnologiacutea los nodosclientes avisan de su estado e informa de sus asignaciones recursos y controla-dores disponibles
Existe la posibilidad de gestionar varios centros de datos agrupados en regio-nes eacutestas son independientes pero permite definir tareas o comprobar el estadode todas ellas desde cualquier punto A continuacioacuten se muestra una figura dela arquitectura a alto nivel de esta configuracioacuten
Figura 10 Arquitectura multi-regioacuten en NomadFuente httpswwwnomadprojectio
La herramienta se sustenta sobre tres protocolos fundamentales un protocolode consenso entre los servidores para compartir informacioacuten sobre su estado yel liacuteder un protocolo Gossip para la gestioacuten entre regiones y el planificador detareas
521 Protocolo de consenso Raft
El objetivo es obtener consistencia en un conjunto de nodos que comparteninformacioacuten es decir si un cliente realiza un cambio que todos los nodos veanla misma informacioacuten a la vez y ademaacutes sea tolerante a fallos Para ello se basaen el algoritmo Raft[13] que se detalla brevemente a continuacioacuten
20
Los nodos participantes en el algoritmo pueden estar en tres estados
Liacuteder (Leader) Todos los cambios que realicen en el cluster pasan por eacutel pri-mero
Seguidor (Follower) Nodo pasivo cuya responsabilidad es responder a laspeticiones del nodo liacuteder
Candidato (Candidate) Maacutequina que no ha encontrado liacuteder y solicita sueleccioacuten
Supongamos que tenemos cinco equipos que acaban de arrancar el protocoloEn la figura 11 se observan los nodos y sus respectivos registros a la derecha
Figura 11 Equipos sin consenso ejecutando el protocolo RAFTFuente httpsgithubcomongardieraftscope
Al comenzar todos los nodos son seguidores esperando recibir comunicacioacutende un nodo que actuacutee como liacuteder Cada nodo tiene un tiempo de espera aleatoriodespueacutes del cual si no es informado por un liacuteder pasa a estado candidato y pideel ldquovotordquo al resto de los participantes El algoritmo divide el tiempo en plazos uncandidato pasa a liacuteder si recibe la mayoriacutea de los votos en un plazo determinadoSe define mayoriacutea o cuoacuterum (quorum) comolceil
N2rceil
+ 1 (1)
donde N representa el nuacutemero de nodos
Para el ejemplo propuesto de 5 equipos se requieren de 3 votos Soacutelo losnodos que se encuentren en estado seguidor pueden votar una uacutenica vez a laprimera solicitud que reciba dentro de un plazo
Supoacutengase que el nodo denotado con S1 ha cumplido su tiempo de espera yrealiza la peticioacuten de voto (figura 12) A partir de este momento se pueden dartres casos
La maacutequina gana la eleccioacuten y pasa a ser liacuteder informando al resto
Otro servidor se establece como liacuteder en el mismo momento
Varios nodos pasan a ser candidatos por lo que ninguno consigue los votos
21
Figura 12 Un equipo pasa a estado candidato (RAFT)
Si un candidato recibe un aviso de un liacuteder en el mismo plazo el primeropasa a ser seguidor y se acaba la eleccioacuten de liacuteder
Por otro lado si un equipo candidato no recibe los votos en el plazo y agotasu tiempo de espera avanza al siguiente plazo y repite el proceso de votacioacutenLa tercera posibilidad puede conllevar a un estado indefinido ya que varioscandidatos pueden agotar su tiempo de espera al mismo tiempo y repartir losvotos Para solventarlo el algoritmo establece tiempos de espera aleatorios paralos candidatos
Siguiendo con el ejemplo propuesto el servidor S1 pasa a ser el liacuteder Cadacierto tiempo eacuteste debe realizar avisos a los nodos seguidores para no agotar sutiempo de espera
En este momento el cluster de servidores estaacute en ldquoconsensordquo y la informacioacutenen todos los nodos estaacute actualizada Un cambio en la informacioacuten inicia unproceso de replicacioacuten el liacuteder registra el cambio lo pasa al resto de nodos yuna vez eacutestos responden el cambio se hace efectivo
Supoacutengase que se realiza un cambio en los datos en la figura 13 en la partederecha se observa el cambio en el registro del servidor S1 que informa a losnodos seguidores En consecuencia los nodos registran el cambio y responden aS1
Figura 13 Cambio en un registro (RAFT)
Una vez el cuoacuterum (en el ejemplo tres equipos) informa al liacuteder de que
22
ha registrado el cambio el liacuteder lo hace efectivo en su sistema y notifica a losnodos que hacen lo mismo En la figura 14 el enviacuteo todaviacutea no ha llegado ala maacutequina S3 y se observa que no ha hecho efectivo el cambio (en el registroaparece punteado)
Figura 14 Aprobacioacuten del resto de equipos (RAFT)
Este protocolo funcionaraacute correctamente mientras exista un nuacutemero de nodosen funcionamiento igual o superior al cuoacuterum en el ejemplo propuesto elcuoacuterum es tres por lo que el sistema puede tolerar la caiacuteda de dos de los equipos
522 Protocolo gossip SWIM
Nomad permite la gestioacuten simultaacutenea de varios centros de datos reparti-dos en regiones geograacuteficamente separadas requiriendo de un protocolo ligeroque mantenga a los miembros actualizados sobre los participantes del conjun-to Para ello usa una ligera variante del protocolo SWIM[3] (Scalable Weakly-consistent Infection-style Process Group Membership Protocol) desarrollada porHashiCorp Estaacute clasificado como un protocolo de tipo gossip que debe su nom-bre a la semejanza con coacutemo se distribuye un rumor en una red social
SWIM se sustenta en dos caracteriacutesticas fundamentales la deteccioacuten de fallosy la distribucioacuten de la informacioacuten relativa a los miembros A continuacioacuten sedetalla el funcionamiento de ambos componentes
Deteccioacuten de fallos
Este componente tiene dos paraacutemetros el periodo de protocolo T y el nuacutemerode subgrupos de deteccioacuten de fallos k en los que se dividen los nodos Paracomprobar la comunicacioacuten entre dos maacutequinas usa la utilidad ping basadaen el protocolo ICMP La deteccioacuten de caiacuteda de un servidor sigue el siguientealgoritmo
Durante el periodo T cada miembro Mi de un subgrupo elige otro al azar Mjdel mismo subgrupo y le enviacutea un mensaje ping para comprobar su estado Enel caso de que se cumpla un tiempo de espera determinado por una estimacioacuten
23
del tiempo de ida y vuelta (RTT por sus siglas en ingleacutes) de la red y no hayarespuesta Mi le vuelve a enviar un mensaje ping indirectamente a traveacutes deun nuacutemero k de miembros escogidos aleatoriamente De no recibir ninguna res-puesta Mi establece que Mj ha sufrido un fallo y lo etiqueta como ldquosospechosordquoinformando al componente de distribucioacuten
Figura 15 Diagrama de tiempo del protocolo SWIMFuente httpswwwcscornelledu
Componente de distribucioacuten
Se encarga de informar de cualquier cambio en los miembros a todo el con-junto Los eventos de nodo caiacutedo y la unioacuten o disociacioacuten de un miembro setransmiten a todos los servidores para que actualicen sus lista Para distribuirla informacioacuten a todos los nodos se podriacutea usar el meacutetodo de multicast perosuele estar deshabilitado Por ello se utiliza una teacutecnica de transmisioacuten denomi-nada Piggybacking mediante la cual se adjunta a los propios mensajes PINGy ACK del algoritmo la informacioacuten a distribuir reduciendo asiacute la congestioacutenen la red
523 Planificacioacuten
Proceso encargado de distribuir las tareas entre los nodos clientes de acuerdoa su estado
El planificador de Nomad estaacute basado en las publicaciones de Google sobresus herramientas de gestioacuten de clusters Borg y Omega14 y entiende los trabajosdescritos por el usuario como un estado deseado es decir su despliegue en unamaacutequina cliente de forma correcta y los clientes como el estado actual esto eslo que se encuentra en ejecucioacuten El registro actualizacioacuten o cancelacioacuten de un
14httpresearchgooglecompubspub43438html
24
trabajo asiacute como el fallo de un nodo cliente implican un cambio de estado atramitar por el sistema lo que se define como evaluacioacuten (evaluation) Esto uacutelti-mo supone comparar el estado actual (clientes) con el estado deseado (conjuntode trabajos registrados) y enviarlos a los planificadores correspondientes que seencargaraacuten de asignar las tareas a los nodos clientes
Figura 16 Procedimiento de asignacioacuten en NomadFuente httpswwwnomadprojectio
En la figura 16 se observa el flujo de trabajo en el que las distintas evalua-ciones se encolan en el evaluation broker que se ejecuta en el servidor liacuteder ygestiona las evaluaciones pendientes asignaacutendoles prioridades
A continuacioacuten los nodos servidores ejecutan los scheduling workers queprocesan las evaluaciones llamando a los distintos planificadores que generanun plan de asignacioacuten esto es un conjunto de relaciones entre las tareas y losnodos clientes donde se ejecutaraacuten Este proceso se divide en dos fases primerose descartan aquellos clientes que no cumplan los requisitos y posteriormentese asigna una calificacioacuten al resto Se selecciona el nodo con mayor puntuacioacuteny se encola el plan en el gestor que se ejecuta en el servidor liacuteder Existen tresplanificadores de acuerdo al tipo de trabajo
Service Incluye aquellos trabajos que estaacuten destinados a ejecutarse en un pe-riacuteodo largo de tiempo Para realizar las asignaciones el planificador evaluacuteala mayor parte de los nodos y usa una versioacuten del algoritmo Best fit in-fluenciada por el trabajo de Google en su herramienta Borg Se trata deun algoritmo de planificacioacuten que sacrifica tiempo a cambio de maximizarel rendimiento de los clientes asignando la tarea a la maacutequina que tengala mayor carga de trabajo con el objetivo de reducir equipos en funciona-
25
miento
Batch Tareas que incluyen listas de comandos en general de menor duracioacuteny que no requieren interaccioacuten con el usuario Se vale del algoritmo deSparrow desarrollado por la universidad de Berkeley15 para limitar losnodos clientes a evaluar
System Trabajos destinados a ejecutarse en todos los nodos incluso los que seunen al cluster posteriormente
Core Mantenimiento interno de Nomad
Una vez se ha realizado el proceso de planificacioacuten el nodo liacuteder lo registra enla cola de planes (plan queue) que se encarga de asignarles prioridad y manejarcondiciones de carrera es decir que no accedan a los recursos de los clientes sincontrol y evitar que eacutestos superen su capacidad
La maacutequina liacuteder del conjunto puede de este modo aceptar una asignacioacuteny ser ejecutada por los clientes o por el contrario rechazaacutersela al planificadorlo que implicariacutea realizar un plan parcial o totalmente nuevo
Finalmente el estado de las evaluaciones se actualizan y los clientes soninformados de las asignaciones ejecutaacutendose las tareas
15httppeopleeecsberkeleyedu~keopublicationssosp13-final17pdf
26
6 Casos de uso y despliegue
Con el objetivo de mostrar las posibles utilidades que este tipo de sistemaspueden tener en las infraestructuras TI actuales se han desplegado las dos he-rramientas en la nube Microsoft Azure usando su servicio cloud de instancias demaacutequinas virtuales Linux para simular un conjunto de ordenadores conectadosentre siacute por una red LAN Sobre ellas se ha implementado dos casos de usouna aplicacioacuten web con una arquitectura con cierta orientacioacuten a microserviciosy un sistema de integracioacuten continua
El coacutedigo y todos los ficheros de configuracioacuten se pueden encontrar en elrepositorio del proyecto en GitHub16
61 Aplicacioacuten Web
Se busca simular el proceso de adaptacioacuten de una solucioacuten web para su des-pliegue en un sistema distribuido con las herramientas anteriormente descritascon el objetivo de aumentar tanto su escalabilidad como disponibilidad medianteredundancia
Se ha partido de una aplicacioacuten ya existente17 un servicio de almacenamien-to y reproduccioacuten de canciones A grandes rasgos este servicio permite crearusuarios subir canciones con sus respectivas portadas tener playlists propias yescuchar las canciones a traveacutes de un navegador web
La solucioacuten estaacute dividida en 4 partes (figura 17)
Una vista web con la loacutegica
Un almacenamiento conectado en red (NAS por sus siglas en ingleacutes)
Una API REST para gestionar las peticiones al almacenamiento
Base de datos NoSQL basada en MongoDB
La nueva tendencia de los proyectos web es su implementacioacuten en contene-dores Docker ya que facilitan su portabilidad y ofrecen un procedimiento dedespliegue raacutepido sobre todo a la hora de desarrollar y realizar pruebas en en-tornos de produccioacuten simulados Por ello en este caso se va a hacer uso de los
16httpsgithubcomAntonioAlfrzCloud-Orchestrators17httpsgithubcomsonsoleslpCDPSfy
27
motores de orquestacioacuten de contenedores de ambas herramientas Marathon enDCOS y el controlador Docker en el caso de Nomad
Figura 17 Arquitectura aplicacioacuten web
A continuacioacuten vamos detallar el despliegue en ambas herramientas de es-ta solucioacuten y observar tanto queacute dificultades se encuentran como que ventajasofrecen El objetivo final es adaptar el proyecto modificaacutendolo lo menos posiblecon objeto de analizar la capacidad de estas herramientas para desplegar cual-quier aplicacioacuten sin que eso conlleve la modificacioacuten de la arquitectura de eacutestaes decir que no sea dependiente del entorno
611 DCOS
Se ha descrito DCOS como una herramienta que se despliega sobre un con-junto de ordenadores y que permite instalar gestionar el despliegue de sistemasdistribuidos
Microsoft Azure cuenta con una plantilla para desplegar en su servicio cloudun cluster de maacutequinas virtuales con DCOS ya instalado que cuenta con
Maacutequinas maestras (1 3 o 5 a seleccionar por el usuario) configuradascomo un conjunto de disponibilidad esto eso Azure da ciertas garantiacuteasde que al menos una maacutequina estaraacute en funcionamiento
Maacutequinas agentes Por motivos de seguridad se distinguen dos roles
bull Nodos privados solo accesibles desde la red interna y configuradoscomo un conjunto de escala un recurso de Azure para gestionar ydesplegar maacutequinas con configuraciones ideacutenticas para permitir unraacutepido escalado
bull Un equipo conectado accesible desde Internet a travntildees de un balan-ceador de carga puacuteblico y situado en una subred externa
28
Dos balanceadores de carga
bull La interfaz puacuteblica del cluster que se conecta con el cliente puacuteblicobull Acceso a los equipos maestros para el administrador que soacutelo permiteconexioacuten mediante SSH y credenciales
Almacenamiento para todas las maacutequinas
Configuraciones necesarias de red y seguridad
En la figura 18 se observa un diagrama de la infraestructura
Figura 18 Infraestructura en Azure
El primer obstaacuteculo es la persistencia de estado de la aplicacioacuten que seconsigue gracias a una base de datos no relacional basada en MongoDB asiacutecomo el almacenamiento de las canciones Para implementarla tenemos variasposibilidades
Montar un sistema externo de almacenamiento conectado en red en todoslos agentes donde se ejecuten las tareas de esta manera si una tarea pasade un nodo a otro por cualquier motivo puede tener acceso a los mismosficheros (opcioacuten del caso de uso original)
Implementar un sistema de ficheros distribuidos en los agentes
Usar los servicios de almacenamiento de las nubes puacuteblicas
Aprovechar el sistema de voluacutemenes persistentes de Apache Mesos Eacutestepermite reservar recursos de un agente de forma que al arrancar una tarease crea un volumen independiente del ciclo de vida de eacutesta con ello esosrecursos donde se ha almacenado la informacioacuten pueden volver a ofrecerseal mismo entorno de tal manera que otra tarea pueda acceder a ella
DCOS aprovecha este sistema de voluacutemenes persistentes y permite instalarbases de datos distribuidas como ArangoDB o Apache Cassandra sin embargoesto implicariacutea modificar todo el coacutedigo referente al modelo de la base de datos
29
Por motivos de eficiencia y latencia asiacute como de una mayor gobernabilidadde los datos la mejor opcioacuten es usar el recurso de voluacutemenes persistentes queofrece Apache Mesos ya que de esta manera se gestionariacutea la aplicacioacuten completamediante una uacutenica herramienta Sin embargo esto implica que la informacioacutense encuentra exclusivamente en el agente donde se haya ejecutado la tarea y porlo tanto se sigue requiriendo de software externo para distribuir la informacioacutenpara que se accesible para todos los agentes A la hora de realizar este proyectose encontraba en desarrollo Flocker una solucioacuten desarrollada por ClusterHQque permite compartir los voluacutemenes de Docker a traveacutes de un cluster quesi bien es compatible con el planificador de Mesos el proyecto se encontrabatodaviacutea en fases tempranas de desarrollo y los sistemas de almacenamiento quesoporta quedaban fuera del aacutembito de este trabajo
Por todo ello dado que las maacutequinas se han desplegado en la nube puacuteblicade Azure se decidioacute usar su servicio de almacenamiento de objetos para lascanciones y otra maacutequina para desplegar MongoDB y asiacute mantener el modelode datos original de la aplicacioacuten La diferencia del almacenamiento de obje-tos con respecto a nivel de fichero es que el primero no tiene jerarquiacutea paraorganizar los archivos eacutestos se guardan como objetos (con sus metadatos) enun mismo espacio soacutelo diferenciaacutendose por un identificador uacutenico esto implicaentre otras cosas que se puede acceder a un fichero dado uacutenicamente su IDindependientemente de la localizacioacuten fiacutesica de eacuteste facilitando pues la gestioacuteny el desarrollo
El coacutedigo del proyecto se ha modificado en los siguientes apartados
Las direcciones de la base de datos y los balanceadores de carga asiacute comosus puertos estaban originalmente fijos Se han configurado como variablesde entorno para facilitar el descubrimiento del servicio y hacer transpa-rente la aplicacioacuten al entorno de despliegue
La API REST se ha adaptado al almacenamiento en Azure en vez de enlocal
Estas modificaciones no suponen un cambio sustancial pero permiten separala persistencia de las tareas ejecutadas por DCOS lo que facilita en granmedida su ejecucioacuten al ser totalmente sin estado y ademaacutes implican tenerlos datos bajo un mayor control
Para la orquestacioacuten de contenedores se va a usar el entorno Marathondesarrollado tambieacuten por Mesosphere Eacuteste se puede usar a traveacutes de una interfazgraacutefica la interfaz de liacutenea de comandos (en lo que sigue CLI por sus siglas eningleacutes) de DCOS o con su API HTTP
Primero se han publicado la imaacutegenes de los contenedores que encapsulanla interfaz web y la api de la aplicacioacuten en el repositorio puacuteblico DockerHub
Los despliegues en este entorno se describen mediante ficheros JSON en losque se detalla entre otras opciones la imagen del contenedor los puertos a usar
30
los recursos que debe ocupar en un nodo o las instrucciones de monitorizacioacuten
Para el servicio de descubrimiento DCOS ofrece la posibilidad de asignardirecciones IP virtuales (VIP por sus siglas en ingleacutes) a tareas que se compartenen todos los nodos DCOS lleva integrado un balanceador de carga a nivel TCP(el componente denominado Minuteman) que balancea entre las direccionesvirtuales de las tareas y todas las instancias de eacutestas a lo largo del cluster Estoes necesario por dos motivos equilibrar la carga de los equipos con el fin deevitar un punto de uacutenico fallo mediante redundancia y evitar la contienda dedirecciones al ejecutar las tareas en puertos aleatorios
Este balanceador de carga estaacute basado en el trabajo de Michael Mitzenma-cher The Power of Two Choices in Randomized Load Balancing18 A grandesrasgos el algoritmo mantiene una media moacutevil exponencial de latencias paracada destino (backend) ademaacutes de las caiacutedas consecutivas Si un destino noresponde a una negociacioacuten en tres pasos (three way handshake) de forma con-secutiva en un periodo inferior a 5 ms se considera caiacutedo El algoritmo iterasobre los destinos disponibles en base a su histoacuterico de fallos y escoge dos deforma aleatoria de los cuales coge el de mejor meacutetrica
Las direcciones virtuales soacutelo se pueden resolver dentro del cluster porello para implementar la interfaz puacuteblica de la aplicacioacuten esto es el balancea-dor de carga de la interfaz web usaremos un paquete de DCOS denominadomarathon-lb un balanceador basado en HAProxy y adaptado por MesosphereEn este caso equilibra la carga de todas instancias de las tareas ejecutadas porel entorno Marathon por sus etiquetas y permite ademaacutes definir como puntode entrada muacuteltiples hosts virtuales definidos por sus nombres completos dedominio (FQDN por sus siglas en ingleacutes) en nuestro caso la interfaz puacuteblicadel balanceador de Azure para los agentes
Por motivos de seguridad todas las tareas se ejecutan en los agentes privadoses decir los que son exclusivamente accesibles desde la red interna Por su partemarathon-lb se ejecuta en el agente puacuteblico que cuenta con IP puacuteblica y lospuertos 80 (HTTP) y 8080 abiertos de forma que la aplicacioacuten sea accesibledesde Internet Esto es posible debido a que Apache Mesos permite reservarrecursos mediante roles asignados a nodos para un uso especiacutefico De esta formala arquitectura vista desde la aplicacioacuten quedariacutea como en la figura 19
18httpswwweecsharvardedu~michaelmpostscriptstpds2001pdf
31
Figura 19 Arquitectura de la aplicacioacuten web en DCOS
Ejecucioacuten
A la hora de desplegar la aplicacioacuten DCOS puede gestionarse medianteuna interfaz graacutefica o una interfaz de liacutenea de comandos La primera se accedea traveacutes de un navegador web en el puerto 80 (HTTP) y permite instalar losentornos disponibles observar el estado de los nodos y las tareas que se estaacutenejecutando y los ficheros de registros que eacutestas generan
La CLI permite el control desde un nodo o una maacutequina remota (suponiendoque los maestros tienen IP puacuteblica y el puerto 80 abierto) ya que DCOS tieneun sistema de autorizacioacuten que permite tener una interfaz puacuteblica con ciertasgarantiacuteas de seguridad
Por su parte cada entorno de trabajo puede ser controlado por la CLI peroademaacutes cuenta con sus propias interfaces Marathon expone una API HTTPen el puerto 8080 de la direccioacuten puacuteblica de los maestros del cluster asiacute comootra interfaz graacutefica Para desplegar un contenedor se podriacutea usar la CLI
$ dcos marathon app add lt f i l e j songt
O la API HTTP
$ cu r l minusX POST http lt ip_maestro gt8080v2apps minusd ltf i l e jsongt minusH Contentminustype app l i c a t i o n j son
32
612 Nomad
La arquitectura de Nomad es maacutes sencilla ya que solo requiere de un ficheroejecutable en todos los nodos para funcionar Si DCOS es la base de instala-cioacuten de entornos de terceros Nomad integra todas las funcionalidades baacutesicasesto es gestor de recursos planificador y ejecutor en los nodos cliente Estaherramienta cuenta con un menor tiempo de desarrollo y en el momento deescribir este documento cuenta exclusivamente con los siguientes controladoresen comparacioacuten con los entornos de DCOS
Motor Docker es decir funcioacuten de orquestacioacuten de contenedores
Ejecucioacuten de archivos binarios como comandos de Shell
Ejecucioacuten de aplicaciones Java
Virtualizacioacuten de maacutequinas mediante tecnologiacutea QEMU
Todos ellos necesitan que la tecnologiacutea subyacente esteacute instalada en las maacute-quinas clientes (Docker Java QEMU) Actualmente no permite el registro decontroladores por parte de terceros aunque estaacute planificado en un futuro ofreceruna interfaz para su desarrollo
Nomad no cuenta con el servicio de descubrimiento sin embargo puede inte-grarse con la herramienta Consul desarrollada por la misma empresa Por otrolado para el balanceo de carga usaremos un contenedor Docker con HAProxyuna herramienta de coacutedigo abierto que ofrece tanto servicios de proxy como debalanceador y cuyos ficheros de configuracioacuten completaremos con el proyectoConsul Template19
Consul
Consul sigue la misma arquitectura que Nomad es decir un nodo servidorque orquesta un conjunto de maacutequinas clientes y permite a los procesos que seejecutan en los equipos definirlos como servicios ofreciendo diversas caracteriacutes-ticas entorno a estos de los cuales vamos a usar dos
Descubrimiento de servicio Las maacutequinas clientes publican en el cataacutelogode servicios las tareas en ejecucioacuten y Consul les asigna nombres de dominioaccesibles por todos los miembros del cluster a traveacutes de la interfaz DNSincluida en esta herramientaConsul se integra con Nomad de forma que todas las tareas que se ejecu-ten en la segunda son automaacuteticamente publicados como servicios de laprimera de esta manera no hace falta conocer la direccioacuten de la maacutequinacliente donde se esteacute ejecutando el proceso ya que se puede acceder a eacutela traveacutes de su nombre de dominio de forma transparente Por ejemplo si
19[httpsgithubcomhashicorpconsul-template]
33
ejecutamos una tarea con ID web en el puerto 8080 se puede acceder aella en la direccioacuten webserviceconsul8080Para que las direcciones propias de Consul las resuelva su propio DNS y noel que esteacute asignado por defecto en la maacutequina usaremos la herramientadnsmasq20 que permite especificar la direccioacuten de un servidor DNS paraconsultas de direcciones especiacuteficas
Monitorizacioacuten Permite realizar comprobaciones del servicio y seguir su esta-do Aprovecharemos esta funcionalidad tanto para definir el propio procesode Nomad como servicio de Consul como las tareas desplegadas
HAProxy + Consul Template
HAProxy es una solucioacuten versaacutetil de coacutedigo abierto que ofrece solucionesde balanceo de carga y proxy Existen otras herramientas en el mercado comoNGINX o ldirectord sin embargo HAProxy suponiacutea una solucioacuten sencilla deconfigurar para mostrar el caso de uso
El uso de estas herramientas se debe a dos motivos para que no existacontienda con respecto a los puertos de los clientes usados por las tareas eacutestos sevan a asignar de forma dinaacutemica lo que en principio implicariacutea que la aplicacioacutendeberiacutea realizar consultas DNS de tipo SRV (que incluye puertos) a la interfazde Consul y balancear la carga entre tareas por redundancia y capacidad
Como la direccioacuten IP y puerto son variables cada vez que las tareas seactualicen o se reasignen es necesario volver a configurar HAProxy de formamanual Por ello HashiCorp ha desarrollado un programa denominado Con-sul Template que realiza peticiones sucesivas a la interfaz HTTP de Consul delas direcciones fiacutesicas de un servicio y reinicia automaacuteticamente el proceso deHAProxy Asiacute definiendo estas tareas como servicios Consul podremos tantomonitorizarlas como escalar las tareas dinaacutemicamente sin necesidad de cambiarel balanceador A partir del contenedor Docker oficial de HAProxy se ha desa-rrollado otro con la configuracioacuten baacutesica y con Consul Template para desplegarlocomo una tarea en Nomad
Despliegue
Se ha usado el mismo coacutedigo que en el apartado anterior con la persistenciaen el servicio de almacenamiento de Azure Desde la perspectiva del hardwarese implementaraacute la misma infraestructura que en el caso de DCOS (figura 18)estos es definiremos dos tipos de maacutequinas clientes un agente que se conectaraacutecon el balanceador de carga con nombre de dominio puacuteblico y donde se desple-garaacute el balanceador de carga de la vista web y agentes privados no accesiblesdesde fuera del cluster y donde se ejecutaraacuten el resto de tareas en la red inter-na La principal diferencia radica en las tareas que ejecutan HAproxy y ConsulTemplate que sustituye a las direcciones IP virtuales que ofrece DCOS
20httpwwwthekelleysorgukdnsmasqdochtml
34
Figura 20 Despliegue en Azure de Nomad+Consul
Cabe matizar que los balanceadores basados en HAProxy se implementanpor necesidad de la aplicacioacuten para el descubrimiento del servicio a diferenciade los de Azure que se implementan por motivos de seguridad y escalabilidaddel cluster en siacute
Configuracioacuten Nomad
Los ficheros de configuracioacuten de las maacutequinas maacutester y cliente son similaresy comparten la mayoriacutea de las opciones como por ejemplo el nombre del nodoo la interfaz de red donde escucha Nomad las peticiones Sus opciones son engeneral auto-explicativas sin embargo existen dos detalles que matizar
El proceso de Nomad escucha las peticiones tanto de los protocolos deconsenso como del usuario a traveacutes de una interfaz de red que se debeindicar en el fichero de configuracioacuten
En el caso de los clientes se deben indicar las direcciones de los servidoresdel cluster sin embargo se trata de un sistema dinaacutemico en el que losnodos pueden sufrir errores y cambiar de direccioacuten Por ello se ha definidoNomad como un servicio de Consul y asiacute poder definir la direccioacuten de losservidores como un nombre de dominio no por su direccioacuten fiacutesica que elservidor DNS de Consul se encargaraacute de resolver
Por defecto Nomad usa los siguientes puertos
API HTTP 4646 Peticiones HTTP y recepcioacuten de oacuterdenes mediante laliacutenea de comandos
RPC 4647 Protocolo de consenso entre los nodos del cluster
Serf 4648 Protocolo de gossip entre los servidores de los centros de datosgobernados por Nomad
35
Los dos uacuteltimos deben ser interfaces alcanzables por otros nodos sin embargo laAPI HTTP por motivos de seguridad deberiacutea ser local ya que en caso contrariocualquier persona con acceso a ella tiene el control sobre la herramienta Eacutestasolo deberiacutea estar accesible en un servidor o gestionarlo mediante una terminalSSH por ejemplo En este trabajo al ser una prueba de concepto se ha abiertoen todos los nodos
Trabajos de Nomad
Las tareas se detallan en ficheros con formato HashiCorp Configuration Lan-guage un derivado del formato JSON creado por la empresa que le da nombrecompatible con eacuteste y que permite comentarios
En estos ficheros se puede definir
La regioacuten y el centro de datos donde se ejecutaraacute (Nomad permite lagestioacuten de centros de datos geograacuteficamente distribuidos en regiones)
La poliacutetica de actualizacioacuten de la tarea
Grupo de tareas esto es que se ejecutaraacuten en el mismo nodo
El nuacutemero de grupos a ejecutarescalar asiacute como los liacutemite que debencumplir los nodos asignados
La poliacutetica de reinicio ante fallo o error
Tareas El controlador su configuracioacuten los paraacutemetros del servicio aso-ciado a registrar en Consul asiacute como los recursos que consume (puertosmemoria)
En nuestro caso usamos sobre todo el controlador Docker esto eso orques-tacioacuten de contenedores en los nodos clientes y tres de sus opciones
Imagen del contenedor Se han subido todas las imaacutegenes del proyecto a Doc-ker Hub donde por defecto se busca la imagen
Puertos Los puertos a usar por el contenedor que pueden ser estaacuteticos asigna-dos por el usuario o dinaacutemicos siendo Nomad el que se encarga de mapearun puerto libre del nodo cliente al expuesto por el contenedor
Servidores DNS Como usamos la interfaz DNS de Consul como descubri-miento de servicio se debe configurar el contenedor para que use cualquiernodo del cluster como servidor DNS
Configuracioacuten Consul
Al ser desarrolladas por la misma empresa los ficheros de configuracioacuten deConsul y Nomad comparten muchas opciones Consul tambieacuten acepta peticionesa traveacutes de una interfaz de red siendo los puertos usados por defecto
36
RPC 8300 8400 Maneja la peticiones del resto de nodos y usuarios
Serf 8301 8302 Protocolo gossip
HTTP API 8500
HTTPS API Desactivada por defecto
Interfaz DNS 8600
Se debe asignar a los protocolos internos del cluster esto es RPC y Serf unainterfaz alcanzable por los nodos y por el contrarioasignar a los dos uacuteltimos ala interfaz de loopback por motivos de seguridad
Cabe destacar que Consul tambieacuten cuenta con una interfaz graacutefica que per-mite ver el estado de los equipos y los servicios registrados y que se encuentra enel mismo puerto que la API HTTP en la direccioacuten httpIP_EQUIPO8500ui
Ejecucioacuten
Tanto Nomad como Consul requieren de la ejecucioacuten de un fichero en todoslos nodos integrantes del cluster Como prueba de concepto se ha decidido usardos servidores para ambos aunque cabe matizar que es un nuacutemero ineficienteya que la caiacuteda de uno de ellos supondriacutea la peacuterdida del cuoacuterum y por tantodel consenso del cluster
En primer lugar se arrancan los servidores que son los encargados de ejecu-tar el protocolo de consenso y gestionar el cluster y a continuacioacuten los clientesque no tienen praacutecticamente estado y dependen de los servidores
En el caso de Consul se debe indicar el directorio donde se guardan losficheros que describen los servicios asiacute como el archivo que especifica el resto delas opciones
1 Se inicia el primer servidor en uno de los equipos
$ consu l agent minuscon f i gminusd i r e t c consu l d s e r v i c e s minuscon f i gminus f i l e consu l_server j son
2 Los siguientes equipos deben unirse al anterior por lo que antildeadimos elargumento join con la direccioacuten del primer servidor Para el caso de otrosservidores
$ consu l agent minuscon f i gminusd i r e t c consu l d s e r v i c e s minuscon f i gminus f i l e consu l_server j son minus j o i n ltIP_servidor1gt
37
Una vez los servidores han alcanzado el consenso y elegido un liacuteder en losclientes
$ consu l agent minuscon f i gminusd i r e t c consu l d s e r v i c e s minuscon f i gminus f i l e c on su l_c l i en t j son minus j o i n ltIP_cualquierServ idorgt
El proceso para iniciar Nomad es igual y los comandos similares sin embargoya no es necesario indicar una direccioacuten IP fija en los equipos sino el nombre dedominio del servicio de Nomad registrado por Consul En el primer servidor
$ nomad agent minusc on f i g nomad_server j son
Y el resto de equipos (con su fichero de configuracioacuten correspondiente)$ nomad agent minusc on f i g nomad_server j son minus j o i n nomad s e r v i c e consu l
Por uacuteltimo para desplegar la aplicacioacuten web se han escrito tres ficherosque detallan las tareas de la interfaz web API y los balanceadores de cargaMediante la CLI
$ nomad run minusaddress=http lt ip_c lus te r gt4646 lt f i l e hclgt
O mediante la API HTTP de Nomad$ cu r l minusX POST minusd ltf i l e hclgthttp lt ip_c lus te r gt4646 jobltjob_namegt
Ansible
Como se puede comprobar con el aumento del nuacutemero de equipos pasa aser inviable manejar todos los nodos a traveacutes de terminal Ademaacutes como seha comentado con anterioridad Nomad requiere que en los nodos clientes es-teacuten instalados las herramientas que soporten las tareas por ejemplo el motorde Docker Por ello para facilitar tanto el arranque como la instalacioacuten de lasdependencias vamos a usar Ansible una herramienta de coacutedigo abierto desarro-llada en Python que permite gestionar configuraciones aprovisionar recursosdespliegue de aplicaciones de forma automaacutetica
A grandes rasgos esta herramienta funciona mediante ficheros en formatoYAML denominados play-books que describen un conjunto de pasos a ejecutaren una lista de equipos remotos Estos pasos son ejecutados por moacutedulos inde-pendientes a traveacutes de SSH es decir en cualquier ordenador con conexioacuten a los
38
hosts dado su contrasentildea o clave puacuteblica puede arrancar el script y realizariacutealos pasos de forma remota gestionando el cluster desde un solo equipo
Se han desarrollado guiones para lo siguiente
Descarga de los binarios de Nomad y Consul en todos los nodos copiade los ficheros de configuracioacuten baacutesicos y modificarlos de acuerdo a cadanodo (nombre del equipo direccioacuten IP)
Instalacioacuten de las dependencias
Arranque de Nomad y Consul
Ansible extiende su funcionalidad a traveacutes de moacutedulos independientes que per-miten por ejemplo instalar paquetes mediante herramientas de gestioacuten de pa-quetes (APT yum) aprovisionar automaacuteticamente maacutequinas virtuales de Ama-zon EC2
Algunas opciones de los ficheros de configuracioacuten de Nomad y Consul sondependientes del nodo particular por ejemplo la interfaz de red Para estetrabajo se ha realizado un moacutedulo para modificar los ficheros de configuracioacutende forma automaacutetica En el repositorio del proyecto se encuentra una carpetadonde se encuentran todos los ficheros necesarios para desplegar un clustertotalmente funcional solo requiere de una liacutenea de terminal con Ansible
$ ans ib l eminusplaybook minus i hos t s minusk ltssh_passgt minusu ltnode_usergt s i t e yml
39
62 Servicio de integracioacuten continua
Se ha implementado un sistema de integracioacuten continua que permite ejecu-tar tareas de compilacioacuten y pruebas de forma distribuida aumentando asiacute elrendimiento de los equipos En primer lugar se detallaraacute los motivos por los quepuede resultar beneficioso para las empresas una implementacioacuten de este tipo alo que seguiraacute los detalles del despliegue
621 DevOps
Metodologiacutea que defiende la comunicacioacuten y colaboracioacuten entre desarrolla-dores de software y los profesionales de operaciones a lo largo de todo el ciclo devida de una aplicacioacuten Estaacute muy relacionado con el desarrollo aacutegil de softwareesto es un enfoque para los proyectos que defiende el desarrollo iterativo e in-cremental donde los requisitos y soluciones evolucionan con el tiempo seguacuten lanecesidad del proyecto DevOps extiende esta filosofiacutea a todas los componentesde un servicio incluyendo sistemas y operaciones
Se trata de un concepto que cada organizacioacuten o empresa adapta a suspropias necesidades y procesos de negocio en este proyecto nos vamos a centraren la integracioacuten continua una praacutectica fundamental tanto del desarrollo aacutegilcomo de esta filosofiacutea
622 Integracioacuten Continua
Se define como una praacutectica de desarrollo software donde los miembros delequipo ponen en comuacuten su trabajo frecuentemente al menos una vez al diacutea21Cada integracioacuten se verifica con una compilacioacuten automaacutetica que incluye laejecucioacuten de pruebas para detectar errores de integracioacuten tan pronto como seaposible
Desde el punto de vista operativo esto supone automatizar la configuracioacutende equipos o el despliegue de maacutequinas virtuales donde compilar el proyecto yejecutar las pruebas y posteriormente eliminarlas Este flujo de trabajo se vebeneficiado en entornos distribuidos ya que el objetivo del desarrollador es com-probar el resultado de las pruebas raacutepidamente sin preocuparse del despliegueo los propios equipos
Para esta prueba de concepto vamos a usar Jenkins un servidor de integra-cioacuten continua escrito en Java que nos permite definir trabajos que contendraacutenla descripcioacuten tanto del entorno como su ejecucioacuten
Este sigue una estructura maestro-esclavo muy similar al de los gestores declusters usados en este proyecto el maestro contiene toda la loacutegica del servicio
21httpmartinfowlercomarticlescontinuousIntegrationhtml
40
trabajos autenticacioacuten y los esclavos son los encargados de la ejecucioacuten ensiacute Jenkins tiene varias viacuteas para aprovisionar los uacuteltimos
Mediante SSH
Interfaz graacutefica
Desarrollar un script propio
Ejecucioacuten de un fichero java
La ventaja de usar planificadores es que el despliegue de esclavos es dinaacutemicoes decir no tener una maacutequina especiacuteficamente configurada para ello DCOS yNomad se encargaraacuten de configurar estos despliegues en sus maacutequinas y poste-riormente eliminarlos Para ello se ha usado la uacuteltima opcioacuten definiendo tareasque descarguen el fichero java Con todo ello se consigue un entorno de inte-gracioacuten continua eficiente que ademaacutes permite la ejecucioacuten de otros servicios deforma independiente
Jenkins permite la creacioacuten de plugins que extienden sus funcionalidadesTanto Nomad22 como Apache Mesos cuentan con uno que permite su integra-cioacuten
Para esta prueba se va a usar el mismo proyecto que para el caso de usode orquestacioacuten de contenedores la aplicacioacuten web al que se le ha antildeadido untest para comprobar que se conecta correctamente a la base de datos medianteMocha un framework de Nodejs Por otro lado se antildeade el plugin de git ya queel coacutedigo se obtiene de GitHub el repositorio remoto de control de versiones delproyecto
El proceso general de ejecucioacuten seriacutea como sigue
1 Se ejecuta el maestro de Jenkins como tarea Docker partiendo de la imagenoficial
2 Al arrancar un trabajo se manda una tarea a los planificadores que laasignaraacuten a un nodo cliente Esta tarea consiste en la descarga del ficherode configuracioacuten Java y arrancarlo configurando el equipo como un clientede Jenkins temporalmente
3 Jenkins ejecuta el trabajo en el nuevo cliente en este caso iniciar la apli-cacioacuten web iniciar las pruebas y generar un informe
4 Se elimina el cliente
A continuacioacuten se detallan los matices de cada herramienta a la hora de imple-mentar este servicio
22Desarrollado por Ivo Verberk httpwwwivoverberknl
41
623 Jenkins con Nomad
El plugin permite la ejecucioacuten del fichero Java mediante dos controladorescontenedores Docker y Java En este proyecto nos hemos decantado por el pri-mero ya que nos ahorra instalar la maacutequina virtual de java en todos los nodoscliente Por ello se ha construido un contenedor base con Java para la ejecucioacutendel fichero de configuracioacuten y Nodejs para lanzar la aplicacioacuten web
El plugin se configura con la direccioacuten IP del cluster y el contenedor queejecuta el esclavo Jenkins Por su parte el trabajo en Jenkins se define conel repositorio en GitHub donde se aloja el coacutedigo del proyecto a probar y loscomandos a ejecutar en este caso npm update y npm test
624 Jenkins con DCOS
En el caso de DCOS su sistema de paquetes incluye Jenkins por lo queal instalarlo ya se tiene la configuracioacuten de Mesos totalmente funcional Sinembargo para ejecutar la aplicacioacuten en particular y las pruebas se requiere deNodejs en los equipos esclavos por ello debemos antildeadir un plugin de Jenkinsque permite instalar este entorno antes de ejecutar el trabajo Una vez hechoesto soacutelo queda definir la tarea igual que en el caso anterior
Cabe destacar que Mesosphere tambieacuten ha desarrollado un plugin que per-mite hacer despliegues en Marathon de tal manera que permitiriacutea con cadacommit del coacutedigo compilar la imagen del contenedor Docker y desplegarlaautomaacuteticamente aunque en este proyecto no se ha hecho pruebas de esta fun-cionalidad
42
7 Escalando la infraestructura
Uno de los factores clave que se busca a la hora de implementar sistemasdistribuidos es el poder escalar la infraestructura de forma maacutes sencilla estoes detectar que las maacutequinas estaacuten alcanzando el liacutemite de su capacidad yaumentar eacutesta ya sea mejorando sus caracteriacutesticas teacutecnicas o antildeadiendo maacutesnodos al cluster
El coacutedigo y todos los ficheros de configuracioacuten de esta seccioacuten tambieacuten sepueden encontrar en el repositorio del proyecto en GitHub23
71 Disentildeo
Microsoft Azure permite organizar los servicios cloud de forma loacutegica a traveacutesde grupos de recursos y asiacute poder crear o eliminar eacutestos en conjunto parauna aplicacioacuten determinada (por ejemplo una aplicacioacuten web suele requerir demaacutequinas virtuales bases de datos almacenamiento) Ademaacutes dispone dela opcioacuten de crear plantillas en formato JSON que permite al desarrolladordefinir los recursos y su interrelacioacuten para desplegar de forma automaacutetica unainfraestructura TI en la nube
Azure tambieacuten ofrece la posibilidad de monitorizar el estado de las maacutequinasvirtuales a traveacutes de extensiones lo que permite configurar el escalado automaacute-tico al alcanzar cierto liacutemite definido por el operador Eacutesta es a priori la formaen que deberiacutea implementarse hablando en teacuterminos de eficiencia sin embargoesta aproximacioacuten es totalmente dependiente de la plataforma es decir no sepuede extrapolar a otro proveedor o sobre recursos propios sin realizar un nue-vo disentildeo En este proyecto las tareas que son ejecutadas por estos equipos notienen estado ya que todo lo relativo a la persistencia lo hemos asignado fueradel cluster esto permite escalar la plataforma a traveacutes de otra aproximaciones
Las plantillas aceptan una serie de variables a indicar por el usuario entreotras los conjuntos de escala para definir los nodos aceptan una variable quedefine el nuacutemero de maacutequinas que los componen Por otro lado Azure ofreceuna API REST y kits de desarrollo software (SDK por sus siglas en ingleacutes) quepermiten su despliegue de forma programaacutetica Aprovechando estas facilidadesen este proyecto se va a aproximar la escalabilidad con el sucesivo desplieguede la infraestructura de forma automaacutetica se monitorizan los equipos y si sedetecta una maacutequina excesivamente cargada se aumenta el nuacutemero de equiposen la plantilla y se vuelve a desplegar
23httpsgithubcomAntonioAlfrzCloud-Orchestrators
43
En este proyecto se han disentildeado las plantillas para desplegar la arquitec-tura necesaria tanto de Nomad como de DCOS En el caso de la primera eldespliegue es maacutes descriptivo ya que incluye maacutequinas virtuales grupos de se-guridad redes En el caso de DCOS Azure cuenta con un servicio especiacuteficopara clusters gobernados por DCOS denominado Azure Container Service queincluye los componentes necesarios y la instalacioacuten ya realizada
72 Implementacioacuten
En primer lugar para monitorizar el estado de los equipos se va a usar laherramienta Nagios un sistema que permite controlar el estado del hardwarey los servicios de un equipo Se trata de una herramienta muy completa de laque se va a usar su capacidad para ejecutar comandos (plugins) en los nodospara detectar picos de carga generar alertas y ejecutar programas para estoseventos
Se ha desplegado una maacutequina virtual con esta herramienta en ambos siste-mas y se ha instalado una extensioacuten de Nagios (Nagios Remote Plugin Executor)en todos los nodos que permite ejecutar comprobaciones remotamente en con-creto para esta prueba de concepto medir el nivel de saturacioacuten de la unidadcentral de procesamiento (CPU por sus siglas del ingleacutes) Cuando sucede uncambio de estado de una maacutequina esto es cuando este paraacutemetro supera el liacutemi-te definido por el operador Nagios permite actuar en consecuencia ejecutandoprogramas por ello se ha desarrollado un script que ejecuta lo siguiente
Un programa desarrollado en Python con el SDK de Azure que modificalas plantillas y despliega los recursos
Un guioacuten de Ansible para instalar todos los componentes necesarios en lasnuevas maacutequinas y arrancar de nuevo el cluster y las aplicaciones
44
8 Resultados y conclusiones
En este uacuteltimo apartado se da una visioacuten global del proyecto asiacute como a lasconclusiones maacutes importantes a las que se ha llegado y posibles temas futurosde desarrollo
81 Comparacioacuten
Ambas herramientas ofrecen las funcionalidades para gestionar los recursoseficientemente ofreciendo a los desarrolladores una plataforma donde desplegarsus aplicaciones de forma distribuida independientemente de los equipos fiacutesicosy el hardware que las soporten
DCOS es una herramienta que en un comienzo fue privativa pero cuyos res-ponsables la empresa Mesosphere decidieron publicar una versioacuten de coacutedigoEacutesta nos permite gestionar un cluster de una forma sencilla y usable ademaacutes decomplementarlo con otras herramientas como el balanceador de carga integradoo la autenticacioacuten de usuarios ademaacutes estaacute basada en Apache Mesos un pro-yecto de relativa madurez y con el soporte de la Apache Software FoundationDe forma resumida DCOS ofrece muchas posibilidades y servicios a cambiode una arquitectura e instalacioacuten maacutes compleja
Por su parte HashiCorp con menor tiempo de desarrollo ha conseguidouna herramienta muy sencilla de desplegar que ademaacutes cumple con todas lasfuncionalidades baacutesicas ejecutando un simple binario en cada nodo se puededesplegar un gestor de clusters totalmente funcional Sin embargo no cuentacon todas las posibilidades de Mesos (Nomad cuenta con menos controladoresque entornos posibles de Mesos) ni con los antildeadidos de DCOS lo que implicael uso de otras herramientas para complementar el servicio (Consul HAProxy)
De entre las dificultades encontradas al usar estas herramientas y desplegaraplicaciones sobre ellas se puede destacar la depuracioacuten en ocasiones se desco-noce si un error viene de la propia herramienta de la aplicacioacuten desplegada o delequipo fiacutesico si no se cuenta con un sistema de procesamiento de registro unose puede encontrar con muacuteltiples terminales abiertas inspeccionando numerososficheros de registro buscando posibles errores Ademaacutes no dejan de ser solucio-nes que para usar eficientemente se debe conocer parte de su funcionamientoy sintaxis a la hora de describir la tareas lo que supone un esfuerzo antildeadido yaque cada una tiene sus particularidades y liacutemites
45
82 Conclusiones
En una sociedad cada vez maacutes digital las empresas deben adaptarse a unmercado cuya demanda de contenido no deja de crecer Las nuevas arquitecturascomo microservicios asiacute como la gran cantidad de datos generada implica queuna mejor gestioacuten de los recursos y la rapidez para desplegar o escalar solucionesdando valor al cliente lo maacutes raacutepido posible es uno de los objetivos de todas lasempresas de base tecnoloacutegica
Las ventajas que ofrecen los planificadores con aplicaciones distribuidas sonnumerosas sin ir maacutes lejos empresas tan punteras como Google llevan maacutesde 10 antildeos orquestando contenedores24 Por un lado permiten aumentar elrendimiento de los equipos propios y por otro implementar un servicio comoplataforma para despliegues distribuidos sobre cualquier conjunto hardware deesta forma se provee un servicio similar al de la nube puacuteblica pero con laprincipal diferencia de que se elimina la independencia con el proveedor (vendorlock-in) esto es las aplicaciones no tienen limitaciones impuestas por eacuteste talescomo lenguaje de programacioacuten o herramientas y permite despliegues hiacutebridosentre recursos propios y la nube
83 Objetivos conseguidos
Implementacioacuten de los planificadores propuestos en la nube Se ha en-tendido y detallado el funcionamiento de estas herramientas y se hanimplementado en el servicio de infraestructura de Microsoft Azure
Despliegue de aplicaciones y servicios distribuidos Servicios que se usanactualmente en la industria del desarrollo software asiacute como una aplica-cioacuten web con una arquitectura moderna han sido desplegados de formadistribuida en los equipos cumpliendo con la funcionalidad esperada ade-maacutes de consiguiendo una alta disponibilidad
Aproximacioacuten de arquitectura escalable Se ha hecho una aproximacioacutende infraestructura escalable de forma que sea parcialmente extrapolable aotros proveedores
24httpwwwnextplatformcom20160322decade-container-control-google
46
84 Liacuteneas de investigacioacuten
Siguiendo con la materia de este proyecto se presentan posibles liacuteneas deinvestigacioacuten
Analizar el despliegue con estas herramientas de aplicaciones de Big Datay comparar la eficiencia con respecto a soluciones especializadas
Analizar el rendimiento de los algoritmos de planificacioacuten antes pruebasde estreacutes y situaciones de alta contienda
Comparar el uso de estas herramientas con las praacutecticas actuales de laindustria o implementacioacuten en un sistema de produccioacuten real
47
Referencias
[1] LA Barroso y U Houmllzle laquoThe Datacenter as a Computer An Introduc-tion to the Design of Warehouse-Scale Machinesraquo En Morgan amp ClaypoolPublishers ()
[2] Systems Research Group ndash NetOS (University of Cambridge) The evolu-tion of cluster scheduler architectures 2016 url httpswwwclcamacukresearchsrgnetoscamsasblog2016-03-09-scheduler-architectureshtml
[3] A Das I Gupta y A Motivala SWIM Scalable Weakly-consistent Infection-style Process Group Membership Protocol Inf teacutec Dept of ComputerScience Cornell University url https www cs cornell edu ~asdasresearchdsn02-swimpdf
[4] D Dubhashi y A Das Mastering Mesos PACKT Publishing mayo de2016
[5] The Apache Software Foundation Apache Mesos documentation urlhttpsmesosapacheorg
[6] David Greenberg Building Applications on Mesos OrsquoReilly Media 2016[7] Armand Grillet Comparison of Container Schedulers Inf teacutec Technische
Universitaumlt Berlin[8] HashiCorp Consul documentation url httpswwwconsulio[9] HashiCorp Nomad documentation url httpsdcosio[10] Dan C Marinescu Cloud computing theory and practice Morgan Kauf-
mann 2013[11] Mesosphere DCOS documentation url httpswwwnomadproject
io[12] Microsoft Azure documentation url httpsazuremicrosoftcom
es-esdocumentation[13] D Ongaro y J Ousterhout In Search of an Understandable Consensus
Algorithm Inf teacutec Stanford University url httpsraftgithubioraftpdf
[14] Fei Teng laquoRessource allocation and schelduling models for cloud compu-tingraquo Tesis de mtriacutea Ecole Centrale Paris 2011
[15] A Williams y col Automation and Orchestration with Docker and Contai-ners A Comprehensive Overview of the Docker and Container Ecosystem3 The New Stack 2016
48
- Resumen
- Summary
- Iacutendice de figuras
- Introduccioacuten y objetivos
-
- Contexto
- Objetivos
- Estructura del documento
-
- Cloud Computing
- Nuevas cargas de trabajo
- Gestioacuten de recursos Planificadores
-
- Sistemas distribuidos
-
- Clasificacioacuten
-
- Herramientas
-
- DCOS
-
- Apache Mesos
- Ejemplos de uso
-
- Nomad
-
- Protocolo de consenso Raft
- Protocolo gossip SWIM
- Planificacioacuten
-
- Casos de uso y despliegue
-
- Aplicacioacuten Web
-
- DCOS
- Nomad
-
- Servicio de integracioacuten continua
-
- DevOps
- Integracioacuten Continua
- Jenkins con Nomad
- Jenkins con DCOS
-
- Escalando la infraestructura
-
- Disentildeo
- Implementacioacuten
-
- Resultados y conclusiones
-
- Comparacioacuten
- Conclusiones
- Objetivos conseguidos
- Liacuteneas de investigacioacuten
-
52 Nomad
Herramienta de coacutedigo abierto de gestioacuten de clusters creada y desarrolladapor Hashicorp13 que permite el despliegue de aplicaciones y procesos de formadistribuida
Las principales diferencias con Apache Mesos a grandes rasgos son
Arquitectura maacutes ligera Nomad soacutelo requiere de un fichero para funcionarejecutaacutendolo con las correspondientes configuraciones en todos los nodosrealiza las funciones de gestioacuten del cluster eleccioacuten de liacuteder planificacioacutende recursos y ejecucioacuten de las tareas
Centro de datos y regiones muacuteltiples Su arquitectura estaacute orientada afacilitar la gestioacuten de diferentes centros de datos geograacuteficamente distri-buidos
Entorno de ejecucioacuten Las tareas se definen y son interpretadas mediantecontroladores integrados en Nomad que se valen de los recursos y herra-mientas de los nodos clientes para ejecutarlas Esta integracioacuten dificultael desarrollo de controladores por parte de terceros a diferencia de Mesosque delega dicha responsabilidad en los entornos de trabajo externos alproyecto
Usa un planificador de estado compartido con respecto a la planificacioacutenen dos niveles de Mesos
Antes de entrar en maacutes detalle en la arquitectura es importante definir lossiguientes teacuterminos
Controlador (Driver) Software que se encarga de interpretar las definicionesde las tareas y ejecutarlas semejante a los procesadores de los entornosde trabajo de Mesos A la hora de redactar este proyecto Nomad contabacon controladores para contenedores Docker virtualizacioacuten de maacutequinasmediante el emulador QEMU aplicaciones java y archivos binarios
Grupo de trabajo (Task Group) Conjunto de tareas que se ejecutan en elmismo nodo cliente
Trabajo (Job) Conjunto loacutegico de tareas y grupos de trabajo que se despliegana la vez
Asignacioacuten (Allocation) Relacioacuten entre un grupo de trabajo y el cliente don-de se ejecuta
Evaluacioacuten (Evaluation) Proceso mediante el cual Nomad planifica y ges-tiona el registro o actualizaciones de los trabajos
13httpswwwhashicorpcom
19
Nomad sigue una arquitectura maestro-esclavo similar a la de Apache Mesosmuacuteltiples servidores acuerdan entre siacute un liacuteder que gestiona la planificacioacuten detareas en los clientes que soacutelo conocen sus asignaciones y las ejecutan
Todos los servidores participan paralelamente en tareas de planificacioacuten derecursos y asignacioacuten de tareas y ademaacutes entre ellos eligen un liacuteder que seencarga de la coordinacioacuten de la suscripcioacuten de los clientes al cluster y de lagestioacuten de las peticiones
Los clientes estaacuten configurados para comunicarse con el servidor usando lla-madas a procedimiento remoto (RPC por sus siglas en ingleacutes) que permite unordenador ejecutar coacutedigo en otra maacutequina Mediante esta tecnologiacutea los nodosclientes avisan de su estado e informa de sus asignaciones recursos y controla-dores disponibles
Existe la posibilidad de gestionar varios centros de datos agrupados en regio-nes eacutestas son independientes pero permite definir tareas o comprobar el estadode todas ellas desde cualquier punto A continuacioacuten se muestra una figura dela arquitectura a alto nivel de esta configuracioacuten
Figura 10 Arquitectura multi-regioacuten en NomadFuente httpswwwnomadprojectio
La herramienta se sustenta sobre tres protocolos fundamentales un protocolode consenso entre los servidores para compartir informacioacuten sobre su estado yel liacuteder un protocolo Gossip para la gestioacuten entre regiones y el planificador detareas
521 Protocolo de consenso Raft
El objetivo es obtener consistencia en un conjunto de nodos que comparteninformacioacuten es decir si un cliente realiza un cambio que todos los nodos veanla misma informacioacuten a la vez y ademaacutes sea tolerante a fallos Para ello se basaen el algoritmo Raft[13] que se detalla brevemente a continuacioacuten
20
Los nodos participantes en el algoritmo pueden estar en tres estados
Liacuteder (Leader) Todos los cambios que realicen en el cluster pasan por eacutel pri-mero
Seguidor (Follower) Nodo pasivo cuya responsabilidad es responder a laspeticiones del nodo liacuteder
Candidato (Candidate) Maacutequina que no ha encontrado liacuteder y solicita sueleccioacuten
Supongamos que tenemos cinco equipos que acaban de arrancar el protocoloEn la figura 11 se observan los nodos y sus respectivos registros a la derecha
Figura 11 Equipos sin consenso ejecutando el protocolo RAFTFuente httpsgithubcomongardieraftscope
Al comenzar todos los nodos son seguidores esperando recibir comunicacioacutende un nodo que actuacutee como liacuteder Cada nodo tiene un tiempo de espera aleatoriodespueacutes del cual si no es informado por un liacuteder pasa a estado candidato y pideel ldquovotordquo al resto de los participantes El algoritmo divide el tiempo en plazos uncandidato pasa a liacuteder si recibe la mayoriacutea de los votos en un plazo determinadoSe define mayoriacutea o cuoacuterum (quorum) comolceil
N2rceil
+ 1 (1)
donde N representa el nuacutemero de nodos
Para el ejemplo propuesto de 5 equipos se requieren de 3 votos Soacutelo losnodos que se encuentren en estado seguidor pueden votar una uacutenica vez a laprimera solicitud que reciba dentro de un plazo
Supoacutengase que el nodo denotado con S1 ha cumplido su tiempo de espera yrealiza la peticioacuten de voto (figura 12) A partir de este momento se pueden dartres casos
La maacutequina gana la eleccioacuten y pasa a ser liacuteder informando al resto
Otro servidor se establece como liacuteder en el mismo momento
Varios nodos pasan a ser candidatos por lo que ninguno consigue los votos
21
Figura 12 Un equipo pasa a estado candidato (RAFT)
Si un candidato recibe un aviso de un liacuteder en el mismo plazo el primeropasa a ser seguidor y se acaba la eleccioacuten de liacuteder
Por otro lado si un equipo candidato no recibe los votos en el plazo y agotasu tiempo de espera avanza al siguiente plazo y repite el proceso de votacioacutenLa tercera posibilidad puede conllevar a un estado indefinido ya que varioscandidatos pueden agotar su tiempo de espera al mismo tiempo y repartir losvotos Para solventarlo el algoritmo establece tiempos de espera aleatorios paralos candidatos
Siguiendo con el ejemplo propuesto el servidor S1 pasa a ser el liacuteder Cadacierto tiempo eacuteste debe realizar avisos a los nodos seguidores para no agotar sutiempo de espera
En este momento el cluster de servidores estaacute en ldquoconsensordquo y la informacioacutenen todos los nodos estaacute actualizada Un cambio en la informacioacuten inicia unproceso de replicacioacuten el liacuteder registra el cambio lo pasa al resto de nodos yuna vez eacutestos responden el cambio se hace efectivo
Supoacutengase que se realiza un cambio en los datos en la figura 13 en la partederecha se observa el cambio en el registro del servidor S1 que informa a losnodos seguidores En consecuencia los nodos registran el cambio y responden aS1
Figura 13 Cambio en un registro (RAFT)
Una vez el cuoacuterum (en el ejemplo tres equipos) informa al liacuteder de que
22
ha registrado el cambio el liacuteder lo hace efectivo en su sistema y notifica a losnodos que hacen lo mismo En la figura 14 el enviacuteo todaviacutea no ha llegado ala maacutequina S3 y se observa que no ha hecho efectivo el cambio (en el registroaparece punteado)
Figura 14 Aprobacioacuten del resto de equipos (RAFT)
Este protocolo funcionaraacute correctamente mientras exista un nuacutemero de nodosen funcionamiento igual o superior al cuoacuterum en el ejemplo propuesto elcuoacuterum es tres por lo que el sistema puede tolerar la caiacuteda de dos de los equipos
522 Protocolo gossip SWIM
Nomad permite la gestioacuten simultaacutenea de varios centros de datos reparti-dos en regiones geograacuteficamente separadas requiriendo de un protocolo ligeroque mantenga a los miembros actualizados sobre los participantes del conjun-to Para ello usa una ligera variante del protocolo SWIM[3] (Scalable Weakly-consistent Infection-style Process Group Membership Protocol) desarrollada porHashiCorp Estaacute clasificado como un protocolo de tipo gossip que debe su nom-bre a la semejanza con coacutemo se distribuye un rumor en una red social
SWIM se sustenta en dos caracteriacutesticas fundamentales la deteccioacuten de fallosy la distribucioacuten de la informacioacuten relativa a los miembros A continuacioacuten sedetalla el funcionamiento de ambos componentes
Deteccioacuten de fallos
Este componente tiene dos paraacutemetros el periodo de protocolo T y el nuacutemerode subgrupos de deteccioacuten de fallos k en los que se dividen los nodos Paracomprobar la comunicacioacuten entre dos maacutequinas usa la utilidad ping basadaen el protocolo ICMP La deteccioacuten de caiacuteda de un servidor sigue el siguientealgoritmo
Durante el periodo T cada miembro Mi de un subgrupo elige otro al azar Mjdel mismo subgrupo y le enviacutea un mensaje ping para comprobar su estado Enel caso de que se cumpla un tiempo de espera determinado por una estimacioacuten
23
del tiempo de ida y vuelta (RTT por sus siglas en ingleacutes) de la red y no hayarespuesta Mi le vuelve a enviar un mensaje ping indirectamente a traveacutes deun nuacutemero k de miembros escogidos aleatoriamente De no recibir ninguna res-puesta Mi establece que Mj ha sufrido un fallo y lo etiqueta como ldquosospechosordquoinformando al componente de distribucioacuten
Figura 15 Diagrama de tiempo del protocolo SWIMFuente httpswwwcscornelledu
Componente de distribucioacuten
Se encarga de informar de cualquier cambio en los miembros a todo el con-junto Los eventos de nodo caiacutedo y la unioacuten o disociacioacuten de un miembro setransmiten a todos los servidores para que actualicen sus lista Para distribuirla informacioacuten a todos los nodos se podriacutea usar el meacutetodo de multicast perosuele estar deshabilitado Por ello se utiliza una teacutecnica de transmisioacuten denomi-nada Piggybacking mediante la cual se adjunta a los propios mensajes PINGy ACK del algoritmo la informacioacuten a distribuir reduciendo asiacute la congestioacutenen la red
523 Planificacioacuten
Proceso encargado de distribuir las tareas entre los nodos clientes de acuerdoa su estado
El planificador de Nomad estaacute basado en las publicaciones de Google sobresus herramientas de gestioacuten de clusters Borg y Omega14 y entiende los trabajosdescritos por el usuario como un estado deseado es decir su despliegue en unamaacutequina cliente de forma correcta y los clientes como el estado actual esto eslo que se encuentra en ejecucioacuten El registro actualizacioacuten o cancelacioacuten de un
14httpresearchgooglecompubspub43438html
24
trabajo asiacute como el fallo de un nodo cliente implican un cambio de estado atramitar por el sistema lo que se define como evaluacioacuten (evaluation) Esto uacutelti-mo supone comparar el estado actual (clientes) con el estado deseado (conjuntode trabajos registrados) y enviarlos a los planificadores correspondientes que seencargaraacuten de asignar las tareas a los nodos clientes
Figura 16 Procedimiento de asignacioacuten en NomadFuente httpswwwnomadprojectio
En la figura 16 se observa el flujo de trabajo en el que las distintas evalua-ciones se encolan en el evaluation broker que se ejecuta en el servidor liacuteder ygestiona las evaluaciones pendientes asignaacutendoles prioridades
A continuacioacuten los nodos servidores ejecutan los scheduling workers queprocesan las evaluaciones llamando a los distintos planificadores que generanun plan de asignacioacuten esto es un conjunto de relaciones entre las tareas y losnodos clientes donde se ejecutaraacuten Este proceso se divide en dos fases primerose descartan aquellos clientes que no cumplan los requisitos y posteriormentese asigna una calificacioacuten al resto Se selecciona el nodo con mayor puntuacioacuteny se encola el plan en el gestor que se ejecuta en el servidor liacuteder Existen tresplanificadores de acuerdo al tipo de trabajo
Service Incluye aquellos trabajos que estaacuten destinados a ejecutarse en un pe-riacuteodo largo de tiempo Para realizar las asignaciones el planificador evaluacuteala mayor parte de los nodos y usa una versioacuten del algoritmo Best fit in-fluenciada por el trabajo de Google en su herramienta Borg Se trata deun algoritmo de planificacioacuten que sacrifica tiempo a cambio de maximizarel rendimiento de los clientes asignando la tarea a la maacutequina que tengala mayor carga de trabajo con el objetivo de reducir equipos en funciona-
25
miento
Batch Tareas que incluyen listas de comandos en general de menor duracioacuteny que no requieren interaccioacuten con el usuario Se vale del algoritmo deSparrow desarrollado por la universidad de Berkeley15 para limitar losnodos clientes a evaluar
System Trabajos destinados a ejecutarse en todos los nodos incluso los que seunen al cluster posteriormente
Core Mantenimiento interno de Nomad
Una vez se ha realizado el proceso de planificacioacuten el nodo liacuteder lo registra enla cola de planes (plan queue) que se encarga de asignarles prioridad y manejarcondiciones de carrera es decir que no accedan a los recursos de los clientes sincontrol y evitar que eacutestos superen su capacidad
La maacutequina liacuteder del conjunto puede de este modo aceptar una asignacioacuteny ser ejecutada por los clientes o por el contrario rechazaacutersela al planificadorlo que implicariacutea realizar un plan parcial o totalmente nuevo
Finalmente el estado de las evaluaciones se actualizan y los clientes soninformados de las asignaciones ejecutaacutendose las tareas
15httppeopleeecsberkeleyedu~keopublicationssosp13-final17pdf
26
6 Casos de uso y despliegue
Con el objetivo de mostrar las posibles utilidades que este tipo de sistemaspueden tener en las infraestructuras TI actuales se han desplegado las dos he-rramientas en la nube Microsoft Azure usando su servicio cloud de instancias demaacutequinas virtuales Linux para simular un conjunto de ordenadores conectadosentre siacute por una red LAN Sobre ellas se ha implementado dos casos de usouna aplicacioacuten web con una arquitectura con cierta orientacioacuten a microserviciosy un sistema de integracioacuten continua
El coacutedigo y todos los ficheros de configuracioacuten se pueden encontrar en elrepositorio del proyecto en GitHub16
61 Aplicacioacuten Web
Se busca simular el proceso de adaptacioacuten de una solucioacuten web para su des-pliegue en un sistema distribuido con las herramientas anteriormente descritascon el objetivo de aumentar tanto su escalabilidad como disponibilidad medianteredundancia
Se ha partido de una aplicacioacuten ya existente17 un servicio de almacenamien-to y reproduccioacuten de canciones A grandes rasgos este servicio permite crearusuarios subir canciones con sus respectivas portadas tener playlists propias yescuchar las canciones a traveacutes de un navegador web
La solucioacuten estaacute dividida en 4 partes (figura 17)
Una vista web con la loacutegica
Un almacenamiento conectado en red (NAS por sus siglas en ingleacutes)
Una API REST para gestionar las peticiones al almacenamiento
Base de datos NoSQL basada en MongoDB
La nueva tendencia de los proyectos web es su implementacioacuten en contene-dores Docker ya que facilitan su portabilidad y ofrecen un procedimiento dedespliegue raacutepido sobre todo a la hora de desarrollar y realizar pruebas en en-tornos de produccioacuten simulados Por ello en este caso se va a hacer uso de los
16httpsgithubcomAntonioAlfrzCloud-Orchestrators17httpsgithubcomsonsoleslpCDPSfy
27
motores de orquestacioacuten de contenedores de ambas herramientas Marathon enDCOS y el controlador Docker en el caso de Nomad
Figura 17 Arquitectura aplicacioacuten web
A continuacioacuten vamos detallar el despliegue en ambas herramientas de es-ta solucioacuten y observar tanto queacute dificultades se encuentran como que ventajasofrecen El objetivo final es adaptar el proyecto modificaacutendolo lo menos posiblecon objeto de analizar la capacidad de estas herramientas para desplegar cual-quier aplicacioacuten sin que eso conlleve la modificacioacuten de la arquitectura de eacutestaes decir que no sea dependiente del entorno
611 DCOS
Se ha descrito DCOS como una herramienta que se despliega sobre un con-junto de ordenadores y que permite instalar gestionar el despliegue de sistemasdistribuidos
Microsoft Azure cuenta con una plantilla para desplegar en su servicio cloudun cluster de maacutequinas virtuales con DCOS ya instalado que cuenta con
Maacutequinas maestras (1 3 o 5 a seleccionar por el usuario) configuradascomo un conjunto de disponibilidad esto eso Azure da ciertas garantiacuteasde que al menos una maacutequina estaraacute en funcionamiento
Maacutequinas agentes Por motivos de seguridad se distinguen dos roles
bull Nodos privados solo accesibles desde la red interna y configuradoscomo un conjunto de escala un recurso de Azure para gestionar ydesplegar maacutequinas con configuraciones ideacutenticas para permitir unraacutepido escalado
bull Un equipo conectado accesible desde Internet a travntildees de un balan-ceador de carga puacuteblico y situado en una subred externa
28
Dos balanceadores de carga
bull La interfaz puacuteblica del cluster que se conecta con el cliente puacuteblicobull Acceso a los equipos maestros para el administrador que soacutelo permiteconexioacuten mediante SSH y credenciales
Almacenamiento para todas las maacutequinas
Configuraciones necesarias de red y seguridad
En la figura 18 se observa un diagrama de la infraestructura
Figura 18 Infraestructura en Azure
El primer obstaacuteculo es la persistencia de estado de la aplicacioacuten que seconsigue gracias a una base de datos no relacional basada en MongoDB asiacutecomo el almacenamiento de las canciones Para implementarla tenemos variasposibilidades
Montar un sistema externo de almacenamiento conectado en red en todoslos agentes donde se ejecuten las tareas de esta manera si una tarea pasade un nodo a otro por cualquier motivo puede tener acceso a los mismosficheros (opcioacuten del caso de uso original)
Implementar un sistema de ficheros distribuidos en los agentes
Usar los servicios de almacenamiento de las nubes puacuteblicas
Aprovechar el sistema de voluacutemenes persistentes de Apache Mesos Eacutestepermite reservar recursos de un agente de forma que al arrancar una tarease crea un volumen independiente del ciclo de vida de eacutesta con ello esosrecursos donde se ha almacenado la informacioacuten pueden volver a ofrecerseal mismo entorno de tal manera que otra tarea pueda acceder a ella
DCOS aprovecha este sistema de voluacutemenes persistentes y permite instalarbases de datos distribuidas como ArangoDB o Apache Cassandra sin embargoesto implicariacutea modificar todo el coacutedigo referente al modelo de la base de datos
29
Por motivos de eficiencia y latencia asiacute como de una mayor gobernabilidadde los datos la mejor opcioacuten es usar el recurso de voluacutemenes persistentes queofrece Apache Mesos ya que de esta manera se gestionariacutea la aplicacioacuten completamediante una uacutenica herramienta Sin embargo esto implica que la informacioacutense encuentra exclusivamente en el agente donde se haya ejecutado la tarea y porlo tanto se sigue requiriendo de software externo para distribuir la informacioacutenpara que se accesible para todos los agentes A la hora de realizar este proyectose encontraba en desarrollo Flocker una solucioacuten desarrollada por ClusterHQque permite compartir los voluacutemenes de Docker a traveacutes de un cluster quesi bien es compatible con el planificador de Mesos el proyecto se encontrabatodaviacutea en fases tempranas de desarrollo y los sistemas de almacenamiento quesoporta quedaban fuera del aacutembito de este trabajo
Por todo ello dado que las maacutequinas se han desplegado en la nube puacuteblicade Azure se decidioacute usar su servicio de almacenamiento de objetos para lascanciones y otra maacutequina para desplegar MongoDB y asiacute mantener el modelode datos original de la aplicacioacuten La diferencia del almacenamiento de obje-tos con respecto a nivel de fichero es que el primero no tiene jerarquiacutea paraorganizar los archivos eacutestos se guardan como objetos (con sus metadatos) enun mismo espacio soacutelo diferenciaacutendose por un identificador uacutenico esto implicaentre otras cosas que se puede acceder a un fichero dado uacutenicamente su IDindependientemente de la localizacioacuten fiacutesica de eacuteste facilitando pues la gestioacuteny el desarrollo
El coacutedigo del proyecto se ha modificado en los siguientes apartados
Las direcciones de la base de datos y los balanceadores de carga asiacute comosus puertos estaban originalmente fijos Se han configurado como variablesde entorno para facilitar el descubrimiento del servicio y hacer transpa-rente la aplicacioacuten al entorno de despliegue
La API REST se ha adaptado al almacenamiento en Azure en vez de enlocal
Estas modificaciones no suponen un cambio sustancial pero permiten separala persistencia de las tareas ejecutadas por DCOS lo que facilita en granmedida su ejecucioacuten al ser totalmente sin estado y ademaacutes implican tenerlos datos bajo un mayor control
Para la orquestacioacuten de contenedores se va a usar el entorno Marathondesarrollado tambieacuten por Mesosphere Eacuteste se puede usar a traveacutes de una interfazgraacutefica la interfaz de liacutenea de comandos (en lo que sigue CLI por sus siglas eningleacutes) de DCOS o con su API HTTP
Primero se han publicado la imaacutegenes de los contenedores que encapsulanla interfaz web y la api de la aplicacioacuten en el repositorio puacuteblico DockerHub
Los despliegues en este entorno se describen mediante ficheros JSON en losque se detalla entre otras opciones la imagen del contenedor los puertos a usar
30
los recursos que debe ocupar en un nodo o las instrucciones de monitorizacioacuten
Para el servicio de descubrimiento DCOS ofrece la posibilidad de asignardirecciones IP virtuales (VIP por sus siglas en ingleacutes) a tareas que se compartenen todos los nodos DCOS lleva integrado un balanceador de carga a nivel TCP(el componente denominado Minuteman) que balancea entre las direccionesvirtuales de las tareas y todas las instancias de eacutestas a lo largo del cluster Estoes necesario por dos motivos equilibrar la carga de los equipos con el fin deevitar un punto de uacutenico fallo mediante redundancia y evitar la contienda dedirecciones al ejecutar las tareas en puertos aleatorios
Este balanceador de carga estaacute basado en el trabajo de Michael Mitzenma-cher The Power of Two Choices in Randomized Load Balancing18 A grandesrasgos el algoritmo mantiene una media moacutevil exponencial de latencias paracada destino (backend) ademaacutes de las caiacutedas consecutivas Si un destino noresponde a una negociacioacuten en tres pasos (three way handshake) de forma con-secutiva en un periodo inferior a 5 ms se considera caiacutedo El algoritmo iterasobre los destinos disponibles en base a su histoacuterico de fallos y escoge dos deforma aleatoria de los cuales coge el de mejor meacutetrica
Las direcciones virtuales soacutelo se pueden resolver dentro del cluster porello para implementar la interfaz puacuteblica de la aplicacioacuten esto es el balancea-dor de carga de la interfaz web usaremos un paquete de DCOS denominadomarathon-lb un balanceador basado en HAProxy y adaptado por MesosphereEn este caso equilibra la carga de todas instancias de las tareas ejecutadas porel entorno Marathon por sus etiquetas y permite ademaacutes definir como puntode entrada muacuteltiples hosts virtuales definidos por sus nombres completos dedominio (FQDN por sus siglas en ingleacutes) en nuestro caso la interfaz puacuteblicadel balanceador de Azure para los agentes
Por motivos de seguridad todas las tareas se ejecutan en los agentes privadoses decir los que son exclusivamente accesibles desde la red interna Por su partemarathon-lb se ejecuta en el agente puacuteblico que cuenta con IP puacuteblica y lospuertos 80 (HTTP) y 8080 abiertos de forma que la aplicacioacuten sea accesibledesde Internet Esto es posible debido a que Apache Mesos permite reservarrecursos mediante roles asignados a nodos para un uso especiacutefico De esta formala arquitectura vista desde la aplicacioacuten quedariacutea como en la figura 19
18httpswwweecsharvardedu~michaelmpostscriptstpds2001pdf
31
Figura 19 Arquitectura de la aplicacioacuten web en DCOS
Ejecucioacuten
A la hora de desplegar la aplicacioacuten DCOS puede gestionarse medianteuna interfaz graacutefica o una interfaz de liacutenea de comandos La primera se accedea traveacutes de un navegador web en el puerto 80 (HTTP) y permite instalar losentornos disponibles observar el estado de los nodos y las tareas que se estaacutenejecutando y los ficheros de registros que eacutestas generan
La CLI permite el control desde un nodo o una maacutequina remota (suponiendoque los maestros tienen IP puacuteblica y el puerto 80 abierto) ya que DCOS tieneun sistema de autorizacioacuten que permite tener una interfaz puacuteblica con ciertasgarantiacuteas de seguridad
Por su parte cada entorno de trabajo puede ser controlado por la CLI peroademaacutes cuenta con sus propias interfaces Marathon expone una API HTTPen el puerto 8080 de la direccioacuten puacuteblica de los maestros del cluster asiacute comootra interfaz graacutefica Para desplegar un contenedor se podriacutea usar la CLI
$ dcos marathon app add lt f i l e j songt
O la API HTTP
$ cu r l minusX POST http lt ip_maestro gt8080v2apps minusd ltf i l e jsongt minusH Contentminustype app l i c a t i o n j son
32
612 Nomad
La arquitectura de Nomad es maacutes sencilla ya que solo requiere de un ficheroejecutable en todos los nodos para funcionar Si DCOS es la base de instala-cioacuten de entornos de terceros Nomad integra todas las funcionalidades baacutesicasesto es gestor de recursos planificador y ejecutor en los nodos cliente Estaherramienta cuenta con un menor tiempo de desarrollo y en el momento deescribir este documento cuenta exclusivamente con los siguientes controladoresen comparacioacuten con los entornos de DCOS
Motor Docker es decir funcioacuten de orquestacioacuten de contenedores
Ejecucioacuten de archivos binarios como comandos de Shell
Ejecucioacuten de aplicaciones Java
Virtualizacioacuten de maacutequinas mediante tecnologiacutea QEMU
Todos ellos necesitan que la tecnologiacutea subyacente esteacute instalada en las maacute-quinas clientes (Docker Java QEMU) Actualmente no permite el registro decontroladores por parte de terceros aunque estaacute planificado en un futuro ofreceruna interfaz para su desarrollo
Nomad no cuenta con el servicio de descubrimiento sin embargo puede inte-grarse con la herramienta Consul desarrollada por la misma empresa Por otrolado para el balanceo de carga usaremos un contenedor Docker con HAProxyuna herramienta de coacutedigo abierto que ofrece tanto servicios de proxy como debalanceador y cuyos ficheros de configuracioacuten completaremos con el proyectoConsul Template19
Consul
Consul sigue la misma arquitectura que Nomad es decir un nodo servidorque orquesta un conjunto de maacutequinas clientes y permite a los procesos que seejecutan en los equipos definirlos como servicios ofreciendo diversas caracteriacutes-ticas entorno a estos de los cuales vamos a usar dos
Descubrimiento de servicio Las maacutequinas clientes publican en el cataacutelogode servicios las tareas en ejecucioacuten y Consul les asigna nombres de dominioaccesibles por todos los miembros del cluster a traveacutes de la interfaz DNSincluida en esta herramientaConsul se integra con Nomad de forma que todas las tareas que se ejecu-ten en la segunda son automaacuteticamente publicados como servicios de laprimera de esta manera no hace falta conocer la direccioacuten de la maacutequinacliente donde se esteacute ejecutando el proceso ya que se puede acceder a eacutela traveacutes de su nombre de dominio de forma transparente Por ejemplo si
19[httpsgithubcomhashicorpconsul-template]
33
ejecutamos una tarea con ID web en el puerto 8080 se puede acceder aella en la direccioacuten webserviceconsul8080Para que las direcciones propias de Consul las resuelva su propio DNS y noel que esteacute asignado por defecto en la maacutequina usaremos la herramientadnsmasq20 que permite especificar la direccioacuten de un servidor DNS paraconsultas de direcciones especiacuteficas
Monitorizacioacuten Permite realizar comprobaciones del servicio y seguir su esta-do Aprovecharemos esta funcionalidad tanto para definir el propio procesode Nomad como servicio de Consul como las tareas desplegadas
HAProxy + Consul Template
HAProxy es una solucioacuten versaacutetil de coacutedigo abierto que ofrece solucionesde balanceo de carga y proxy Existen otras herramientas en el mercado comoNGINX o ldirectord sin embargo HAProxy suponiacutea una solucioacuten sencilla deconfigurar para mostrar el caso de uso
El uso de estas herramientas se debe a dos motivos para que no existacontienda con respecto a los puertos de los clientes usados por las tareas eacutestos sevan a asignar de forma dinaacutemica lo que en principio implicariacutea que la aplicacioacutendeberiacutea realizar consultas DNS de tipo SRV (que incluye puertos) a la interfazde Consul y balancear la carga entre tareas por redundancia y capacidad
Como la direccioacuten IP y puerto son variables cada vez que las tareas seactualicen o se reasignen es necesario volver a configurar HAProxy de formamanual Por ello HashiCorp ha desarrollado un programa denominado Con-sul Template que realiza peticiones sucesivas a la interfaz HTTP de Consul delas direcciones fiacutesicas de un servicio y reinicia automaacuteticamente el proceso deHAProxy Asiacute definiendo estas tareas como servicios Consul podremos tantomonitorizarlas como escalar las tareas dinaacutemicamente sin necesidad de cambiarel balanceador A partir del contenedor Docker oficial de HAProxy se ha desa-rrollado otro con la configuracioacuten baacutesica y con Consul Template para desplegarlocomo una tarea en Nomad
Despliegue
Se ha usado el mismo coacutedigo que en el apartado anterior con la persistenciaen el servicio de almacenamiento de Azure Desde la perspectiva del hardwarese implementaraacute la misma infraestructura que en el caso de DCOS (figura 18)estos es definiremos dos tipos de maacutequinas clientes un agente que se conectaraacutecon el balanceador de carga con nombre de dominio puacuteblico y donde se desple-garaacute el balanceador de carga de la vista web y agentes privados no accesiblesdesde fuera del cluster y donde se ejecutaraacuten el resto de tareas en la red inter-na La principal diferencia radica en las tareas que ejecutan HAproxy y ConsulTemplate que sustituye a las direcciones IP virtuales que ofrece DCOS
20httpwwwthekelleysorgukdnsmasqdochtml
34
Figura 20 Despliegue en Azure de Nomad+Consul
Cabe matizar que los balanceadores basados en HAProxy se implementanpor necesidad de la aplicacioacuten para el descubrimiento del servicio a diferenciade los de Azure que se implementan por motivos de seguridad y escalabilidaddel cluster en siacute
Configuracioacuten Nomad
Los ficheros de configuracioacuten de las maacutequinas maacutester y cliente son similaresy comparten la mayoriacutea de las opciones como por ejemplo el nombre del nodoo la interfaz de red donde escucha Nomad las peticiones Sus opciones son engeneral auto-explicativas sin embargo existen dos detalles que matizar
El proceso de Nomad escucha las peticiones tanto de los protocolos deconsenso como del usuario a traveacutes de una interfaz de red que se debeindicar en el fichero de configuracioacuten
En el caso de los clientes se deben indicar las direcciones de los servidoresdel cluster sin embargo se trata de un sistema dinaacutemico en el que losnodos pueden sufrir errores y cambiar de direccioacuten Por ello se ha definidoNomad como un servicio de Consul y asiacute poder definir la direccioacuten de losservidores como un nombre de dominio no por su direccioacuten fiacutesica que elservidor DNS de Consul se encargaraacute de resolver
Por defecto Nomad usa los siguientes puertos
API HTTP 4646 Peticiones HTTP y recepcioacuten de oacuterdenes mediante laliacutenea de comandos
RPC 4647 Protocolo de consenso entre los nodos del cluster
Serf 4648 Protocolo de gossip entre los servidores de los centros de datosgobernados por Nomad
35
Los dos uacuteltimos deben ser interfaces alcanzables por otros nodos sin embargo laAPI HTTP por motivos de seguridad deberiacutea ser local ya que en caso contrariocualquier persona con acceso a ella tiene el control sobre la herramienta Eacutestasolo deberiacutea estar accesible en un servidor o gestionarlo mediante una terminalSSH por ejemplo En este trabajo al ser una prueba de concepto se ha abiertoen todos los nodos
Trabajos de Nomad
Las tareas se detallan en ficheros con formato HashiCorp Configuration Lan-guage un derivado del formato JSON creado por la empresa que le da nombrecompatible con eacuteste y que permite comentarios
En estos ficheros se puede definir
La regioacuten y el centro de datos donde se ejecutaraacute (Nomad permite lagestioacuten de centros de datos geograacuteficamente distribuidos en regiones)
La poliacutetica de actualizacioacuten de la tarea
Grupo de tareas esto es que se ejecutaraacuten en el mismo nodo
El nuacutemero de grupos a ejecutarescalar asiacute como los liacutemite que debencumplir los nodos asignados
La poliacutetica de reinicio ante fallo o error
Tareas El controlador su configuracioacuten los paraacutemetros del servicio aso-ciado a registrar en Consul asiacute como los recursos que consume (puertosmemoria)
En nuestro caso usamos sobre todo el controlador Docker esto eso orques-tacioacuten de contenedores en los nodos clientes y tres de sus opciones
Imagen del contenedor Se han subido todas las imaacutegenes del proyecto a Doc-ker Hub donde por defecto se busca la imagen
Puertos Los puertos a usar por el contenedor que pueden ser estaacuteticos asigna-dos por el usuario o dinaacutemicos siendo Nomad el que se encarga de mapearun puerto libre del nodo cliente al expuesto por el contenedor
Servidores DNS Como usamos la interfaz DNS de Consul como descubri-miento de servicio se debe configurar el contenedor para que use cualquiernodo del cluster como servidor DNS
Configuracioacuten Consul
Al ser desarrolladas por la misma empresa los ficheros de configuracioacuten deConsul y Nomad comparten muchas opciones Consul tambieacuten acepta peticionesa traveacutes de una interfaz de red siendo los puertos usados por defecto
36
RPC 8300 8400 Maneja la peticiones del resto de nodos y usuarios
Serf 8301 8302 Protocolo gossip
HTTP API 8500
HTTPS API Desactivada por defecto
Interfaz DNS 8600
Se debe asignar a los protocolos internos del cluster esto es RPC y Serf unainterfaz alcanzable por los nodos y por el contrarioasignar a los dos uacuteltimos ala interfaz de loopback por motivos de seguridad
Cabe destacar que Consul tambieacuten cuenta con una interfaz graacutefica que per-mite ver el estado de los equipos y los servicios registrados y que se encuentra enel mismo puerto que la API HTTP en la direccioacuten httpIP_EQUIPO8500ui
Ejecucioacuten
Tanto Nomad como Consul requieren de la ejecucioacuten de un fichero en todoslos nodos integrantes del cluster Como prueba de concepto se ha decidido usardos servidores para ambos aunque cabe matizar que es un nuacutemero ineficienteya que la caiacuteda de uno de ellos supondriacutea la peacuterdida del cuoacuterum y por tantodel consenso del cluster
En primer lugar se arrancan los servidores que son los encargados de ejecu-tar el protocolo de consenso y gestionar el cluster y a continuacioacuten los clientesque no tienen praacutecticamente estado y dependen de los servidores
En el caso de Consul se debe indicar el directorio donde se guardan losficheros que describen los servicios asiacute como el archivo que especifica el resto delas opciones
1 Se inicia el primer servidor en uno de los equipos
$ consu l agent minuscon f i gminusd i r e t c consu l d s e r v i c e s minuscon f i gminus f i l e consu l_server j son
2 Los siguientes equipos deben unirse al anterior por lo que antildeadimos elargumento join con la direccioacuten del primer servidor Para el caso de otrosservidores
$ consu l agent minuscon f i gminusd i r e t c consu l d s e r v i c e s minuscon f i gminus f i l e consu l_server j son minus j o i n ltIP_servidor1gt
37
Una vez los servidores han alcanzado el consenso y elegido un liacuteder en losclientes
$ consu l agent minuscon f i gminusd i r e t c consu l d s e r v i c e s minuscon f i gminus f i l e c on su l_c l i en t j son minus j o i n ltIP_cualquierServ idorgt
El proceso para iniciar Nomad es igual y los comandos similares sin embargoya no es necesario indicar una direccioacuten IP fija en los equipos sino el nombre dedominio del servicio de Nomad registrado por Consul En el primer servidor
$ nomad agent minusc on f i g nomad_server j son
Y el resto de equipos (con su fichero de configuracioacuten correspondiente)$ nomad agent minusc on f i g nomad_server j son minus j o i n nomad s e r v i c e consu l
Por uacuteltimo para desplegar la aplicacioacuten web se han escrito tres ficherosque detallan las tareas de la interfaz web API y los balanceadores de cargaMediante la CLI
$ nomad run minusaddress=http lt ip_c lus te r gt4646 lt f i l e hclgt
O mediante la API HTTP de Nomad$ cu r l minusX POST minusd ltf i l e hclgthttp lt ip_c lus te r gt4646 jobltjob_namegt
Ansible
Como se puede comprobar con el aumento del nuacutemero de equipos pasa aser inviable manejar todos los nodos a traveacutes de terminal Ademaacutes como seha comentado con anterioridad Nomad requiere que en los nodos clientes es-teacuten instalados las herramientas que soporten las tareas por ejemplo el motorde Docker Por ello para facilitar tanto el arranque como la instalacioacuten de lasdependencias vamos a usar Ansible una herramienta de coacutedigo abierto desarro-llada en Python que permite gestionar configuraciones aprovisionar recursosdespliegue de aplicaciones de forma automaacutetica
A grandes rasgos esta herramienta funciona mediante ficheros en formatoYAML denominados play-books que describen un conjunto de pasos a ejecutaren una lista de equipos remotos Estos pasos son ejecutados por moacutedulos inde-pendientes a traveacutes de SSH es decir en cualquier ordenador con conexioacuten a los
38
hosts dado su contrasentildea o clave puacuteblica puede arrancar el script y realizariacutealos pasos de forma remota gestionando el cluster desde un solo equipo
Se han desarrollado guiones para lo siguiente
Descarga de los binarios de Nomad y Consul en todos los nodos copiade los ficheros de configuracioacuten baacutesicos y modificarlos de acuerdo a cadanodo (nombre del equipo direccioacuten IP)
Instalacioacuten de las dependencias
Arranque de Nomad y Consul
Ansible extiende su funcionalidad a traveacutes de moacutedulos independientes que per-miten por ejemplo instalar paquetes mediante herramientas de gestioacuten de pa-quetes (APT yum) aprovisionar automaacuteticamente maacutequinas virtuales de Ama-zon EC2
Algunas opciones de los ficheros de configuracioacuten de Nomad y Consul sondependientes del nodo particular por ejemplo la interfaz de red Para estetrabajo se ha realizado un moacutedulo para modificar los ficheros de configuracioacutende forma automaacutetica En el repositorio del proyecto se encuentra una carpetadonde se encuentran todos los ficheros necesarios para desplegar un clustertotalmente funcional solo requiere de una liacutenea de terminal con Ansible
$ ans ib l eminusplaybook minus i hos t s minusk ltssh_passgt minusu ltnode_usergt s i t e yml
39
62 Servicio de integracioacuten continua
Se ha implementado un sistema de integracioacuten continua que permite ejecu-tar tareas de compilacioacuten y pruebas de forma distribuida aumentando asiacute elrendimiento de los equipos En primer lugar se detallaraacute los motivos por los quepuede resultar beneficioso para las empresas una implementacioacuten de este tipo alo que seguiraacute los detalles del despliegue
621 DevOps
Metodologiacutea que defiende la comunicacioacuten y colaboracioacuten entre desarrolla-dores de software y los profesionales de operaciones a lo largo de todo el ciclo devida de una aplicacioacuten Estaacute muy relacionado con el desarrollo aacutegil de softwareesto es un enfoque para los proyectos que defiende el desarrollo iterativo e in-cremental donde los requisitos y soluciones evolucionan con el tiempo seguacuten lanecesidad del proyecto DevOps extiende esta filosofiacutea a todas los componentesde un servicio incluyendo sistemas y operaciones
Se trata de un concepto que cada organizacioacuten o empresa adapta a suspropias necesidades y procesos de negocio en este proyecto nos vamos a centraren la integracioacuten continua una praacutectica fundamental tanto del desarrollo aacutegilcomo de esta filosofiacutea
622 Integracioacuten Continua
Se define como una praacutectica de desarrollo software donde los miembros delequipo ponen en comuacuten su trabajo frecuentemente al menos una vez al diacutea21Cada integracioacuten se verifica con una compilacioacuten automaacutetica que incluye laejecucioacuten de pruebas para detectar errores de integracioacuten tan pronto como seaposible
Desde el punto de vista operativo esto supone automatizar la configuracioacutende equipos o el despliegue de maacutequinas virtuales donde compilar el proyecto yejecutar las pruebas y posteriormente eliminarlas Este flujo de trabajo se vebeneficiado en entornos distribuidos ya que el objetivo del desarrollador es com-probar el resultado de las pruebas raacutepidamente sin preocuparse del despliegueo los propios equipos
Para esta prueba de concepto vamos a usar Jenkins un servidor de integra-cioacuten continua escrito en Java que nos permite definir trabajos que contendraacutenla descripcioacuten tanto del entorno como su ejecucioacuten
Este sigue una estructura maestro-esclavo muy similar al de los gestores declusters usados en este proyecto el maestro contiene toda la loacutegica del servicio
21httpmartinfowlercomarticlescontinuousIntegrationhtml
40
trabajos autenticacioacuten y los esclavos son los encargados de la ejecucioacuten ensiacute Jenkins tiene varias viacuteas para aprovisionar los uacuteltimos
Mediante SSH
Interfaz graacutefica
Desarrollar un script propio
Ejecucioacuten de un fichero java
La ventaja de usar planificadores es que el despliegue de esclavos es dinaacutemicoes decir no tener una maacutequina especiacuteficamente configurada para ello DCOS yNomad se encargaraacuten de configurar estos despliegues en sus maacutequinas y poste-riormente eliminarlos Para ello se ha usado la uacuteltima opcioacuten definiendo tareasque descarguen el fichero java Con todo ello se consigue un entorno de inte-gracioacuten continua eficiente que ademaacutes permite la ejecucioacuten de otros servicios deforma independiente
Jenkins permite la creacioacuten de plugins que extienden sus funcionalidadesTanto Nomad22 como Apache Mesos cuentan con uno que permite su integra-cioacuten
Para esta prueba se va a usar el mismo proyecto que para el caso de usode orquestacioacuten de contenedores la aplicacioacuten web al que se le ha antildeadido untest para comprobar que se conecta correctamente a la base de datos medianteMocha un framework de Nodejs Por otro lado se antildeade el plugin de git ya queel coacutedigo se obtiene de GitHub el repositorio remoto de control de versiones delproyecto
El proceso general de ejecucioacuten seriacutea como sigue
1 Se ejecuta el maestro de Jenkins como tarea Docker partiendo de la imagenoficial
2 Al arrancar un trabajo se manda una tarea a los planificadores que laasignaraacuten a un nodo cliente Esta tarea consiste en la descarga del ficherode configuracioacuten Java y arrancarlo configurando el equipo como un clientede Jenkins temporalmente
3 Jenkins ejecuta el trabajo en el nuevo cliente en este caso iniciar la apli-cacioacuten web iniciar las pruebas y generar un informe
4 Se elimina el cliente
A continuacioacuten se detallan los matices de cada herramienta a la hora de imple-mentar este servicio
22Desarrollado por Ivo Verberk httpwwwivoverberknl
41
623 Jenkins con Nomad
El plugin permite la ejecucioacuten del fichero Java mediante dos controladorescontenedores Docker y Java En este proyecto nos hemos decantado por el pri-mero ya que nos ahorra instalar la maacutequina virtual de java en todos los nodoscliente Por ello se ha construido un contenedor base con Java para la ejecucioacutendel fichero de configuracioacuten y Nodejs para lanzar la aplicacioacuten web
El plugin se configura con la direccioacuten IP del cluster y el contenedor queejecuta el esclavo Jenkins Por su parte el trabajo en Jenkins se define conel repositorio en GitHub donde se aloja el coacutedigo del proyecto a probar y loscomandos a ejecutar en este caso npm update y npm test
624 Jenkins con DCOS
En el caso de DCOS su sistema de paquetes incluye Jenkins por lo queal instalarlo ya se tiene la configuracioacuten de Mesos totalmente funcional Sinembargo para ejecutar la aplicacioacuten en particular y las pruebas se requiere deNodejs en los equipos esclavos por ello debemos antildeadir un plugin de Jenkinsque permite instalar este entorno antes de ejecutar el trabajo Una vez hechoesto soacutelo queda definir la tarea igual que en el caso anterior
Cabe destacar que Mesosphere tambieacuten ha desarrollado un plugin que per-mite hacer despliegues en Marathon de tal manera que permitiriacutea con cadacommit del coacutedigo compilar la imagen del contenedor Docker y desplegarlaautomaacuteticamente aunque en este proyecto no se ha hecho pruebas de esta fun-cionalidad
42
7 Escalando la infraestructura
Uno de los factores clave que se busca a la hora de implementar sistemasdistribuidos es el poder escalar la infraestructura de forma maacutes sencilla estoes detectar que las maacutequinas estaacuten alcanzando el liacutemite de su capacidad yaumentar eacutesta ya sea mejorando sus caracteriacutesticas teacutecnicas o antildeadiendo maacutesnodos al cluster
El coacutedigo y todos los ficheros de configuracioacuten de esta seccioacuten tambieacuten sepueden encontrar en el repositorio del proyecto en GitHub23
71 Disentildeo
Microsoft Azure permite organizar los servicios cloud de forma loacutegica a traveacutesde grupos de recursos y asiacute poder crear o eliminar eacutestos en conjunto parauna aplicacioacuten determinada (por ejemplo una aplicacioacuten web suele requerir demaacutequinas virtuales bases de datos almacenamiento) Ademaacutes dispone dela opcioacuten de crear plantillas en formato JSON que permite al desarrolladordefinir los recursos y su interrelacioacuten para desplegar de forma automaacutetica unainfraestructura TI en la nube
Azure tambieacuten ofrece la posibilidad de monitorizar el estado de las maacutequinasvirtuales a traveacutes de extensiones lo que permite configurar el escalado automaacute-tico al alcanzar cierto liacutemite definido por el operador Eacutesta es a priori la formaen que deberiacutea implementarse hablando en teacuterminos de eficiencia sin embargoesta aproximacioacuten es totalmente dependiente de la plataforma es decir no sepuede extrapolar a otro proveedor o sobre recursos propios sin realizar un nue-vo disentildeo En este proyecto las tareas que son ejecutadas por estos equipos notienen estado ya que todo lo relativo a la persistencia lo hemos asignado fueradel cluster esto permite escalar la plataforma a traveacutes de otra aproximaciones
Las plantillas aceptan una serie de variables a indicar por el usuario entreotras los conjuntos de escala para definir los nodos aceptan una variable quedefine el nuacutemero de maacutequinas que los componen Por otro lado Azure ofreceuna API REST y kits de desarrollo software (SDK por sus siglas en ingleacutes) quepermiten su despliegue de forma programaacutetica Aprovechando estas facilidadesen este proyecto se va a aproximar la escalabilidad con el sucesivo desplieguede la infraestructura de forma automaacutetica se monitorizan los equipos y si sedetecta una maacutequina excesivamente cargada se aumenta el nuacutemero de equiposen la plantilla y se vuelve a desplegar
23httpsgithubcomAntonioAlfrzCloud-Orchestrators
43
En este proyecto se han disentildeado las plantillas para desplegar la arquitec-tura necesaria tanto de Nomad como de DCOS En el caso de la primera eldespliegue es maacutes descriptivo ya que incluye maacutequinas virtuales grupos de se-guridad redes En el caso de DCOS Azure cuenta con un servicio especiacuteficopara clusters gobernados por DCOS denominado Azure Container Service queincluye los componentes necesarios y la instalacioacuten ya realizada
72 Implementacioacuten
En primer lugar para monitorizar el estado de los equipos se va a usar laherramienta Nagios un sistema que permite controlar el estado del hardwarey los servicios de un equipo Se trata de una herramienta muy completa de laque se va a usar su capacidad para ejecutar comandos (plugins) en los nodospara detectar picos de carga generar alertas y ejecutar programas para estoseventos
Se ha desplegado una maacutequina virtual con esta herramienta en ambos siste-mas y se ha instalado una extensioacuten de Nagios (Nagios Remote Plugin Executor)en todos los nodos que permite ejecutar comprobaciones remotamente en con-creto para esta prueba de concepto medir el nivel de saturacioacuten de la unidadcentral de procesamiento (CPU por sus siglas del ingleacutes) Cuando sucede uncambio de estado de una maacutequina esto es cuando este paraacutemetro supera el liacutemi-te definido por el operador Nagios permite actuar en consecuencia ejecutandoprogramas por ello se ha desarrollado un script que ejecuta lo siguiente
Un programa desarrollado en Python con el SDK de Azure que modificalas plantillas y despliega los recursos
Un guioacuten de Ansible para instalar todos los componentes necesarios en lasnuevas maacutequinas y arrancar de nuevo el cluster y las aplicaciones
44
8 Resultados y conclusiones
En este uacuteltimo apartado se da una visioacuten global del proyecto asiacute como a lasconclusiones maacutes importantes a las que se ha llegado y posibles temas futurosde desarrollo
81 Comparacioacuten
Ambas herramientas ofrecen las funcionalidades para gestionar los recursoseficientemente ofreciendo a los desarrolladores una plataforma donde desplegarsus aplicaciones de forma distribuida independientemente de los equipos fiacutesicosy el hardware que las soporten
DCOS es una herramienta que en un comienzo fue privativa pero cuyos res-ponsables la empresa Mesosphere decidieron publicar una versioacuten de coacutedigoEacutesta nos permite gestionar un cluster de una forma sencilla y usable ademaacutes decomplementarlo con otras herramientas como el balanceador de carga integradoo la autenticacioacuten de usuarios ademaacutes estaacute basada en Apache Mesos un pro-yecto de relativa madurez y con el soporte de la Apache Software FoundationDe forma resumida DCOS ofrece muchas posibilidades y servicios a cambiode una arquitectura e instalacioacuten maacutes compleja
Por su parte HashiCorp con menor tiempo de desarrollo ha conseguidouna herramienta muy sencilla de desplegar que ademaacutes cumple con todas lasfuncionalidades baacutesicas ejecutando un simple binario en cada nodo se puededesplegar un gestor de clusters totalmente funcional Sin embargo no cuentacon todas las posibilidades de Mesos (Nomad cuenta con menos controladoresque entornos posibles de Mesos) ni con los antildeadidos de DCOS lo que implicael uso de otras herramientas para complementar el servicio (Consul HAProxy)
De entre las dificultades encontradas al usar estas herramientas y desplegaraplicaciones sobre ellas se puede destacar la depuracioacuten en ocasiones se desco-noce si un error viene de la propia herramienta de la aplicacioacuten desplegada o delequipo fiacutesico si no se cuenta con un sistema de procesamiento de registro unose puede encontrar con muacuteltiples terminales abiertas inspeccionando numerososficheros de registro buscando posibles errores Ademaacutes no dejan de ser solucio-nes que para usar eficientemente se debe conocer parte de su funcionamientoy sintaxis a la hora de describir la tareas lo que supone un esfuerzo antildeadido yaque cada una tiene sus particularidades y liacutemites
45
82 Conclusiones
En una sociedad cada vez maacutes digital las empresas deben adaptarse a unmercado cuya demanda de contenido no deja de crecer Las nuevas arquitecturascomo microservicios asiacute como la gran cantidad de datos generada implica queuna mejor gestioacuten de los recursos y la rapidez para desplegar o escalar solucionesdando valor al cliente lo maacutes raacutepido posible es uno de los objetivos de todas lasempresas de base tecnoloacutegica
Las ventajas que ofrecen los planificadores con aplicaciones distribuidas sonnumerosas sin ir maacutes lejos empresas tan punteras como Google llevan maacutesde 10 antildeos orquestando contenedores24 Por un lado permiten aumentar elrendimiento de los equipos propios y por otro implementar un servicio comoplataforma para despliegues distribuidos sobre cualquier conjunto hardware deesta forma se provee un servicio similar al de la nube puacuteblica pero con laprincipal diferencia de que se elimina la independencia con el proveedor (vendorlock-in) esto es las aplicaciones no tienen limitaciones impuestas por eacuteste talescomo lenguaje de programacioacuten o herramientas y permite despliegues hiacutebridosentre recursos propios y la nube
83 Objetivos conseguidos
Implementacioacuten de los planificadores propuestos en la nube Se ha en-tendido y detallado el funcionamiento de estas herramientas y se hanimplementado en el servicio de infraestructura de Microsoft Azure
Despliegue de aplicaciones y servicios distribuidos Servicios que se usanactualmente en la industria del desarrollo software asiacute como una aplica-cioacuten web con una arquitectura moderna han sido desplegados de formadistribuida en los equipos cumpliendo con la funcionalidad esperada ade-maacutes de consiguiendo una alta disponibilidad
Aproximacioacuten de arquitectura escalable Se ha hecho una aproximacioacutende infraestructura escalable de forma que sea parcialmente extrapolable aotros proveedores
24httpwwwnextplatformcom20160322decade-container-control-google
46
84 Liacuteneas de investigacioacuten
Siguiendo con la materia de este proyecto se presentan posibles liacuteneas deinvestigacioacuten
Analizar el despliegue con estas herramientas de aplicaciones de Big Datay comparar la eficiencia con respecto a soluciones especializadas
Analizar el rendimiento de los algoritmos de planificacioacuten antes pruebasde estreacutes y situaciones de alta contienda
Comparar el uso de estas herramientas con las praacutecticas actuales de laindustria o implementacioacuten en un sistema de produccioacuten real
47
Referencias
[1] LA Barroso y U Houmllzle laquoThe Datacenter as a Computer An Introduc-tion to the Design of Warehouse-Scale Machinesraquo En Morgan amp ClaypoolPublishers ()
[2] Systems Research Group ndash NetOS (University of Cambridge) The evolu-tion of cluster scheduler architectures 2016 url httpswwwclcamacukresearchsrgnetoscamsasblog2016-03-09-scheduler-architectureshtml
[3] A Das I Gupta y A Motivala SWIM Scalable Weakly-consistent Infection-style Process Group Membership Protocol Inf teacutec Dept of ComputerScience Cornell University url https www cs cornell edu ~asdasresearchdsn02-swimpdf
[4] D Dubhashi y A Das Mastering Mesos PACKT Publishing mayo de2016
[5] The Apache Software Foundation Apache Mesos documentation urlhttpsmesosapacheorg
[6] David Greenberg Building Applications on Mesos OrsquoReilly Media 2016[7] Armand Grillet Comparison of Container Schedulers Inf teacutec Technische
Universitaumlt Berlin[8] HashiCorp Consul documentation url httpswwwconsulio[9] HashiCorp Nomad documentation url httpsdcosio[10] Dan C Marinescu Cloud computing theory and practice Morgan Kauf-
mann 2013[11] Mesosphere DCOS documentation url httpswwwnomadproject
io[12] Microsoft Azure documentation url httpsazuremicrosoftcom
es-esdocumentation[13] D Ongaro y J Ousterhout In Search of an Understandable Consensus
Algorithm Inf teacutec Stanford University url httpsraftgithubioraftpdf
[14] Fei Teng laquoRessource allocation and schelduling models for cloud compu-tingraquo Tesis de mtriacutea Ecole Centrale Paris 2011
[15] A Williams y col Automation and Orchestration with Docker and Contai-ners A Comprehensive Overview of the Docker and Container Ecosystem3 The New Stack 2016
48
- Resumen
- Summary
- Iacutendice de figuras
- Introduccioacuten y objetivos
-
- Contexto
- Objetivos
- Estructura del documento
-
- Cloud Computing
- Nuevas cargas de trabajo
- Gestioacuten de recursos Planificadores
-
- Sistemas distribuidos
-
- Clasificacioacuten
-
- Herramientas
-
- DCOS
-
- Apache Mesos
- Ejemplos de uso
-
- Nomad
-
- Protocolo de consenso Raft
- Protocolo gossip SWIM
- Planificacioacuten
-
- Casos de uso y despliegue
-
- Aplicacioacuten Web
-
- DCOS
- Nomad
-
- Servicio de integracioacuten continua
-
- DevOps
- Integracioacuten Continua
- Jenkins con Nomad
- Jenkins con DCOS
-
- Escalando la infraestructura
-
- Disentildeo
- Implementacioacuten
-
- Resultados y conclusiones
-
- Comparacioacuten
- Conclusiones
- Objetivos conseguidos
- Liacuteneas de investigacioacuten
-
Nomad sigue una arquitectura maestro-esclavo similar a la de Apache Mesosmuacuteltiples servidores acuerdan entre siacute un liacuteder que gestiona la planificacioacuten detareas en los clientes que soacutelo conocen sus asignaciones y las ejecutan
Todos los servidores participan paralelamente en tareas de planificacioacuten derecursos y asignacioacuten de tareas y ademaacutes entre ellos eligen un liacuteder que seencarga de la coordinacioacuten de la suscripcioacuten de los clientes al cluster y de lagestioacuten de las peticiones
Los clientes estaacuten configurados para comunicarse con el servidor usando lla-madas a procedimiento remoto (RPC por sus siglas en ingleacutes) que permite unordenador ejecutar coacutedigo en otra maacutequina Mediante esta tecnologiacutea los nodosclientes avisan de su estado e informa de sus asignaciones recursos y controla-dores disponibles
Existe la posibilidad de gestionar varios centros de datos agrupados en regio-nes eacutestas son independientes pero permite definir tareas o comprobar el estadode todas ellas desde cualquier punto A continuacioacuten se muestra una figura dela arquitectura a alto nivel de esta configuracioacuten
Figura 10 Arquitectura multi-regioacuten en NomadFuente httpswwwnomadprojectio
La herramienta se sustenta sobre tres protocolos fundamentales un protocolode consenso entre los servidores para compartir informacioacuten sobre su estado yel liacuteder un protocolo Gossip para la gestioacuten entre regiones y el planificador detareas
521 Protocolo de consenso Raft
El objetivo es obtener consistencia en un conjunto de nodos que comparteninformacioacuten es decir si un cliente realiza un cambio que todos los nodos veanla misma informacioacuten a la vez y ademaacutes sea tolerante a fallos Para ello se basaen el algoritmo Raft[13] que se detalla brevemente a continuacioacuten
20
Los nodos participantes en el algoritmo pueden estar en tres estados
Liacuteder (Leader) Todos los cambios que realicen en el cluster pasan por eacutel pri-mero
Seguidor (Follower) Nodo pasivo cuya responsabilidad es responder a laspeticiones del nodo liacuteder
Candidato (Candidate) Maacutequina que no ha encontrado liacuteder y solicita sueleccioacuten
Supongamos que tenemos cinco equipos que acaban de arrancar el protocoloEn la figura 11 se observan los nodos y sus respectivos registros a la derecha
Figura 11 Equipos sin consenso ejecutando el protocolo RAFTFuente httpsgithubcomongardieraftscope
Al comenzar todos los nodos son seguidores esperando recibir comunicacioacutende un nodo que actuacutee como liacuteder Cada nodo tiene un tiempo de espera aleatoriodespueacutes del cual si no es informado por un liacuteder pasa a estado candidato y pideel ldquovotordquo al resto de los participantes El algoritmo divide el tiempo en plazos uncandidato pasa a liacuteder si recibe la mayoriacutea de los votos en un plazo determinadoSe define mayoriacutea o cuoacuterum (quorum) comolceil
N2rceil
+ 1 (1)
donde N representa el nuacutemero de nodos
Para el ejemplo propuesto de 5 equipos se requieren de 3 votos Soacutelo losnodos que se encuentren en estado seguidor pueden votar una uacutenica vez a laprimera solicitud que reciba dentro de un plazo
Supoacutengase que el nodo denotado con S1 ha cumplido su tiempo de espera yrealiza la peticioacuten de voto (figura 12) A partir de este momento se pueden dartres casos
La maacutequina gana la eleccioacuten y pasa a ser liacuteder informando al resto
Otro servidor se establece como liacuteder en el mismo momento
Varios nodos pasan a ser candidatos por lo que ninguno consigue los votos
21
Figura 12 Un equipo pasa a estado candidato (RAFT)
Si un candidato recibe un aviso de un liacuteder en el mismo plazo el primeropasa a ser seguidor y se acaba la eleccioacuten de liacuteder
Por otro lado si un equipo candidato no recibe los votos en el plazo y agotasu tiempo de espera avanza al siguiente plazo y repite el proceso de votacioacutenLa tercera posibilidad puede conllevar a un estado indefinido ya que varioscandidatos pueden agotar su tiempo de espera al mismo tiempo y repartir losvotos Para solventarlo el algoritmo establece tiempos de espera aleatorios paralos candidatos
Siguiendo con el ejemplo propuesto el servidor S1 pasa a ser el liacuteder Cadacierto tiempo eacuteste debe realizar avisos a los nodos seguidores para no agotar sutiempo de espera
En este momento el cluster de servidores estaacute en ldquoconsensordquo y la informacioacutenen todos los nodos estaacute actualizada Un cambio en la informacioacuten inicia unproceso de replicacioacuten el liacuteder registra el cambio lo pasa al resto de nodos yuna vez eacutestos responden el cambio se hace efectivo
Supoacutengase que se realiza un cambio en los datos en la figura 13 en la partederecha se observa el cambio en el registro del servidor S1 que informa a losnodos seguidores En consecuencia los nodos registran el cambio y responden aS1
Figura 13 Cambio en un registro (RAFT)
Una vez el cuoacuterum (en el ejemplo tres equipos) informa al liacuteder de que
22
ha registrado el cambio el liacuteder lo hace efectivo en su sistema y notifica a losnodos que hacen lo mismo En la figura 14 el enviacuteo todaviacutea no ha llegado ala maacutequina S3 y se observa que no ha hecho efectivo el cambio (en el registroaparece punteado)
Figura 14 Aprobacioacuten del resto de equipos (RAFT)
Este protocolo funcionaraacute correctamente mientras exista un nuacutemero de nodosen funcionamiento igual o superior al cuoacuterum en el ejemplo propuesto elcuoacuterum es tres por lo que el sistema puede tolerar la caiacuteda de dos de los equipos
522 Protocolo gossip SWIM
Nomad permite la gestioacuten simultaacutenea de varios centros de datos reparti-dos en regiones geograacuteficamente separadas requiriendo de un protocolo ligeroque mantenga a los miembros actualizados sobre los participantes del conjun-to Para ello usa una ligera variante del protocolo SWIM[3] (Scalable Weakly-consistent Infection-style Process Group Membership Protocol) desarrollada porHashiCorp Estaacute clasificado como un protocolo de tipo gossip que debe su nom-bre a la semejanza con coacutemo se distribuye un rumor en una red social
SWIM se sustenta en dos caracteriacutesticas fundamentales la deteccioacuten de fallosy la distribucioacuten de la informacioacuten relativa a los miembros A continuacioacuten sedetalla el funcionamiento de ambos componentes
Deteccioacuten de fallos
Este componente tiene dos paraacutemetros el periodo de protocolo T y el nuacutemerode subgrupos de deteccioacuten de fallos k en los que se dividen los nodos Paracomprobar la comunicacioacuten entre dos maacutequinas usa la utilidad ping basadaen el protocolo ICMP La deteccioacuten de caiacuteda de un servidor sigue el siguientealgoritmo
Durante el periodo T cada miembro Mi de un subgrupo elige otro al azar Mjdel mismo subgrupo y le enviacutea un mensaje ping para comprobar su estado Enel caso de que se cumpla un tiempo de espera determinado por una estimacioacuten
23
del tiempo de ida y vuelta (RTT por sus siglas en ingleacutes) de la red y no hayarespuesta Mi le vuelve a enviar un mensaje ping indirectamente a traveacutes deun nuacutemero k de miembros escogidos aleatoriamente De no recibir ninguna res-puesta Mi establece que Mj ha sufrido un fallo y lo etiqueta como ldquosospechosordquoinformando al componente de distribucioacuten
Figura 15 Diagrama de tiempo del protocolo SWIMFuente httpswwwcscornelledu
Componente de distribucioacuten
Se encarga de informar de cualquier cambio en los miembros a todo el con-junto Los eventos de nodo caiacutedo y la unioacuten o disociacioacuten de un miembro setransmiten a todos los servidores para que actualicen sus lista Para distribuirla informacioacuten a todos los nodos se podriacutea usar el meacutetodo de multicast perosuele estar deshabilitado Por ello se utiliza una teacutecnica de transmisioacuten denomi-nada Piggybacking mediante la cual se adjunta a los propios mensajes PINGy ACK del algoritmo la informacioacuten a distribuir reduciendo asiacute la congestioacutenen la red
523 Planificacioacuten
Proceso encargado de distribuir las tareas entre los nodos clientes de acuerdoa su estado
El planificador de Nomad estaacute basado en las publicaciones de Google sobresus herramientas de gestioacuten de clusters Borg y Omega14 y entiende los trabajosdescritos por el usuario como un estado deseado es decir su despliegue en unamaacutequina cliente de forma correcta y los clientes como el estado actual esto eslo que se encuentra en ejecucioacuten El registro actualizacioacuten o cancelacioacuten de un
14httpresearchgooglecompubspub43438html
24
trabajo asiacute como el fallo de un nodo cliente implican un cambio de estado atramitar por el sistema lo que se define como evaluacioacuten (evaluation) Esto uacutelti-mo supone comparar el estado actual (clientes) con el estado deseado (conjuntode trabajos registrados) y enviarlos a los planificadores correspondientes que seencargaraacuten de asignar las tareas a los nodos clientes
Figura 16 Procedimiento de asignacioacuten en NomadFuente httpswwwnomadprojectio
En la figura 16 se observa el flujo de trabajo en el que las distintas evalua-ciones se encolan en el evaluation broker que se ejecuta en el servidor liacuteder ygestiona las evaluaciones pendientes asignaacutendoles prioridades
A continuacioacuten los nodos servidores ejecutan los scheduling workers queprocesan las evaluaciones llamando a los distintos planificadores que generanun plan de asignacioacuten esto es un conjunto de relaciones entre las tareas y losnodos clientes donde se ejecutaraacuten Este proceso se divide en dos fases primerose descartan aquellos clientes que no cumplan los requisitos y posteriormentese asigna una calificacioacuten al resto Se selecciona el nodo con mayor puntuacioacuteny se encola el plan en el gestor que se ejecuta en el servidor liacuteder Existen tresplanificadores de acuerdo al tipo de trabajo
Service Incluye aquellos trabajos que estaacuten destinados a ejecutarse en un pe-riacuteodo largo de tiempo Para realizar las asignaciones el planificador evaluacuteala mayor parte de los nodos y usa una versioacuten del algoritmo Best fit in-fluenciada por el trabajo de Google en su herramienta Borg Se trata deun algoritmo de planificacioacuten que sacrifica tiempo a cambio de maximizarel rendimiento de los clientes asignando la tarea a la maacutequina que tengala mayor carga de trabajo con el objetivo de reducir equipos en funciona-
25
miento
Batch Tareas que incluyen listas de comandos en general de menor duracioacuteny que no requieren interaccioacuten con el usuario Se vale del algoritmo deSparrow desarrollado por la universidad de Berkeley15 para limitar losnodos clientes a evaluar
System Trabajos destinados a ejecutarse en todos los nodos incluso los que seunen al cluster posteriormente
Core Mantenimiento interno de Nomad
Una vez se ha realizado el proceso de planificacioacuten el nodo liacuteder lo registra enla cola de planes (plan queue) que se encarga de asignarles prioridad y manejarcondiciones de carrera es decir que no accedan a los recursos de los clientes sincontrol y evitar que eacutestos superen su capacidad
La maacutequina liacuteder del conjunto puede de este modo aceptar una asignacioacuteny ser ejecutada por los clientes o por el contrario rechazaacutersela al planificadorlo que implicariacutea realizar un plan parcial o totalmente nuevo
Finalmente el estado de las evaluaciones se actualizan y los clientes soninformados de las asignaciones ejecutaacutendose las tareas
15httppeopleeecsberkeleyedu~keopublicationssosp13-final17pdf
26
6 Casos de uso y despliegue
Con el objetivo de mostrar las posibles utilidades que este tipo de sistemaspueden tener en las infraestructuras TI actuales se han desplegado las dos he-rramientas en la nube Microsoft Azure usando su servicio cloud de instancias demaacutequinas virtuales Linux para simular un conjunto de ordenadores conectadosentre siacute por una red LAN Sobre ellas se ha implementado dos casos de usouna aplicacioacuten web con una arquitectura con cierta orientacioacuten a microserviciosy un sistema de integracioacuten continua
El coacutedigo y todos los ficheros de configuracioacuten se pueden encontrar en elrepositorio del proyecto en GitHub16
61 Aplicacioacuten Web
Se busca simular el proceso de adaptacioacuten de una solucioacuten web para su des-pliegue en un sistema distribuido con las herramientas anteriormente descritascon el objetivo de aumentar tanto su escalabilidad como disponibilidad medianteredundancia
Se ha partido de una aplicacioacuten ya existente17 un servicio de almacenamien-to y reproduccioacuten de canciones A grandes rasgos este servicio permite crearusuarios subir canciones con sus respectivas portadas tener playlists propias yescuchar las canciones a traveacutes de un navegador web
La solucioacuten estaacute dividida en 4 partes (figura 17)
Una vista web con la loacutegica
Un almacenamiento conectado en red (NAS por sus siglas en ingleacutes)
Una API REST para gestionar las peticiones al almacenamiento
Base de datos NoSQL basada en MongoDB
La nueva tendencia de los proyectos web es su implementacioacuten en contene-dores Docker ya que facilitan su portabilidad y ofrecen un procedimiento dedespliegue raacutepido sobre todo a la hora de desarrollar y realizar pruebas en en-tornos de produccioacuten simulados Por ello en este caso se va a hacer uso de los
16httpsgithubcomAntonioAlfrzCloud-Orchestrators17httpsgithubcomsonsoleslpCDPSfy
27
motores de orquestacioacuten de contenedores de ambas herramientas Marathon enDCOS y el controlador Docker en el caso de Nomad
Figura 17 Arquitectura aplicacioacuten web
A continuacioacuten vamos detallar el despliegue en ambas herramientas de es-ta solucioacuten y observar tanto queacute dificultades se encuentran como que ventajasofrecen El objetivo final es adaptar el proyecto modificaacutendolo lo menos posiblecon objeto de analizar la capacidad de estas herramientas para desplegar cual-quier aplicacioacuten sin que eso conlleve la modificacioacuten de la arquitectura de eacutestaes decir que no sea dependiente del entorno
611 DCOS
Se ha descrito DCOS como una herramienta que se despliega sobre un con-junto de ordenadores y que permite instalar gestionar el despliegue de sistemasdistribuidos
Microsoft Azure cuenta con una plantilla para desplegar en su servicio cloudun cluster de maacutequinas virtuales con DCOS ya instalado que cuenta con
Maacutequinas maestras (1 3 o 5 a seleccionar por el usuario) configuradascomo un conjunto de disponibilidad esto eso Azure da ciertas garantiacuteasde que al menos una maacutequina estaraacute en funcionamiento
Maacutequinas agentes Por motivos de seguridad se distinguen dos roles
bull Nodos privados solo accesibles desde la red interna y configuradoscomo un conjunto de escala un recurso de Azure para gestionar ydesplegar maacutequinas con configuraciones ideacutenticas para permitir unraacutepido escalado
bull Un equipo conectado accesible desde Internet a travntildees de un balan-ceador de carga puacuteblico y situado en una subred externa
28
Dos balanceadores de carga
bull La interfaz puacuteblica del cluster que se conecta con el cliente puacuteblicobull Acceso a los equipos maestros para el administrador que soacutelo permiteconexioacuten mediante SSH y credenciales
Almacenamiento para todas las maacutequinas
Configuraciones necesarias de red y seguridad
En la figura 18 se observa un diagrama de la infraestructura
Figura 18 Infraestructura en Azure
El primer obstaacuteculo es la persistencia de estado de la aplicacioacuten que seconsigue gracias a una base de datos no relacional basada en MongoDB asiacutecomo el almacenamiento de las canciones Para implementarla tenemos variasposibilidades
Montar un sistema externo de almacenamiento conectado en red en todoslos agentes donde se ejecuten las tareas de esta manera si una tarea pasade un nodo a otro por cualquier motivo puede tener acceso a los mismosficheros (opcioacuten del caso de uso original)
Implementar un sistema de ficheros distribuidos en los agentes
Usar los servicios de almacenamiento de las nubes puacuteblicas
Aprovechar el sistema de voluacutemenes persistentes de Apache Mesos Eacutestepermite reservar recursos de un agente de forma que al arrancar una tarease crea un volumen independiente del ciclo de vida de eacutesta con ello esosrecursos donde se ha almacenado la informacioacuten pueden volver a ofrecerseal mismo entorno de tal manera que otra tarea pueda acceder a ella
DCOS aprovecha este sistema de voluacutemenes persistentes y permite instalarbases de datos distribuidas como ArangoDB o Apache Cassandra sin embargoesto implicariacutea modificar todo el coacutedigo referente al modelo de la base de datos
29
Por motivos de eficiencia y latencia asiacute como de una mayor gobernabilidadde los datos la mejor opcioacuten es usar el recurso de voluacutemenes persistentes queofrece Apache Mesos ya que de esta manera se gestionariacutea la aplicacioacuten completamediante una uacutenica herramienta Sin embargo esto implica que la informacioacutense encuentra exclusivamente en el agente donde se haya ejecutado la tarea y porlo tanto se sigue requiriendo de software externo para distribuir la informacioacutenpara que se accesible para todos los agentes A la hora de realizar este proyectose encontraba en desarrollo Flocker una solucioacuten desarrollada por ClusterHQque permite compartir los voluacutemenes de Docker a traveacutes de un cluster quesi bien es compatible con el planificador de Mesos el proyecto se encontrabatodaviacutea en fases tempranas de desarrollo y los sistemas de almacenamiento quesoporta quedaban fuera del aacutembito de este trabajo
Por todo ello dado que las maacutequinas se han desplegado en la nube puacuteblicade Azure se decidioacute usar su servicio de almacenamiento de objetos para lascanciones y otra maacutequina para desplegar MongoDB y asiacute mantener el modelode datos original de la aplicacioacuten La diferencia del almacenamiento de obje-tos con respecto a nivel de fichero es que el primero no tiene jerarquiacutea paraorganizar los archivos eacutestos se guardan como objetos (con sus metadatos) enun mismo espacio soacutelo diferenciaacutendose por un identificador uacutenico esto implicaentre otras cosas que se puede acceder a un fichero dado uacutenicamente su IDindependientemente de la localizacioacuten fiacutesica de eacuteste facilitando pues la gestioacuteny el desarrollo
El coacutedigo del proyecto se ha modificado en los siguientes apartados
Las direcciones de la base de datos y los balanceadores de carga asiacute comosus puertos estaban originalmente fijos Se han configurado como variablesde entorno para facilitar el descubrimiento del servicio y hacer transpa-rente la aplicacioacuten al entorno de despliegue
La API REST se ha adaptado al almacenamiento en Azure en vez de enlocal
Estas modificaciones no suponen un cambio sustancial pero permiten separala persistencia de las tareas ejecutadas por DCOS lo que facilita en granmedida su ejecucioacuten al ser totalmente sin estado y ademaacutes implican tenerlos datos bajo un mayor control
Para la orquestacioacuten de contenedores se va a usar el entorno Marathondesarrollado tambieacuten por Mesosphere Eacuteste se puede usar a traveacutes de una interfazgraacutefica la interfaz de liacutenea de comandos (en lo que sigue CLI por sus siglas eningleacutes) de DCOS o con su API HTTP
Primero se han publicado la imaacutegenes de los contenedores que encapsulanla interfaz web y la api de la aplicacioacuten en el repositorio puacuteblico DockerHub
Los despliegues en este entorno se describen mediante ficheros JSON en losque se detalla entre otras opciones la imagen del contenedor los puertos a usar
30
los recursos que debe ocupar en un nodo o las instrucciones de monitorizacioacuten
Para el servicio de descubrimiento DCOS ofrece la posibilidad de asignardirecciones IP virtuales (VIP por sus siglas en ingleacutes) a tareas que se compartenen todos los nodos DCOS lleva integrado un balanceador de carga a nivel TCP(el componente denominado Minuteman) que balancea entre las direccionesvirtuales de las tareas y todas las instancias de eacutestas a lo largo del cluster Estoes necesario por dos motivos equilibrar la carga de los equipos con el fin deevitar un punto de uacutenico fallo mediante redundancia y evitar la contienda dedirecciones al ejecutar las tareas en puertos aleatorios
Este balanceador de carga estaacute basado en el trabajo de Michael Mitzenma-cher The Power of Two Choices in Randomized Load Balancing18 A grandesrasgos el algoritmo mantiene una media moacutevil exponencial de latencias paracada destino (backend) ademaacutes de las caiacutedas consecutivas Si un destino noresponde a una negociacioacuten en tres pasos (three way handshake) de forma con-secutiva en un periodo inferior a 5 ms se considera caiacutedo El algoritmo iterasobre los destinos disponibles en base a su histoacuterico de fallos y escoge dos deforma aleatoria de los cuales coge el de mejor meacutetrica
Las direcciones virtuales soacutelo se pueden resolver dentro del cluster porello para implementar la interfaz puacuteblica de la aplicacioacuten esto es el balancea-dor de carga de la interfaz web usaremos un paquete de DCOS denominadomarathon-lb un balanceador basado en HAProxy y adaptado por MesosphereEn este caso equilibra la carga de todas instancias de las tareas ejecutadas porel entorno Marathon por sus etiquetas y permite ademaacutes definir como puntode entrada muacuteltiples hosts virtuales definidos por sus nombres completos dedominio (FQDN por sus siglas en ingleacutes) en nuestro caso la interfaz puacuteblicadel balanceador de Azure para los agentes
Por motivos de seguridad todas las tareas se ejecutan en los agentes privadoses decir los que son exclusivamente accesibles desde la red interna Por su partemarathon-lb se ejecuta en el agente puacuteblico que cuenta con IP puacuteblica y lospuertos 80 (HTTP) y 8080 abiertos de forma que la aplicacioacuten sea accesibledesde Internet Esto es posible debido a que Apache Mesos permite reservarrecursos mediante roles asignados a nodos para un uso especiacutefico De esta formala arquitectura vista desde la aplicacioacuten quedariacutea como en la figura 19
18httpswwweecsharvardedu~michaelmpostscriptstpds2001pdf
31
Figura 19 Arquitectura de la aplicacioacuten web en DCOS
Ejecucioacuten
A la hora de desplegar la aplicacioacuten DCOS puede gestionarse medianteuna interfaz graacutefica o una interfaz de liacutenea de comandos La primera se accedea traveacutes de un navegador web en el puerto 80 (HTTP) y permite instalar losentornos disponibles observar el estado de los nodos y las tareas que se estaacutenejecutando y los ficheros de registros que eacutestas generan
La CLI permite el control desde un nodo o una maacutequina remota (suponiendoque los maestros tienen IP puacuteblica y el puerto 80 abierto) ya que DCOS tieneun sistema de autorizacioacuten que permite tener una interfaz puacuteblica con ciertasgarantiacuteas de seguridad
Por su parte cada entorno de trabajo puede ser controlado por la CLI peroademaacutes cuenta con sus propias interfaces Marathon expone una API HTTPen el puerto 8080 de la direccioacuten puacuteblica de los maestros del cluster asiacute comootra interfaz graacutefica Para desplegar un contenedor se podriacutea usar la CLI
$ dcos marathon app add lt f i l e j songt
O la API HTTP
$ cu r l minusX POST http lt ip_maestro gt8080v2apps minusd ltf i l e jsongt minusH Contentminustype app l i c a t i o n j son
32
612 Nomad
La arquitectura de Nomad es maacutes sencilla ya que solo requiere de un ficheroejecutable en todos los nodos para funcionar Si DCOS es la base de instala-cioacuten de entornos de terceros Nomad integra todas las funcionalidades baacutesicasesto es gestor de recursos planificador y ejecutor en los nodos cliente Estaherramienta cuenta con un menor tiempo de desarrollo y en el momento deescribir este documento cuenta exclusivamente con los siguientes controladoresen comparacioacuten con los entornos de DCOS
Motor Docker es decir funcioacuten de orquestacioacuten de contenedores
Ejecucioacuten de archivos binarios como comandos de Shell
Ejecucioacuten de aplicaciones Java
Virtualizacioacuten de maacutequinas mediante tecnologiacutea QEMU
Todos ellos necesitan que la tecnologiacutea subyacente esteacute instalada en las maacute-quinas clientes (Docker Java QEMU) Actualmente no permite el registro decontroladores por parte de terceros aunque estaacute planificado en un futuro ofreceruna interfaz para su desarrollo
Nomad no cuenta con el servicio de descubrimiento sin embargo puede inte-grarse con la herramienta Consul desarrollada por la misma empresa Por otrolado para el balanceo de carga usaremos un contenedor Docker con HAProxyuna herramienta de coacutedigo abierto que ofrece tanto servicios de proxy como debalanceador y cuyos ficheros de configuracioacuten completaremos con el proyectoConsul Template19
Consul
Consul sigue la misma arquitectura que Nomad es decir un nodo servidorque orquesta un conjunto de maacutequinas clientes y permite a los procesos que seejecutan en los equipos definirlos como servicios ofreciendo diversas caracteriacutes-ticas entorno a estos de los cuales vamos a usar dos
Descubrimiento de servicio Las maacutequinas clientes publican en el cataacutelogode servicios las tareas en ejecucioacuten y Consul les asigna nombres de dominioaccesibles por todos los miembros del cluster a traveacutes de la interfaz DNSincluida en esta herramientaConsul se integra con Nomad de forma que todas las tareas que se ejecu-ten en la segunda son automaacuteticamente publicados como servicios de laprimera de esta manera no hace falta conocer la direccioacuten de la maacutequinacliente donde se esteacute ejecutando el proceso ya que se puede acceder a eacutela traveacutes de su nombre de dominio de forma transparente Por ejemplo si
19[httpsgithubcomhashicorpconsul-template]
33
ejecutamos una tarea con ID web en el puerto 8080 se puede acceder aella en la direccioacuten webserviceconsul8080Para que las direcciones propias de Consul las resuelva su propio DNS y noel que esteacute asignado por defecto en la maacutequina usaremos la herramientadnsmasq20 que permite especificar la direccioacuten de un servidor DNS paraconsultas de direcciones especiacuteficas
Monitorizacioacuten Permite realizar comprobaciones del servicio y seguir su esta-do Aprovecharemos esta funcionalidad tanto para definir el propio procesode Nomad como servicio de Consul como las tareas desplegadas
HAProxy + Consul Template
HAProxy es una solucioacuten versaacutetil de coacutedigo abierto que ofrece solucionesde balanceo de carga y proxy Existen otras herramientas en el mercado comoNGINX o ldirectord sin embargo HAProxy suponiacutea una solucioacuten sencilla deconfigurar para mostrar el caso de uso
El uso de estas herramientas se debe a dos motivos para que no existacontienda con respecto a los puertos de los clientes usados por las tareas eacutestos sevan a asignar de forma dinaacutemica lo que en principio implicariacutea que la aplicacioacutendeberiacutea realizar consultas DNS de tipo SRV (que incluye puertos) a la interfazde Consul y balancear la carga entre tareas por redundancia y capacidad
Como la direccioacuten IP y puerto son variables cada vez que las tareas seactualicen o se reasignen es necesario volver a configurar HAProxy de formamanual Por ello HashiCorp ha desarrollado un programa denominado Con-sul Template que realiza peticiones sucesivas a la interfaz HTTP de Consul delas direcciones fiacutesicas de un servicio y reinicia automaacuteticamente el proceso deHAProxy Asiacute definiendo estas tareas como servicios Consul podremos tantomonitorizarlas como escalar las tareas dinaacutemicamente sin necesidad de cambiarel balanceador A partir del contenedor Docker oficial de HAProxy se ha desa-rrollado otro con la configuracioacuten baacutesica y con Consul Template para desplegarlocomo una tarea en Nomad
Despliegue
Se ha usado el mismo coacutedigo que en el apartado anterior con la persistenciaen el servicio de almacenamiento de Azure Desde la perspectiva del hardwarese implementaraacute la misma infraestructura que en el caso de DCOS (figura 18)estos es definiremos dos tipos de maacutequinas clientes un agente que se conectaraacutecon el balanceador de carga con nombre de dominio puacuteblico y donde se desple-garaacute el balanceador de carga de la vista web y agentes privados no accesiblesdesde fuera del cluster y donde se ejecutaraacuten el resto de tareas en la red inter-na La principal diferencia radica en las tareas que ejecutan HAproxy y ConsulTemplate que sustituye a las direcciones IP virtuales que ofrece DCOS
20httpwwwthekelleysorgukdnsmasqdochtml
34
Figura 20 Despliegue en Azure de Nomad+Consul
Cabe matizar que los balanceadores basados en HAProxy se implementanpor necesidad de la aplicacioacuten para el descubrimiento del servicio a diferenciade los de Azure que se implementan por motivos de seguridad y escalabilidaddel cluster en siacute
Configuracioacuten Nomad
Los ficheros de configuracioacuten de las maacutequinas maacutester y cliente son similaresy comparten la mayoriacutea de las opciones como por ejemplo el nombre del nodoo la interfaz de red donde escucha Nomad las peticiones Sus opciones son engeneral auto-explicativas sin embargo existen dos detalles que matizar
El proceso de Nomad escucha las peticiones tanto de los protocolos deconsenso como del usuario a traveacutes de una interfaz de red que se debeindicar en el fichero de configuracioacuten
En el caso de los clientes se deben indicar las direcciones de los servidoresdel cluster sin embargo se trata de un sistema dinaacutemico en el que losnodos pueden sufrir errores y cambiar de direccioacuten Por ello se ha definidoNomad como un servicio de Consul y asiacute poder definir la direccioacuten de losservidores como un nombre de dominio no por su direccioacuten fiacutesica que elservidor DNS de Consul se encargaraacute de resolver
Por defecto Nomad usa los siguientes puertos
API HTTP 4646 Peticiones HTTP y recepcioacuten de oacuterdenes mediante laliacutenea de comandos
RPC 4647 Protocolo de consenso entre los nodos del cluster
Serf 4648 Protocolo de gossip entre los servidores de los centros de datosgobernados por Nomad
35
Los dos uacuteltimos deben ser interfaces alcanzables por otros nodos sin embargo laAPI HTTP por motivos de seguridad deberiacutea ser local ya que en caso contrariocualquier persona con acceso a ella tiene el control sobre la herramienta Eacutestasolo deberiacutea estar accesible en un servidor o gestionarlo mediante una terminalSSH por ejemplo En este trabajo al ser una prueba de concepto se ha abiertoen todos los nodos
Trabajos de Nomad
Las tareas se detallan en ficheros con formato HashiCorp Configuration Lan-guage un derivado del formato JSON creado por la empresa que le da nombrecompatible con eacuteste y que permite comentarios
En estos ficheros se puede definir
La regioacuten y el centro de datos donde se ejecutaraacute (Nomad permite lagestioacuten de centros de datos geograacuteficamente distribuidos en regiones)
La poliacutetica de actualizacioacuten de la tarea
Grupo de tareas esto es que se ejecutaraacuten en el mismo nodo
El nuacutemero de grupos a ejecutarescalar asiacute como los liacutemite que debencumplir los nodos asignados
La poliacutetica de reinicio ante fallo o error
Tareas El controlador su configuracioacuten los paraacutemetros del servicio aso-ciado a registrar en Consul asiacute como los recursos que consume (puertosmemoria)
En nuestro caso usamos sobre todo el controlador Docker esto eso orques-tacioacuten de contenedores en los nodos clientes y tres de sus opciones
Imagen del contenedor Se han subido todas las imaacutegenes del proyecto a Doc-ker Hub donde por defecto se busca la imagen
Puertos Los puertos a usar por el contenedor que pueden ser estaacuteticos asigna-dos por el usuario o dinaacutemicos siendo Nomad el que se encarga de mapearun puerto libre del nodo cliente al expuesto por el contenedor
Servidores DNS Como usamos la interfaz DNS de Consul como descubri-miento de servicio se debe configurar el contenedor para que use cualquiernodo del cluster como servidor DNS
Configuracioacuten Consul
Al ser desarrolladas por la misma empresa los ficheros de configuracioacuten deConsul y Nomad comparten muchas opciones Consul tambieacuten acepta peticionesa traveacutes de una interfaz de red siendo los puertos usados por defecto
36
RPC 8300 8400 Maneja la peticiones del resto de nodos y usuarios
Serf 8301 8302 Protocolo gossip
HTTP API 8500
HTTPS API Desactivada por defecto
Interfaz DNS 8600
Se debe asignar a los protocolos internos del cluster esto es RPC y Serf unainterfaz alcanzable por los nodos y por el contrarioasignar a los dos uacuteltimos ala interfaz de loopback por motivos de seguridad
Cabe destacar que Consul tambieacuten cuenta con una interfaz graacutefica que per-mite ver el estado de los equipos y los servicios registrados y que se encuentra enel mismo puerto que la API HTTP en la direccioacuten httpIP_EQUIPO8500ui
Ejecucioacuten
Tanto Nomad como Consul requieren de la ejecucioacuten de un fichero en todoslos nodos integrantes del cluster Como prueba de concepto se ha decidido usardos servidores para ambos aunque cabe matizar que es un nuacutemero ineficienteya que la caiacuteda de uno de ellos supondriacutea la peacuterdida del cuoacuterum y por tantodel consenso del cluster
En primer lugar se arrancan los servidores que son los encargados de ejecu-tar el protocolo de consenso y gestionar el cluster y a continuacioacuten los clientesque no tienen praacutecticamente estado y dependen de los servidores
En el caso de Consul se debe indicar el directorio donde se guardan losficheros que describen los servicios asiacute como el archivo que especifica el resto delas opciones
1 Se inicia el primer servidor en uno de los equipos
$ consu l agent minuscon f i gminusd i r e t c consu l d s e r v i c e s minuscon f i gminus f i l e consu l_server j son
2 Los siguientes equipos deben unirse al anterior por lo que antildeadimos elargumento join con la direccioacuten del primer servidor Para el caso de otrosservidores
$ consu l agent minuscon f i gminusd i r e t c consu l d s e r v i c e s minuscon f i gminus f i l e consu l_server j son minus j o i n ltIP_servidor1gt
37
Una vez los servidores han alcanzado el consenso y elegido un liacuteder en losclientes
$ consu l agent minuscon f i gminusd i r e t c consu l d s e r v i c e s minuscon f i gminus f i l e c on su l_c l i en t j son minus j o i n ltIP_cualquierServ idorgt
El proceso para iniciar Nomad es igual y los comandos similares sin embargoya no es necesario indicar una direccioacuten IP fija en los equipos sino el nombre dedominio del servicio de Nomad registrado por Consul En el primer servidor
$ nomad agent minusc on f i g nomad_server j son
Y el resto de equipos (con su fichero de configuracioacuten correspondiente)$ nomad agent minusc on f i g nomad_server j son minus j o i n nomad s e r v i c e consu l
Por uacuteltimo para desplegar la aplicacioacuten web se han escrito tres ficherosque detallan las tareas de la interfaz web API y los balanceadores de cargaMediante la CLI
$ nomad run minusaddress=http lt ip_c lus te r gt4646 lt f i l e hclgt
O mediante la API HTTP de Nomad$ cu r l minusX POST minusd ltf i l e hclgthttp lt ip_c lus te r gt4646 jobltjob_namegt
Ansible
Como se puede comprobar con el aumento del nuacutemero de equipos pasa aser inviable manejar todos los nodos a traveacutes de terminal Ademaacutes como seha comentado con anterioridad Nomad requiere que en los nodos clientes es-teacuten instalados las herramientas que soporten las tareas por ejemplo el motorde Docker Por ello para facilitar tanto el arranque como la instalacioacuten de lasdependencias vamos a usar Ansible una herramienta de coacutedigo abierto desarro-llada en Python que permite gestionar configuraciones aprovisionar recursosdespliegue de aplicaciones de forma automaacutetica
A grandes rasgos esta herramienta funciona mediante ficheros en formatoYAML denominados play-books que describen un conjunto de pasos a ejecutaren una lista de equipos remotos Estos pasos son ejecutados por moacutedulos inde-pendientes a traveacutes de SSH es decir en cualquier ordenador con conexioacuten a los
38
hosts dado su contrasentildea o clave puacuteblica puede arrancar el script y realizariacutealos pasos de forma remota gestionando el cluster desde un solo equipo
Se han desarrollado guiones para lo siguiente
Descarga de los binarios de Nomad y Consul en todos los nodos copiade los ficheros de configuracioacuten baacutesicos y modificarlos de acuerdo a cadanodo (nombre del equipo direccioacuten IP)
Instalacioacuten de las dependencias
Arranque de Nomad y Consul
Ansible extiende su funcionalidad a traveacutes de moacutedulos independientes que per-miten por ejemplo instalar paquetes mediante herramientas de gestioacuten de pa-quetes (APT yum) aprovisionar automaacuteticamente maacutequinas virtuales de Ama-zon EC2
Algunas opciones de los ficheros de configuracioacuten de Nomad y Consul sondependientes del nodo particular por ejemplo la interfaz de red Para estetrabajo se ha realizado un moacutedulo para modificar los ficheros de configuracioacutende forma automaacutetica En el repositorio del proyecto se encuentra una carpetadonde se encuentran todos los ficheros necesarios para desplegar un clustertotalmente funcional solo requiere de una liacutenea de terminal con Ansible
$ ans ib l eminusplaybook minus i hos t s minusk ltssh_passgt minusu ltnode_usergt s i t e yml
39
62 Servicio de integracioacuten continua
Se ha implementado un sistema de integracioacuten continua que permite ejecu-tar tareas de compilacioacuten y pruebas de forma distribuida aumentando asiacute elrendimiento de los equipos En primer lugar se detallaraacute los motivos por los quepuede resultar beneficioso para las empresas una implementacioacuten de este tipo alo que seguiraacute los detalles del despliegue
621 DevOps
Metodologiacutea que defiende la comunicacioacuten y colaboracioacuten entre desarrolla-dores de software y los profesionales de operaciones a lo largo de todo el ciclo devida de una aplicacioacuten Estaacute muy relacionado con el desarrollo aacutegil de softwareesto es un enfoque para los proyectos que defiende el desarrollo iterativo e in-cremental donde los requisitos y soluciones evolucionan con el tiempo seguacuten lanecesidad del proyecto DevOps extiende esta filosofiacutea a todas los componentesde un servicio incluyendo sistemas y operaciones
Se trata de un concepto que cada organizacioacuten o empresa adapta a suspropias necesidades y procesos de negocio en este proyecto nos vamos a centraren la integracioacuten continua una praacutectica fundamental tanto del desarrollo aacutegilcomo de esta filosofiacutea
622 Integracioacuten Continua
Se define como una praacutectica de desarrollo software donde los miembros delequipo ponen en comuacuten su trabajo frecuentemente al menos una vez al diacutea21Cada integracioacuten se verifica con una compilacioacuten automaacutetica que incluye laejecucioacuten de pruebas para detectar errores de integracioacuten tan pronto como seaposible
Desde el punto de vista operativo esto supone automatizar la configuracioacutende equipos o el despliegue de maacutequinas virtuales donde compilar el proyecto yejecutar las pruebas y posteriormente eliminarlas Este flujo de trabajo se vebeneficiado en entornos distribuidos ya que el objetivo del desarrollador es com-probar el resultado de las pruebas raacutepidamente sin preocuparse del despliegueo los propios equipos
Para esta prueba de concepto vamos a usar Jenkins un servidor de integra-cioacuten continua escrito en Java que nos permite definir trabajos que contendraacutenla descripcioacuten tanto del entorno como su ejecucioacuten
Este sigue una estructura maestro-esclavo muy similar al de los gestores declusters usados en este proyecto el maestro contiene toda la loacutegica del servicio
21httpmartinfowlercomarticlescontinuousIntegrationhtml
40
trabajos autenticacioacuten y los esclavos son los encargados de la ejecucioacuten ensiacute Jenkins tiene varias viacuteas para aprovisionar los uacuteltimos
Mediante SSH
Interfaz graacutefica
Desarrollar un script propio
Ejecucioacuten de un fichero java
La ventaja de usar planificadores es que el despliegue de esclavos es dinaacutemicoes decir no tener una maacutequina especiacuteficamente configurada para ello DCOS yNomad se encargaraacuten de configurar estos despliegues en sus maacutequinas y poste-riormente eliminarlos Para ello se ha usado la uacuteltima opcioacuten definiendo tareasque descarguen el fichero java Con todo ello se consigue un entorno de inte-gracioacuten continua eficiente que ademaacutes permite la ejecucioacuten de otros servicios deforma independiente
Jenkins permite la creacioacuten de plugins que extienden sus funcionalidadesTanto Nomad22 como Apache Mesos cuentan con uno que permite su integra-cioacuten
Para esta prueba se va a usar el mismo proyecto que para el caso de usode orquestacioacuten de contenedores la aplicacioacuten web al que se le ha antildeadido untest para comprobar que se conecta correctamente a la base de datos medianteMocha un framework de Nodejs Por otro lado se antildeade el plugin de git ya queel coacutedigo se obtiene de GitHub el repositorio remoto de control de versiones delproyecto
El proceso general de ejecucioacuten seriacutea como sigue
1 Se ejecuta el maestro de Jenkins como tarea Docker partiendo de la imagenoficial
2 Al arrancar un trabajo se manda una tarea a los planificadores que laasignaraacuten a un nodo cliente Esta tarea consiste en la descarga del ficherode configuracioacuten Java y arrancarlo configurando el equipo como un clientede Jenkins temporalmente
3 Jenkins ejecuta el trabajo en el nuevo cliente en este caso iniciar la apli-cacioacuten web iniciar las pruebas y generar un informe
4 Se elimina el cliente
A continuacioacuten se detallan los matices de cada herramienta a la hora de imple-mentar este servicio
22Desarrollado por Ivo Verberk httpwwwivoverberknl
41
623 Jenkins con Nomad
El plugin permite la ejecucioacuten del fichero Java mediante dos controladorescontenedores Docker y Java En este proyecto nos hemos decantado por el pri-mero ya que nos ahorra instalar la maacutequina virtual de java en todos los nodoscliente Por ello se ha construido un contenedor base con Java para la ejecucioacutendel fichero de configuracioacuten y Nodejs para lanzar la aplicacioacuten web
El plugin se configura con la direccioacuten IP del cluster y el contenedor queejecuta el esclavo Jenkins Por su parte el trabajo en Jenkins se define conel repositorio en GitHub donde se aloja el coacutedigo del proyecto a probar y loscomandos a ejecutar en este caso npm update y npm test
624 Jenkins con DCOS
En el caso de DCOS su sistema de paquetes incluye Jenkins por lo queal instalarlo ya se tiene la configuracioacuten de Mesos totalmente funcional Sinembargo para ejecutar la aplicacioacuten en particular y las pruebas se requiere deNodejs en los equipos esclavos por ello debemos antildeadir un plugin de Jenkinsque permite instalar este entorno antes de ejecutar el trabajo Una vez hechoesto soacutelo queda definir la tarea igual que en el caso anterior
Cabe destacar que Mesosphere tambieacuten ha desarrollado un plugin que per-mite hacer despliegues en Marathon de tal manera que permitiriacutea con cadacommit del coacutedigo compilar la imagen del contenedor Docker y desplegarlaautomaacuteticamente aunque en este proyecto no se ha hecho pruebas de esta fun-cionalidad
42
7 Escalando la infraestructura
Uno de los factores clave que se busca a la hora de implementar sistemasdistribuidos es el poder escalar la infraestructura de forma maacutes sencilla estoes detectar que las maacutequinas estaacuten alcanzando el liacutemite de su capacidad yaumentar eacutesta ya sea mejorando sus caracteriacutesticas teacutecnicas o antildeadiendo maacutesnodos al cluster
El coacutedigo y todos los ficheros de configuracioacuten de esta seccioacuten tambieacuten sepueden encontrar en el repositorio del proyecto en GitHub23
71 Disentildeo
Microsoft Azure permite organizar los servicios cloud de forma loacutegica a traveacutesde grupos de recursos y asiacute poder crear o eliminar eacutestos en conjunto parauna aplicacioacuten determinada (por ejemplo una aplicacioacuten web suele requerir demaacutequinas virtuales bases de datos almacenamiento) Ademaacutes dispone dela opcioacuten de crear plantillas en formato JSON que permite al desarrolladordefinir los recursos y su interrelacioacuten para desplegar de forma automaacutetica unainfraestructura TI en la nube
Azure tambieacuten ofrece la posibilidad de monitorizar el estado de las maacutequinasvirtuales a traveacutes de extensiones lo que permite configurar el escalado automaacute-tico al alcanzar cierto liacutemite definido por el operador Eacutesta es a priori la formaen que deberiacutea implementarse hablando en teacuterminos de eficiencia sin embargoesta aproximacioacuten es totalmente dependiente de la plataforma es decir no sepuede extrapolar a otro proveedor o sobre recursos propios sin realizar un nue-vo disentildeo En este proyecto las tareas que son ejecutadas por estos equipos notienen estado ya que todo lo relativo a la persistencia lo hemos asignado fueradel cluster esto permite escalar la plataforma a traveacutes de otra aproximaciones
Las plantillas aceptan una serie de variables a indicar por el usuario entreotras los conjuntos de escala para definir los nodos aceptan una variable quedefine el nuacutemero de maacutequinas que los componen Por otro lado Azure ofreceuna API REST y kits de desarrollo software (SDK por sus siglas en ingleacutes) quepermiten su despliegue de forma programaacutetica Aprovechando estas facilidadesen este proyecto se va a aproximar la escalabilidad con el sucesivo desplieguede la infraestructura de forma automaacutetica se monitorizan los equipos y si sedetecta una maacutequina excesivamente cargada se aumenta el nuacutemero de equiposen la plantilla y se vuelve a desplegar
23httpsgithubcomAntonioAlfrzCloud-Orchestrators
43
En este proyecto se han disentildeado las plantillas para desplegar la arquitec-tura necesaria tanto de Nomad como de DCOS En el caso de la primera eldespliegue es maacutes descriptivo ya que incluye maacutequinas virtuales grupos de se-guridad redes En el caso de DCOS Azure cuenta con un servicio especiacuteficopara clusters gobernados por DCOS denominado Azure Container Service queincluye los componentes necesarios y la instalacioacuten ya realizada
72 Implementacioacuten
En primer lugar para monitorizar el estado de los equipos se va a usar laherramienta Nagios un sistema que permite controlar el estado del hardwarey los servicios de un equipo Se trata de una herramienta muy completa de laque se va a usar su capacidad para ejecutar comandos (plugins) en los nodospara detectar picos de carga generar alertas y ejecutar programas para estoseventos
Se ha desplegado una maacutequina virtual con esta herramienta en ambos siste-mas y se ha instalado una extensioacuten de Nagios (Nagios Remote Plugin Executor)en todos los nodos que permite ejecutar comprobaciones remotamente en con-creto para esta prueba de concepto medir el nivel de saturacioacuten de la unidadcentral de procesamiento (CPU por sus siglas del ingleacutes) Cuando sucede uncambio de estado de una maacutequina esto es cuando este paraacutemetro supera el liacutemi-te definido por el operador Nagios permite actuar en consecuencia ejecutandoprogramas por ello se ha desarrollado un script que ejecuta lo siguiente
Un programa desarrollado en Python con el SDK de Azure que modificalas plantillas y despliega los recursos
Un guioacuten de Ansible para instalar todos los componentes necesarios en lasnuevas maacutequinas y arrancar de nuevo el cluster y las aplicaciones
44
8 Resultados y conclusiones
En este uacuteltimo apartado se da una visioacuten global del proyecto asiacute como a lasconclusiones maacutes importantes a las que se ha llegado y posibles temas futurosde desarrollo
81 Comparacioacuten
Ambas herramientas ofrecen las funcionalidades para gestionar los recursoseficientemente ofreciendo a los desarrolladores una plataforma donde desplegarsus aplicaciones de forma distribuida independientemente de los equipos fiacutesicosy el hardware que las soporten
DCOS es una herramienta que en un comienzo fue privativa pero cuyos res-ponsables la empresa Mesosphere decidieron publicar una versioacuten de coacutedigoEacutesta nos permite gestionar un cluster de una forma sencilla y usable ademaacutes decomplementarlo con otras herramientas como el balanceador de carga integradoo la autenticacioacuten de usuarios ademaacutes estaacute basada en Apache Mesos un pro-yecto de relativa madurez y con el soporte de la Apache Software FoundationDe forma resumida DCOS ofrece muchas posibilidades y servicios a cambiode una arquitectura e instalacioacuten maacutes compleja
Por su parte HashiCorp con menor tiempo de desarrollo ha conseguidouna herramienta muy sencilla de desplegar que ademaacutes cumple con todas lasfuncionalidades baacutesicas ejecutando un simple binario en cada nodo se puededesplegar un gestor de clusters totalmente funcional Sin embargo no cuentacon todas las posibilidades de Mesos (Nomad cuenta con menos controladoresque entornos posibles de Mesos) ni con los antildeadidos de DCOS lo que implicael uso de otras herramientas para complementar el servicio (Consul HAProxy)
De entre las dificultades encontradas al usar estas herramientas y desplegaraplicaciones sobre ellas se puede destacar la depuracioacuten en ocasiones se desco-noce si un error viene de la propia herramienta de la aplicacioacuten desplegada o delequipo fiacutesico si no se cuenta con un sistema de procesamiento de registro unose puede encontrar con muacuteltiples terminales abiertas inspeccionando numerososficheros de registro buscando posibles errores Ademaacutes no dejan de ser solucio-nes que para usar eficientemente se debe conocer parte de su funcionamientoy sintaxis a la hora de describir la tareas lo que supone un esfuerzo antildeadido yaque cada una tiene sus particularidades y liacutemites
45
82 Conclusiones
En una sociedad cada vez maacutes digital las empresas deben adaptarse a unmercado cuya demanda de contenido no deja de crecer Las nuevas arquitecturascomo microservicios asiacute como la gran cantidad de datos generada implica queuna mejor gestioacuten de los recursos y la rapidez para desplegar o escalar solucionesdando valor al cliente lo maacutes raacutepido posible es uno de los objetivos de todas lasempresas de base tecnoloacutegica
Las ventajas que ofrecen los planificadores con aplicaciones distribuidas sonnumerosas sin ir maacutes lejos empresas tan punteras como Google llevan maacutesde 10 antildeos orquestando contenedores24 Por un lado permiten aumentar elrendimiento de los equipos propios y por otro implementar un servicio comoplataforma para despliegues distribuidos sobre cualquier conjunto hardware deesta forma se provee un servicio similar al de la nube puacuteblica pero con laprincipal diferencia de que se elimina la independencia con el proveedor (vendorlock-in) esto es las aplicaciones no tienen limitaciones impuestas por eacuteste talescomo lenguaje de programacioacuten o herramientas y permite despliegues hiacutebridosentre recursos propios y la nube
83 Objetivos conseguidos
Implementacioacuten de los planificadores propuestos en la nube Se ha en-tendido y detallado el funcionamiento de estas herramientas y se hanimplementado en el servicio de infraestructura de Microsoft Azure
Despliegue de aplicaciones y servicios distribuidos Servicios que se usanactualmente en la industria del desarrollo software asiacute como una aplica-cioacuten web con una arquitectura moderna han sido desplegados de formadistribuida en los equipos cumpliendo con la funcionalidad esperada ade-maacutes de consiguiendo una alta disponibilidad
Aproximacioacuten de arquitectura escalable Se ha hecho una aproximacioacutende infraestructura escalable de forma que sea parcialmente extrapolable aotros proveedores
24httpwwwnextplatformcom20160322decade-container-control-google
46
84 Liacuteneas de investigacioacuten
Siguiendo con la materia de este proyecto se presentan posibles liacuteneas deinvestigacioacuten
Analizar el despliegue con estas herramientas de aplicaciones de Big Datay comparar la eficiencia con respecto a soluciones especializadas
Analizar el rendimiento de los algoritmos de planificacioacuten antes pruebasde estreacutes y situaciones de alta contienda
Comparar el uso de estas herramientas con las praacutecticas actuales de laindustria o implementacioacuten en un sistema de produccioacuten real
47
Referencias
[1] LA Barroso y U Houmllzle laquoThe Datacenter as a Computer An Introduc-tion to the Design of Warehouse-Scale Machinesraquo En Morgan amp ClaypoolPublishers ()
[2] Systems Research Group ndash NetOS (University of Cambridge) The evolu-tion of cluster scheduler architectures 2016 url httpswwwclcamacukresearchsrgnetoscamsasblog2016-03-09-scheduler-architectureshtml
[3] A Das I Gupta y A Motivala SWIM Scalable Weakly-consistent Infection-style Process Group Membership Protocol Inf teacutec Dept of ComputerScience Cornell University url https www cs cornell edu ~asdasresearchdsn02-swimpdf
[4] D Dubhashi y A Das Mastering Mesos PACKT Publishing mayo de2016
[5] The Apache Software Foundation Apache Mesos documentation urlhttpsmesosapacheorg
[6] David Greenberg Building Applications on Mesos OrsquoReilly Media 2016[7] Armand Grillet Comparison of Container Schedulers Inf teacutec Technische
Universitaumlt Berlin[8] HashiCorp Consul documentation url httpswwwconsulio[9] HashiCorp Nomad documentation url httpsdcosio[10] Dan C Marinescu Cloud computing theory and practice Morgan Kauf-
mann 2013[11] Mesosphere DCOS documentation url httpswwwnomadproject
io[12] Microsoft Azure documentation url httpsazuremicrosoftcom
es-esdocumentation[13] D Ongaro y J Ousterhout In Search of an Understandable Consensus
Algorithm Inf teacutec Stanford University url httpsraftgithubioraftpdf
[14] Fei Teng laquoRessource allocation and schelduling models for cloud compu-tingraquo Tesis de mtriacutea Ecole Centrale Paris 2011
[15] A Williams y col Automation and Orchestration with Docker and Contai-ners A Comprehensive Overview of the Docker and Container Ecosystem3 The New Stack 2016
48
- Resumen
- Summary
- Iacutendice de figuras
- Introduccioacuten y objetivos
-
- Contexto
- Objetivos
- Estructura del documento
-
- Cloud Computing
- Nuevas cargas de trabajo
- Gestioacuten de recursos Planificadores
-
- Sistemas distribuidos
-
- Clasificacioacuten
-
- Herramientas
-
- DCOS
-
- Apache Mesos
- Ejemplos de uso
-
- Nomad
-
- Protocolo de consenso Raft
- Protocolo gossip SWIM
- Planificacioacuten
-
- Casos de uso y despliegue
-
- Aplicacioacuten Web
-
- DCOS
- Nomad
-
- Servicio de integracioacuten continua
-
- DevOps
- Integracioacuten Continua
- Jenkins con Nomad
- Jenkins con DCOS
-
- Escalando la infraestructura
-
- Disentildeo
- Implementacioacuten
-
- Resultados y conclusiones
-
- Comparacioacuten
- Conclusiones
- Objetivos conseguidos
- Liacuteneas de investigacioacuten
-
Los nodos participantes en el algoritmo pueden estar en tres estados
Liacuteder (Leader) Todos los cambios que realicen en el cluster pasan por eacutel pri-mero
Seguidor (Follower) Nodo pasivo cuya responsabilidad es responder a laspeticiones del nodo liacuteder
Candidato (Candidate) Maacutequina que no ha encontrado liacuteder y solicita sueleccioacuten
Supongamos que tenemos cinco equipos que acaban de arrancar el protocoloEn la figura 11 se observan los nodos y sus respectivos registros a la derecha
Figura 11 Equipos sin consenso ejecutando el protocolo RAFTFuente httpsgithubcomongardieraftscope
Al comenzar todos los nodos son seguidores esperando recibir comunicacioacutende un nodo que actuacutee como liacuteder Cada nodo tiene un tiempo de espera aleatoriodespueacutes del cual si no es informado por un liacuteder pasa a estado candidato y pideel ldquovotordquo al resto de los participantes El algoritmo divide el tiempo en plazos uncandidato pasa a liacuteder si recibe la mayoriacutea de los votos en un plazo determinadoSe define mayoriacutea o cuoacuterum (quorum) comolceil
N2rceil
+ 1 (1)
donde N representa el nuacutemero de nodos
Para el ejemplo propuesto de 5 equipos se requieren de 3 votos Soacutelo losnodos que se encuentren en estado seguidor pueden votar una uacutenica vez a laprimera solicitud que reciba dentro de un plazo
Supoacutengase que el nodo denotado con S1 ha cumplido su tiempo de espera yrealiza la peticioacuten de voto (figura 12) A partir de este momento se pueden dartres casos
La maacutequina gana la eleccioacuten y pasa a ser liacuteder informando al resto
Otro servidor se establece como liacuteder en el mismo momento
Varios nodos pasan a ser candidatos por lo que ninguno consigue los votos
21
Figura 12 Un equipo pasa a estado candidato (RAFT)
Si un candidato recibe un aviso de un liacuteder en el mismo plazo el primeropasa a ser seguidor y se acaba la eleccioacuten de liacuteder
Por otro lado si un equipo candidato no recibe los votos en el plazo y agotasu tiempo de espera avanza al siguiente plazo y repite el proceso de votacioacutenLa tercera posibilidad puede conllevar a un estado indefinido ya que varioscandidatos pueden agotar su tiempo de espera al mismo tiempo y repartir losvotos Para solventarlo el algoritmo establece tiempos de espera aleatorios paralos candidatos
Siguiendo con el ejemplo propuesto el servidor S1 pasa a ser el liacuteder Cadacierto tiempo eacuteste debe realizar avisos a los nodos seguidores para no agotar sutiempo de espera
En este momento el cluster de servidores estaacute en ldquoconsensordquo y la informacioacutenen todos los nodos estaacute actualizada Un cambio en la informacioacuten inicia unproceso de replicacioacuten el liacuteder registra el cambio lo pasa al resto de nodos yuna vez eacutestos responden el cambio se hace efectivo
Supoacutengase que se realiza un cambio en los datos en la figura 13 en la partederecha se observa el cambio en el registro del servidor S1 que informa a losnodos seguidores En consecuencia los nodos registran el cambio y responden aS1
Figura 13 Cambio en un registro (RAFT)
Una vez el cuoacuterum (en el ejemplo tres equipos) informa al liacuteder de que
22
ha registrado el cambio el liacuteder lo hace efectivo en su sistema y notifica a losnodos que hacen lo mismo En la figura 14 el enviacuteo todaviacutea no ha llegado ala maacutequina S3 y se observa que no ha hecho efectivo el cambio (en el registroaparece punteado)
Figura 14 Aprobacioacuten del resto de equipos (RAFT)
Este protocolo funcionaraacute correctamente mientras exista un nuacutemero de nodosen funcionamiento igual o superior al cuoacuterum en el ejemplo propuesto elcuoacuterum es tres por lo que el sistema puede tolerar la caiacuteda de dos de los equipos
522 Protocolo gossip SWIM
Nomad permite la gestioacuten simultaacutenea de varios centros de datos reparti-dos en regiones geograacuteficamente separadas requiriendo de un protocolo ligeroque mantenga a los miembros actualizados sobre los participantes del conjun-to Para ello usa una ligera variante del protocolo SWIM[3] (Scalable Weakly-consistent Infection-style Process Group Membership Protocol) desarrollada porHashiCorp Estaacute clasificado como un protocolo de tipo gossip que debe su nom-bre a la semejanza con coacutemo se distribuye un rumor en una red social
SWIM se sustenta en dos caracteriacutesticas fundamentales la deteccioacuten de fallosy la distribucioacuten de la informacioacuten relativa a los miembros A continuacioacuten sedetalla el funcionamiento de ambos componentes
Deteccioacuten de fallos
Este componente tiene dos paraacutemetros el periodo de protocolo T y el nuacutemerode subgrupos de deteccioacuten de fallos k en los que se dividen los nodos Paracomprobar la comunicacioacuten entre dos maacutequinas usa la utilidad ping basadaen el protocolo ICMP La deteccioacuten de caiacuteda de un servidor sigue el siguientealgoritmo
Durante el periodo T cada miembro Mi de un subgrupo elige otro al azar Mjdel mismo subgrupo y le enviacutea un mensaje ping para comprobar su estado Enel caso de que se cumpla un tiempo de espera determinado por una estimacioacuten
23
del tiempo de ida y vuelta (RTT por sus siglas en ingleacutes) de la red y no hayarespuesta Mi le vuelve a enviar un mensaje ping indirectamente a traveacutes deun nuacutemero k de miembros escogidos aleatoriamente De no recibir ninguna res-puesta Mi establece que Mj ha sufrido un fallo y lo etiqueta como ldquosospechosordquoinformando al componente de distribucioacuten
Figura 15 Diagrama de tiempo del protocolo SWIMFuente httpswwwcscornelledu
Componente de distribucioacuten
Se encarga de informar de cualquier cambio en los miembros a todo el con-junto Los eventos de nodo caiacutedo y la unioacuten o disociacioacuten de un miembro setransmiten a todos los servidores para que actualicen sus lista Para distribuirla informacioacuten a todos los nodos se podriacutea usar el meacutetodo de multicast perosuele estar deshabilitado Por ello se utiliza una teacutecnica de transmisioacuten denomi-nada Piggybacking mediante la cual se adjunta a los propios mensajes PINGy ACK del algoritmo la informacioacuten a distribuir reduciendo asiacute la congestioacutenen la red
523 Planificacioacuten
Proceso encargado de distribuir las tareas entre los nodos clientes de acuerdoa su estado
El planificador de Nomad estaacute basado en las publicaciones de Google sobresus herramientas de gestioacuten de clusters Borg y Omega14 y entiende los trabajosdescritos por el usuario como un estado deseado es decir su despliegue en unamaacutequina cliente de forma correcta y los clientes como el estado actual esto eslo que se encuentra en ejecucioacuten El registro actualizacioacuten o cancelacioacuten de un
14httpresearchgooglecompubspub43438html
24
trabajo asiacute como el fallo de un nodo cliente implican un cambio de estado atramitar por el sistema lo que se define como evaluacioacuten (evaluation) Esto uacutelti-mo supone comparar el estado actual (clientes) con el estado deseado (conjuntode trabajos registrados) y enviarlos a los planificadores correspondientes que seencargaraacuten de asignar las tareas a los nodos clientes
Figura 16 Procedimiento de asignacioacuten en NomadFuente httpswwwnomadprojectio
En la figura 16 se observa el flujo de trabajo en el que las distintas evalua-ciones se encolan en el evaluation broker que se ejecuta en el servidor liacuteder ygestiona las evaluaciones pendientes asignaacutendoles prioridades
A continuacioacuten los nodos servidores ejecutan los scheduling workers queprocesan las evaluaciones llamando a los distintos planificadores que generanun plan de asignacioacuten esto es un conjunto de relaciones entre las tareas y losnodos clientes donde se ejecutaraacuten Este proceso se divide en dos fases primerose descartan aquellos clientes que no cumplan los requisitos y posteriormentese asigna una calificacioacuten al resto Se selecciona el nodo con mayor puntuacioacuteny se encola el plan en el gestor que se ejecuta en el servidor liacuteder Existen tresplanificadores de acuerdo al tipo de trabajo
Service Incluye aquellos trabajos que estaacuten destinados a ejecutarse en un pe-riacuteodo largo de tiempo Para realizar las asignaciones el planificador evaluacuteala mayor parte de los nodos y usa una versioacuten del algoritmo Best fit in-fluenciada por el trabajo de Google en su herramienta Borg Se trata deun algoritmo de planificacioacuten que sacrifica tiempo a cambio de maximizarel rendimiento de los clientes asignando la tarea a la maacutequina que tengala mayor carga de trabajo con el objetivo de reducir equipos en funciona-
25
miento
Batch Tareas que incluyen listas de comandos en general de menor duracioacuteny que no requieren interaccioacuten con el usuario Se vale del algoritmo deSparrow desarrollado por la universidad de Berkeley15 para limitar losnodos clientes a evaluar
System Trabajos destinados a ejecutarse en todos los nodos incluso los que seunen al cluster posteriormente
Core Mantenimiento interno de Nomad
Una vez se ha realizado el proceso de planificacioacuten el nodo liacuteder lo registra enla cola de planes (plan queue) que se encarga de asignarles prioridad y manejarcondiciones de carrera es decir que no accedan a los recursos de los clientes sincontrol y evitar que eacutestos superen su capacidad
La maacutequina liacuteder del conjunto puede de este modo aceptar una asignacioacuteny ser ejecutada por los clientes o por el contrario rechazaacutersela al planificadorlo que implicariacutea realizar un plan parcial o totalmente nuevo
Finalmente el estado de las evaluaciones se actualizan y los clientes soninformados de las asignaciones ejecutaacutendose las tareas
15httppeopleeecsberkeleyedu~keopublicationssosp13-final17pdf
26
6 Casos de uso y despliegue
Con el objetivo de mostrar las posibles utilidades que este tipo de sistemaspueden tener en las infraestructuras TI actuales se han desplegado las dos he-rramientas en la nube Microsoft Azure usando su servicio cloud de instancias demaacutequinas virtuales Linux para simular un conjunto de ordenadores conectadosentre siacute por una red LAN Sobre ellas se ha implementado dos casos de usouna aplicacioacuten web con una arquitectura con cierta orientacioacuten a microserviciosy un sistema de integracioacuten continua
El coacutedigo y todos los ficheros de configuracioacuten se pueden encontrar en elrepositorio del proyecto en GitHub16
61 Aplicacioacuten Web
Se busca simular el proceso de adaptacioacuten de una solucioacuten web para su des-pliegue en un sistema distribuido con las herramientas anteriormente descritascon el objetivo de aumentar tanto su escalabilidad como disponibilidad medianteredundancia
Se ha partido de una aplicacioacuten ya existente17 un servicio de almacenamien-to y reproduccioacuten de canciones A grandes rasgos este servicio permite crearusuarios subir canciones con sus respectivas portadas tener playlists propias yescuchar las canciones a traveacutes de un navegador web
La solucioacuten estaacute dividida en 4 partes (figura 17)
Una vista web con la loacutegica
Un almacenamiento conectado en red (NAS por sus siglas en ingleacutes)
Una API REST para gestionar las peticiones al almacenamiento
Base de datos NoSQL basada en MongoDB
La nueva tendencia de los proyectos web es su implementacioacuten en contene-dores Docker ya que facilitan su portabilidad y ofrecen un procedimiento dedespliegue raacutepido sobre todo a la hora de desarrollar y realizar pruebas en en-tornos de produccioacuten simulados Por ello en este caso se va a hacer uso de los
16httpsgithubcomAntonioAlfrzCloud-Orchestrators17httpsgithubcomsonsoleslpCDPSfy
27
motores de orquestacioacuten de contenedores de ambas herramientas Marathon enDCOS y el controlador Docker en el caso de Nomad
Figura 17 Arquitectura aplicacioacuten web
A continuacioacuten vamos detallar el despliegue en ambas herramientas de es-ta solucioacuten y observar tanto queacute dificultades se encuentran como que ventajasofrecen El objetivo final es adaptar el proyecto modificaacutendolo lo menos posiblecon objeto de analizar la capacidad de estas herramientas para desplegar cual-quier aplicacioacuten sin que eso conlleve la modificacioacuten de la arquitectura de eacutestaes decir que no sea dependiente del entorno
611 DCOS
Se ha descrito DCOS como una herramienta que se despliega sobre un con-junto de ordenadores y que permite instalar gestionar el despliegue de sistemasdistribuidos
Microsoft Azure cuenta con una plantilla para desplegar en su servicio cloudun cluster de maacutequinas virtuales con DCOS ya instalado que cuenta con
Maacutequinas maestras (1 3 o 5 a seleccionar por el usuario) configuradascomo un conjunto de disponibilidad esto eso Azure da ciertas garantiacuteasde que al menos una maacutequina estaraacute en funcionamiento
Maacutequinas agentes Por motivos de seguridad se distinguen dos roles
bull Nodos privados solo accesibles desde la red interna y configuradoscomo un conjunto de escala un recurso de Azure para gestionar ydesplegar maacutequinas con configuraciones ideacutenticas para permitir unraacutepido escalado
bull Un equipo conectado accesible desde Internet a travntildees de un balan-ceador de carga puacuteblico y situado en una subred externa
28
Dos balanceadores de carga
bull La interfaz puacuteblica del cluster que se conecta con el cliente puacuteblicobull Acceso a los equipos maestros para el administrador que soacutelo permiteconexioacuten mediante SSH y credenciales
Almacenamiento para todas las maacutequinas
Configuraciones necesarias de red y seguridad
En la figura 18 se observa un diagrama de la infraestructura
Figura 18 Infraestructura en Azure
El primer obstaacuteculo es la persistencia de estado de la aplicacioacuten que seconsigue gracias a una base de datos no relacional basada en MongoDB asiacutecomo el almacenamiento de las canciones Para implementarla tenemos variasposibilidades
Montar un sistema externo de almacenamiento conectado en red en todoslos agentes donde se ejecuten las tareas de esta manera si una tarea pasade un nodo a otro por cualquier motivo puede tener acceso a los mismosficheros (opcioacuten del caso de uso original)
Implementar un sistema de ficheros distribuidos en los agentes
Usar los servicios de almacenamiento de las nubes puacuteblicas
Aprovechar el sistema de voluacutemenes persistentes de Apache Mesos Eacutestepermite reservar recursos de un agente de forma que al arrancar una tarease crea un volumen independiente del ciclo de vida de eacutesta con ello esosrecursos donde se ha almacenado la informacioacuten pueden volver a ofrecerseal mismo entorno de tal manera que otra tarea pueda acceder a ella
DCOS aprovecha este sistema de voluacutemenes persistentes y permite instalarbases de datos distribuidas como ArangoDB o Apache Cassandra sin embargoesto implicariacutea modificar todo el coacutedigo referente al modelo de la base de datos
29
Por motivos de eficiencia y latencia asiacute como de una mayor gobernabilidadde los datos la mejor opcioacuten es usar el recurso de voluacutemenes persistentes queofrece Apache Mesos ya que de esta manera se gestionariacutea la aplicacioacuten completamediante una uacutenica herramienta Sin embargo esto implica que la informacioacutense encuentra exclusivamente en el agente donde se haya ejecutado la tarea y porlo tanto se sigue requiriendo de software externo para distribuir la informacioacutenpara que se accesible para todos los agentes A la hora de realizar este proyectose encontraba en desarrollo Flocker una solucioacuten desarrollada por ClusterHQque permite compartir los voluacutemenes de Docker a traveacutes de un cluster quesi bien es compatible con el planificador de Mesos el proyecto se encontrabatodaviacutea en fases tempranas de desarrollo y los sistemas de almacenamiento quesoporta quedaban fuera del aacutembito de este trabajo
Por todo ello dado que las maacutequinas se han desplegado en la nube puacuteblicade Azure se decidioacute usar su servicio de almacenamiento de objetos para lascanciones y otra maacutequina para desplegar MongoDB y asiacute mantener el modelode datos original de la aplicacioacuten La diferencia del almacenamiento de obje-tos con respecto a nivel de fichero es que el primero no tiene jerarquiacutea paraorganizar los archivos eacutestos se guardan como objetos (con sus metadatos) enun mismo espacio soacutelo diferenciaacutendose por un identificador uacutenico esto implicaentre otras cosas que se puede acceder a un fichero dado uacutenicamente su IDindependientemente de la localizacioacuten fiacutesica de eacuteste facilitando pues la gestioacuteny el desarrollo
El coacutedigo del proyecto se ha modificado en los siguientes apartados
Las direcciones de la base de datos y los balanceadores de carga asiacute comosus puertos estaban originalmente fijos Se han configurado como variablesde entorno para facilitar el descubrimiento del servicio y hacer transpa-rente la aplicacioacuten al entorno de despliegue
La API REST se ha adaptado al almacenamiento en Azure en vez de enlocal
Estas modificaciones no suponen un cambio sustancial pero permiten separala persistencia de las tareas ejecutadas por DCOS lo que facilita en granmedida su ejecucioacuten al ser totalmente sin estado y ademaacutes implican tenerlos datos bajo un mayor control
Para la orquestacioacuten de contenedores se va a usar el entorno Marathondesarrollado tambieacuten por Mesosphere Eacuteste se puede usar a traveacutes de una interfazgraacutefica la interfaz de liacutenea de comandos (en lo que sigue CLI por sus siglas eningleacutes) de DCOS o con su API HTTP
Primero se han publicado la imaacutegenes de los contenedores que encapsulanla interfaz web y la api de la aplicacioacuten en el repositorio puacuteblico DockerHub
Los despliegues en este entorno se describen mediante ficheros JSON en losque se detalla entre otras opciones la imagen del contenedor los puertos a usar
30
los recursos que debe ocupar en un nodo o las instrucciones de monitorizacioacuten
Para el servicio de descubrimiento DCOS ofrece la posibilidad de asignardirecciones IP virtuales (VIP por sus siglas en ingleacutes) a tareas que se compartenen todos los nodos DCOS lleva integrado un balanceador de carga a nivel TCP(el componente denominado Minuteman) que balancea entre las direccionesvirtuales de las tareas y todas las instancias de eacutestas a lo largo del cluster Estoes necesario por dos motivos equilibrar la carga de los equipos con el fin deevitar un punto de uacutenico fallo mediante redundancia y evitar la contienda dedirecciones al ejecutar las tareas en puertos aleatorios
Este balanceador de carga estaacute basado en el trabajo de Michael Mitzenma-cher The Power of Two Choices in Randomized Load Balancing18 A grandesrasgos el algoritmo mantiene una media moacutevil exponencial de latencias paracada destino (backend) ademaacutes de las caiacutedas consecutivas Si un destino noresponde a una negociacioacuten en tres pasos (three way handshake) de forma con-secutiva en un periodo inferior a 5 ms se considera caiacutedo El algoritmo iterasobre los destinos disponibles en base a su histoacuterico de fallos y escoge dos deforma aleatoria de los cuales coge el de mejor meacutetrica
Las direcciones virtuales soacutelo se pueden resolver dentro del cluster porello para implementar la interfaz puacuteblica de la aplicacioacuten esto es el balancea-dor de carga de la interfaz web usaremos un paquete de DCOS denominadomarathon-lb un balanceador basado en HAProxy y adaptado por MesosphereEn este caso equilibra la carga de todas instancias de las tareas ejecutadas porel entorno Marathon por sus etiquetas y permite ademaacutes definir como puntode entrada muacuteltiples hosts virtuales definidos por sus nombres completos dedominio (FQDN por sus siglas en ingleacutes) en nuestro caso la interfaz puacuteblicadel balanceador de Azure para los agentes
Por motivos de seguridad todas las tareas se ejecutan en los agentes privadoses decir los que son exclusivamente accesibles desde la red interna Por su partemarathon-lb se ejecuta en el agente puacuteblico que cuenta con IP puacuteblica y lospuertos 80 (HTTP) y 8080 abiertos de forma que la aplicacioacuten sea accesibledesde Internet Esto es posible debido a que Apache Mesos permite reservarrecursos mediante roles asignados a nodos para un uso especiacutefico De esta formala arquitectura vista desde la aplicacioacuten quedariacutea como en la figura 19
18httpswwweecsharvardedu~michaelmpostscriptstpds2001pdf
31
Figura 19 Arquitectura de la aplicacioacuten web en DCOS
Ejecucioacuten
A la hora de desplegar la aplicacioacuten DCOS puede gestionarse medianteuna interfaz graacutefica o una interfaz de liacutenea de comandos La primera se accedea traveacutes de un navegador web en el puerto 80 (HTTP) y permite instalar losentornos disponibles observar el estado de los nodos y las tareas que se estaacutenejecutando y los ficheros de registros que eacutestas generan
La CLI permite el control desde un nodo o una maacutequina remota (suponiendoque los maestros tienen IP puacuteblica y el puerto 80 abierto) ya que DCOS tieneun sistema de autorizacioacuten que permite tener una interfaz puacuteblica con ciertasgarantiacuteas de seguridad
Por su parte cada entorno de trabajo puede ser controlado por la CLI peroademaacutes cuenta con sus propias interfaces Marathon expone una API HTTPen el puerto 8080 de la direccioacuten puacuteblica de los maestros del cluster asiacute comootra interfaz graacutefica Para desplegar un contenedor se podriacutea usar la CLI
$ dcos marathon app add lt f i l e j songt
O la API HTTP
$ cu r l minusX POST http lt ip_maestro gt8080v2apps minusd ltf i l e jsongt minusH Contentminustype app l i c a t i o n j son
32
612 Nomad
La arquitectura de Nomad es maacutes sencilla ya que solo requiere de un ficheroejecutable en todos los nodos para funcionar Si DCOS es la base de instala-cioacuten de entornos de terceros Nomad integra todas las funcionalidades baacutesicasesto es gestor de recursos planificador y ejecutor en los nodos cliente Estaherramienta cuenta con un menor tiempo de desarrollo y en el momento deescribir este documento cuenta exclusivamente con los siguientes controladoresen comparacioacuten con los entornos de DCOS
Motor Docker es decir funcioacuten de orquestacioacuten de contenedores
Ejecucioacuten de archivos binarios como comandos de Shell
Ejecucioacuten de aplicaciones Java
Virtualizacioacuten de maacutequinas mediante tecnologiacutea QEMU
Todos ellos necesitan que la tecnologiacutea subyacente esteacute instalada en las maacute-quinas clientes (Docker Java QEMU) Actualmente no permite el registro decontroladores por parte de terceros aunque estaacute planificado en un futuro ofreceruna interfaz para su desarrollo
Nomad no cuenta con el servicio de descubrimiento sin embargo puede inte-grarse con la herramienta Consul desarrollada por la misma empresa Por otrolado para el balanceo de carga usaremos un contenedor Docker con HAProxyuna herramienta de coacutedigo abierto que ofrece tanto servicios de proxy como debalanceador y cuyos ficheros de configuracioacuten completaremos con el proyectoConsul Template19
Consul
Consul sigue la misma arquitectura que Nomad es decir un nodo servidorque orquesta un conjunto de maacutequinas clientes y permite a los procesos que seejecutan en los equipos definirlos como servicios ofreciendo diversas caracteriacutes-ticas entorno a estos de los cuales vamos a usar dos
Descubrimiento de servicio Las maacutequinas clientes publican en el cataacutelogode servicios las tareas en ejecucioacuten y Consul les asigna nombres de dominioaccesibles por todos los miembros del cluster a traveacutes de la interfaz DNSincluida en esta herramientaConsul se integra con Nomad de forma que todas las tareas que se ejecu-ten en la segunda son automaacuteticamente publicados como servicios de laprimera de esta manera no hace falta conocer la direccioacuten de la maacutequinacliente donde se esteacute ejecutando el proceso ya que se puede acceder a eacutela traveacutes de su nombre de dominio de forma transparente Por ejemplo si
19[httpsgithubcomhashicorpconsul-template]
33
ejecutamos una tarea con ID web en el puerto 8080 se puede acceder aella en la direccioacuten webserviceconsul8080Para que las direcciones propias de Consul las resuelva su propio DNS y noel que esteacute asignado por defecto en la maacutequina usaremos la herramientadnsmasq20 que permite especificar la direccioacuten de un servidor DNS paraconsultas de direcciones especiacuteficas
Monitorizacioacuten Permite realizar comprobaciones del servicio y seguir su esta-do Aprovecharemos esta funcionalidad tanto para definir el propio procesode Nomad como servicio de Consul como las tareas desplegadas
HAProxy + Consul Template
HAProxy es una solucioacuten versaacutetil de coacutedigo abierto que ofrece solucionesde balanceo de carga y proxy Existen otras herramientas en el mercado comoNGINX o ldirectord sin embargo HAProxy suponiacutea una solucioacuten sencilla deconfigurar para mostrar el caso de uso
El uso de estas herramientas se debe a dos motivos para que no existacontienda con respecto a los puertos de los clientes usados por las tareas eacutestos sevan a asignar de forma dinaacutemica lo que en principio implicariacutea que la aplicacioacutendeberiacutea realizar consultas DNS de tipo SRV (que incluye puertos) a la interfazde Consul y balancear la carga entre tareas por redundancia y capacidad
Como la direccioacuten IP y puerto son variables cada vez que las tareas seactualicen o se reasignen es necesario volver a configurar HAProxy de formamanual Por ello HashiCorp ha desarrollado un programa denominado Con-sul Template que realiza peticiones sucesivas a la interfaz HTTP de Consul delas direcciones fiacutesicas de un servicio y reinicia automaacuteticamente el proceso deHAProxy Asiacute definiendo estas tareas como servicios Consul podremos tantomonitorizarlas como escalar las tareas dinaacutemicamente sin necesidad de cambiarel balanceador A partir del contenedor Docker oficial de HAProxy se ha desa-rrollado otro con la configuracioacuten baacutesica y con Consul Template para desplegarlocomo una tarea en Nomad
Despliegue
Se ha usado el mismo coacutedigo que en el apartado anterior con la persistenciaen el servicio de almacenamiento de Azure Desde la perspectiva del hardwarese implementaraacute la misma infraestructura que en el caso de DCOS (figura 18)estos es definiremos dos tipos de maacutequinas clientes un agente que se conectaraacutecon el balanceador de carga con nombre de dominio puacuteblico y donde se desple-garaacute el balanceador de carga de la vista web y agentes privados no accesiblesdesde fuera del cluster y donde se ejecutaraacuten el resto de tareas en la red inter-na La principal diferencia radica en las tareas que ejecutan HAproxy y ConsulTemplate que sustituye a las direcciones IP virtuales que ofrece DCOS
20httpwwwthekelleysorgukdnsmasqdochtml
34
Figura 20 Despliegue en Azure de Nomad+Consul
Cabe matizar que los balanceadores basados en HAProxy se implementanpor necesidad de la aplicacioacuten para el descubrimiento del servicio a diferenciade los de Azure que se implementan por motivos de seguridad y escalabilidaddel cluster en siacute
Configuracioacuten Nomad
Los ficheros de configuracioacuten de las maacutequinas maacutester y cliente son similaresy comparten la mayoriacutea de las opciones como por ejemplo el nombre del nodoo la interfaz de red donde escucha Nomad las peticiones Sus opciones son engeneral auto-explicativas sin embargo existen dos detalles que matizar
El proceso de Nomad escucha las peticiones tanto de los protocolos deconsenso como del usuario a traveacutes de una interfaz de red que se debeindicar en el fichero de configuracioacuten
En el caso de los clientes se deben indicar las direcciones de los servidoresdel cluster sin embargo se trata de un sistema dinaacutemico en el que losnodos pueden sufrir errores y cambiar de direccioacuten Por ello se ha definidoNomad como un servicio de Consul y asiacute poder definir la direccioacuten de losservidores como un nombre de dominio no por su direccioacuten fiacutesica que elservidor DNS de Consul se encargaraacute de resolver
Por defecto Nomad usa los siguientes puertos
API HTTP 4646 Peticiones HTTP y recepcioacuten de oacuterdenes mediante laliacutenea de comandos
RPC 4647 Protocolo de consenso entre los nodos del cluster
Serf 4648 Protocolo de gossip entre los servidores de los centros de datosgobernados por Nomad
35
Los dos uacuteltimos deben ser interfaces alcanzables por otros nodos sin embargo laAPI HTTP por motivos de seguridad deberiacutea ser local ya que en caso contrariocualquier persona con acceso a ella tiene el control sobre la herramienta Eacutestasolo deberiacutea estar accesible en un servidor o gestionarlo mediante una terminalSSH por ejemplo En este trabajo al ser una prueba de concepto se ha abiertoen todos los nodos
Trabajos de Nomad
Las tareas se detallan en ficheros con formato HashiCorp Configuration Lan-guage un derivado del formato JSON creado por la empresa que le da nombrecompatible con eacuteste y que permite comentarios
En estos ficheros se puede definir
La regioacuten y el centro de datos donde se ejecutaraacute (Nomad permite lagestioacuten de centros de datos geograacuteficamente distribuidos en regiones)
La poliacutetica de actualizacioacuten de la tarea
Grupo de tareas esto es que se ejecutaraacuten en el mismo nodo
El nuacutemero de grupos a ejecutarescalar asiacute como los liacutemite que debencumplir los nodos asignados
La poliacutetica de reinicio ante fallo o error
Tareas El controlador su configuracioacuten los paraacutemetros del servicio aso-ciado a registrar en Consul asiacute como los recursos que consume (puertosmemoria)
En nuestro caso usamos sobre todo el controlador Docker esto eso orques-tacioacuten de contenedores en los nodos clientes y tres de sus opciones
Imagen del contenedor Se han subido todas las imaacutegenes del proyecto a Doc-ker Hub donde por defecto se busca la imagen
Puertos Los puertos a usar por el contenedor que pueden ser estaacuteticos asigna-dos por el usuario o dinaacutemicos siendo Nomad el que se encarga de mapearun puerto libre del nodo cliente al expuesto por el contenedor
Servidores DNS Como usamos la interfaz DNS de Consul como descubri-miento de servicio se debe configurar el contenedor para que use cualquiernodo del cluster como servidor DNS
Configuracioacuten Consul
Al ser desarrolladas por la misma empresa los ficheros de configuracioacuten deConsul y Nomad comparten muchas opciones Consul tambieacuten acepta peticionesa traveacutes de una interfaz de red siendo los puertos usados por defecto
36
RPC 8300 8400 Maneja la peticiones del resto de nodos y usuarios
Serf 8301 8302 Protocolo gossip
HTTP API 8500
HTTPS API Desactivada por defecto
Interfaz DNS 8600
Se debe asignar a los protocolos internos del cluster esto es RPC y Serf unainterfaz alcanzable por los nodos y por el contrarioasignar a los dos uacuteltimos ala interfaz de loopback por motivos de seguridad
Cabe destacar que Consul tambieacuten cuenta con una interfaz graacutefica que per-mite ver el estado de los equipos y los servicios registrados y que se encuentra enel mismo puerto que la API HTTP en la direccioacuten httpIP_EQUIPO8500ui
Ejecucioacuten
Tanto Nomad como Consul requieren de la ejecucioacuten de un fichero en todoslos nodos integrantes del cluster Como prueba de concepto se ha decidido usardos servidores para ambos aunque cabe matizar que es un nuacutemero ineficienteya que la caiacuteda de uno de ellos supondriacutea la peacuterdida del cuoacuterum y por tantodel consenso del cluster
En primer lugar se arrancan los servidores que son los encargados de ejecu-tar el protocolo de consenso y gestionar el cluster y a continuacioacuten los clientesque no tienen praacutecticamente estado y dependen de los servidores
En el caso de Consul se debe indicar el directorio donde se guardan losficheros que describen los servicios asiacute como el archivo que especifica el resto delas opciones
1 Se inicia el primer servidor en uno de los equipos
$ consu l agent minuscon f i gminusd i r e t c consu l d s e r v i c e s minuscon f i gminus f i l e consu l_server j son
2 Los siguientes equipos deben unirse al anterior por lo que antildeadimos elargumento join con la direccioacuten del primer servidor Para el caso de otrosservidores
$ consu l agent minuscon f i gminusd i r e t c consu l d s e r v i c e s minuscon f i gminus f i l e consu l_server j son minus j o i n ltIP_servidor1gt
37
Una vez los servidores han alcanzado el consenso y elegido un liacuteder en losclientes
$ consu l agent minuscon f i gminusd i r e t c consu l d s e r v i c e s minuscon f i gminus f i l e c on su l_c l i en t j son minus j o i n ltIP_cualquierServ idorgt
El proceso para iniciar Nomad es igual y los comandos similares sin embargoya no es necesario indicar una direccioacuten IP fija en los equipos sino el nombre dedominio del servicio de Nomad registrado por Consul En el primer servidor
$ nomad agent minusc on f i g nomad_server j son
Y el resto de equipos (con su fichero de configuracioacuten correspondiente)$ nomad agent minusc on f i g nomad_server j son minus j o i n nomad s e r v i c e consu l
Por uacuteltimo para desplegar la aplicacioacuten web se han escrito tres ficherosque detallan las tareas de la interfaz web API y los balanceadores de cargaMediante la CLI
$ nomad run minusaddress=http lt ip_c lus te r gt4646 lt f i l e hclgt
O mediante la API HTTP de Nomad$ cu r l minusX POST minusd ltf i l e hclgthttp lt ip_c lus te r gt4646 jobltjob_namegt
Ansible
Como se puede comprobar con el aumento del nuacutemero de equipos pasa aser inviable manejar todos los nodos a traveacutes de terminal Ademaacutes como seha comentado con anterioridad Nomad requiere que en los nodos clientes es-teacuten instalados las herramientas que soporten las tareas por ejemplo el motorde Docker Por ello para facilitar tanto el arranque como la instalacioacuten de lasdependencias vamos a usar Ansible una herramienta de coacutedigo abierto desarro-llada en Python que permite gestionar configuraciones aprovisionar recursosdespliegue de aplicaciones de forma automaacutetica
A grandes rasgos esta herramienta funciona mediante ficheros en formatoYAML denominados play-books que describen un conjunto de pasos a ejecutaren una lista de equipos remotos Estos pasos son ejecutados por moacutedulos inde-pendientes a traveacutes de SSH es decir en cualquier ordenador con conexioacuten a los
38
hosts dado su contrasentildea o clave puacuteblica puede arrancar el script y realizariacutealos pasos de forma remota gestionando el cluster desde un solo equipo
Se han desarrollado guiones para lo siguiente
Descarga de los binarios de Nomad y Consul en todos los nodos copiade los ficheros de configuracioacuten baacutesicos y modificarlos de acuerdo a cadanodo (nombre del equipo direccioacuten IP)
Instalacioacuten de las dependencias
Arranque de Nomad y Consul
Ansible extiende su funcionalidad a traveacutes de moacutedulos independientes que per-miten por ejemplo instalar paquetes mediante herramientas de gestioacuten de pa-quetes (APT yum) aprovisionar automaacuteticamente maacutequinas virtuales de Ama-zon EC2
Algunas opciones de los ficheros de configuracioacuten de Nomad y Consul sondependientes del nodo particular por ejemplo la interfaz de red Para estetrabajo se ha realizado un moacutedulo para modificar los ficheros de configuracioacutende forma automaacutetica En el repositorio del proyecto se encuentra una carpetadonde se encuentran todos los ficheros necesarios para desplegar un clustertotalmente funcional solo requiere de una liacutenea de terminal con Ansible
$ ans ib l eminusplaybook minus i hos t s minusk ltssh_passgt minusu ltnode_usergt s i t e yml
39
62 Servicio de integracioacuten continua
Se ha implementado un sistema de integracioacuten continua que permite ejecu-tar tareas de compilacioacuten y pruebas de forma distribuida aumentando asiacute elrendimiento de los equipos En primer lugar se detallaraacute los motivos por los quepuede resultar beneficioso para las empresas una implementacioacuten de este tipo alo que seguiraacute los detalles del despliegue
621 DevOps
Metodologiacutea que defiende la comunicacioacuten y colaboracioacuten entre desarrolla-dores de software y los profesionales de operaciones a lo largo de todo el ciclo devida de una aplicacioacuten Estaacute muy relacionado con el desarrollo aacutegil de softwareesto es un enfoque para los proyectos que defiende el desarrollo iterativo e in-cremental donde los requisitos y soluciones evolucionan con el tiempo seguacuten lanecesidad del proyecto DevOps extiende esta filosofiacutea a todas los componentesde un servicio incluyendo sistemas y operaciones
Se trata de un concepto que cada organizacioacuten o empresa adapta a suspropias necesidades y procesos de negocio en este proyecto nos vamos a centraren la integracioacuten continua una praacutectica fundamental tanto del desarrollo aacutegilcomo de esta filosofiacutea
622 Integracioacuten Continua
Se define como una praacutectica de desarrollo software donde los miembros delequipo ponen en comuacuten su trabajo frecuentemente al menos una vez al diacutea21Cada integracioacuten se verifica con una compilacioacuten automaacutetica que incluye laejecucioacuten de pruebas para detectar errores de integracioacuten tan pronto como seaposible
Desde el punto de vista operativo esto supone automatizar la configuracioacutende equipos o el despliegue de maacutequinas virtuales donde compilar el proyecto yejecutar las pruebas y posteriormente eliminarlas Este flujo de trabajo se vebeneficiado en entornos distribuidos ya que el objetivo del desarrollador es com-probar el resultado de las pruebas raacutepidamente sin preocuparse del despliegueo los propios equipos
Para esta prueba de concepto vamos a usar Jenkins un servidor de integra-cioacuten continua escrito en Java que nos permite definir trabajos que contendraacutenla descripcioacuten tanto del entorno como su ejecucioacuten
Este sigue una estructura maestro-esclavo muy similar al de los gestores declusters usados en este proyecto el maestro contiene toda la loacutegica del servicio
21httpmartinfowlercomarticlescontinuousIntegrationhtml
40
trabajos autenticacioacuten y los esclavos son los encargados de la ejecucioacuten ensiacute Jenkins tiene varias viacuteas para aprovisionar los uacuteltimos
Mediante SSH
Interfaz graacutefica
Desarrollar un script propio
Ejecucioacuten de un fichero java
La ventaja de usar planificadores es que el despliegue de esclavos es dinaacutemicoes decir no tener una maacutequina especiacuteficamente configurada para ello DCOS yNomad se encargaraacuten de configurar estos despliegues en sus maacutequinas y poste-riormente eliminarlos Para ello se ha usado la uacuteltima opcioacuten definiendo tareasque descarguen el fichero java Con todo ello se consigue un entorno de inte-gracioacuten continua eficiente que ademaacutes permite la ejecucioacuten de otros servicios deforma independiente
Jenkins permite la creacioacuten de plugins que extienden sus funcionalidadesTanto Nomad22 como Apache Mesos cuentan con uno que permite su integra-cioacuten
Para esta prueba se va a usar el mismo proyecto que para el caso de usode orquestacioacuten de contenedores la aplicacioacuten web al que se le ha antildeadido untest para comprobar que se conecta correctamente a la base de datos medianteMocha un framework de Nodejs Por otro lado se antildeade el plugin de git ya queel coacutedigo se obtiene de GitHub el repositorio remoto de control de versiones delproyecto
El proceso general de ejecucioacuten seriacutea como sigue
1 Se ejecuta el maestro de Jenkins como tarea Docker partiendo de la imagenoficial
2 Al arrancar un trabajo se manda una tarea a los planificadores que laasignaraacuten a un nodo cliente Esta tarea consiste en la descarga del ficherode configuracioacuten Java y arrancarlo configurando el equipo como un clientede Jenkins temporalmente
3 Jenkins ejecuta el trabajo en el nuevo cliente en este caso iniciar la apli-cacioacuten web iniciar las pruebas y generar un informe
4 Se elimina el cliente
A continuacioacuten se detallan los matices de cada herramienta a la hora de imple-mentar este servicio
22Desarrollado por Ivo Verberk httpwwwivoverberknl
41
623 Jenkins con Nomad
El plugin permite la ejecucioacuten del fichero Java mediante dos controladorescontenedores Docker y Java En este proyecto nos hemos decantado por el pri-mero ya que nos ahorra instalar la maacutequina virtual de java en todos los nodoscliente Por ello se ha construido un contenedor base con Java para la ejecucioacutendel fichero de configuracioacuten y Nodejs para lanzar la aplicacioacuten web
El plugin se configura con la direccioacuten IP del cluster y el contenedor queejecuta el esclavo Jenkins Por su parte el trabajo en Jenkins se define conel repositorio en GitHub donde se aloja el coacutedigo del proyecto a probar y loscomandos a ejecutar en este caso npm update y npm test
624 Jenkins con DCOS
En el caso de DCOS su sistema de paquetes incluye Jenkins por lo queal instalarlo ya se tiene la configuracioacuten de Mesos totalmente funcional Sinembargo para ejecutar la aplicacioacuten en particular y las pruebas se requiere deNodejs en los equipos esclavos por ello debemos antildeadir un plugin de Jenkinsque permite instalar este entorno antes de ejecutar el trabajo Una vez hechoesto soacutelo queda definir la tarea igual que en el caso anterior
Cabe destacar que Mesosphere tambieacuten ha desarrollado un plugin que per-mite hacer despliegues en Marathon de tal manera que permitiriacutea con cadacommit del coacutedigo compilar la imagen del contenedor Docker y desplegarlaautomaacuteticamente aunque en este proyecto no se ha hecho pruebas de esta fun-cionalidad
42
7 Escalando la infraestructura
Uno de los factores clave que se busca a la hora de implementar sistemasdistribuidos es el poder escalar la infraestructura de forma maacutes sencilla estoes detectar que las maacutequinas estaacuten alcanzando el liacutemite de su capacidad yaumentar eacutesta ya sea mejorando sus caracteriacutesticas teacutecnicas o antildeadiendo maacutesnodos al cluster
El coacutedigo y todos los ficheros de configuracioacuten de esta seccioacuten tambieacuten sepueden encontrar en el repositorio del proyecto en GitHub23
71 Disentildeo
Microsoft Azure permite organizar los servicios cloud de forma loacutegica a traveacutesde grupos de recursos y asiacute poder crear o eliminar eacutestos en conjunto parauna aplicacioacuten determinada (por ejemplo una aplicacioacuten web suele requerir demaacutequinas virtuales bases de datos almacenamiento) Ademaacutes dispone dela opcioacuten de crear plantillas en formato JSON que permite al desarrolladordefinir los recursos y su interrelacioacuten para desplegar de forma automaacutetica unainfraestructura TI en la nube
Azure tambieacuten ofrece la posibilidad de monitorizar el estado de las maacutequinasvirtuales a traveacutes de extensiones lo que permite configurar el escalado automaacute-tico al alcanzar cierto liacutemite definido por el operador Eacutesta es a priori la formaen que deberiacutea implementarse hablando en teacuterminos de eficiencia sin embargoesta aproximacioacuten es totalmente dependiente de la plataforma es decir no sepuede extrapolar a otro proveedor o sobre recursos propios sin realizar un nue-vo disentildeo En este proyecto las tareas que son ejecutadas por estos equipos notienen estado ya que todo lo relativo a la persistencia lo hemos asignado fueradel cluster esto permite escalar la plataforma a traveacutes de otra aproximaciones
Las plantillas aceptan una serie de variables a indicar por el usuario entreotras los conjuntos de escala para definir los nodos aceptan una variable quedefine el nuacutemero de maacutequinas que los componen Por otro lado Azure ofreceuna API REST y kits de desarrollo software (SDK por sus siglas en ingleacutes) quepermiten su despliegue de forma programaacutetica Aprovechando estas facilidadesen este proyecto se va a aproximar la escalabilidad con el sucesivo desplieguede la infraestructura de forma automaacutetica se monitorizan los equipos y si sedetecta una maacutequina excesivamente cargada se aumenta el nuacutemero de equiposen la plantilla y se vuelve a desplegar
23httpsgithubcomAntonioAlfrzCloud-Orchestrators
43
En este proyecto se han disentildeado las plantillas para desplegar la arquitec-tura necesaria tanto de Nomad como de DCOS En el caso de la primera eldespliegue es maacutes descriptivo ya que incluye maacutequinas virtuales grupos de se-guridad redes En el caso de DCOS Azure cuenta con un servicio especiacuteficopara clusters gobernados por DCOS denominado Azure Container Service queincluye los componentes necesarios y la instalacioacuten ya realizada
72 Implementacioacuten
En primer lugar para monitorizar el estado de los equipos se va a usar laherramienta Nagios un sistema que permite controlar el estado del hardwarey los servicios de un equipo Se trata de una herramienta muy completa de laque se va a usar su capacidad para ejecutar comandos (plugins) en los nodospara detectar picos de carga generar alertas y ejecutar programas para estoseventos
Se ha desplegado una maacutequina virtual con esta herramienta en ambos siste-mas y se ha instalado una extensioacuten de Nagios (Nagios Remote Plugin Executor)en todos los nodos que permite ejecutar comprobaciones remotamente en con-creto para esta prueba de concepto medir el nivel de saturacioacuten de la unidadcentral de procesamiento (CPU por sus siglas del ingleacutes) Cuando sucede uncambio de estado de una maacutequina esto es cuando este paraacutemetro supera el liacutemi-te definido por el operador Nagios permite actuar en consecuencia ejecutandoprogramas por ello se ha desarrollado un script que ejecuta lo siguiente
Un programa desarrollado en Python con el SDK de Azure que modificalas plantillas y despliega los recursos
Un guioacuten de Ansible para instalar todos los componentes necesarios en lasnuevas maacutequinas y arrancar de nuevo el cluster y las aplicaciones
44
8 Resultados y conclusiones
En este uacuteltimo apartado se da una visioacuten global del proyecto asiacute como a lasconclusiones maacutes importantes a las que se ha llegado y posibles temas futurosde desarrollo
81 Comparacioacuten
Ambas herramientas ofrecen las funcionalidades para gestionar los recursoseficientemente ofreciendo a los desarrolladores una plataforma donde desplegarsus aplicaciones de forma distribuida independientemente de los equipos fiacutesicosy el hardware que las soporten
DCOS es una herramienta que en un comienzo fue privativa pero cuyos res-ponsables la empresa Mesosphere decidieron publicar una versioacuten de coacutedigoEacutesta nos permite gestionar un cluster de una forma sencilla y usable ademaacutes decomplementarlo con otras herramientas como el balanceador de carga integradoo la autenticacioacuten de usuarios ademaacutes estaacute basada en Apache Mesos un pro-yecto de relativa madurez y con el soporte de la Apache Software FoundationDe forma resumida DCOS ofrece muchas posibilidades y servicios a cambiode una arquitectura e instalacioacuten maacutes compleja
Por su parte HashiCorp con menor tiempo de desarrollo ha conseguidouna herramienta muy sencilla de desplegar que ademaacutes cumple con todas lasfuncionalidades baacutesicas ejecutando un simple binario en cada nodo se puededesplegar un gestor de clusters totalmente funcional Sin embargo no cuentacon todas las posibilidades de Mesos (Nomad cuenta con menos controladoresque entornos posibles de Mesos) ni con los antildeadidos de DCOS lo que implicael uso de otras herramientas para complementar el servicio (Consul HAProxy)
De entre las dificultades encontradas al usar estas herramientas y desplegaraplicaciones sobre ellas se puede destacar la depuracioacuten en ocasiones se desco-noce si un error viene de la propia herramienta de la aplicacioacuten desplegada o delequipo fiacutesico si no se cuenta con un sistema de procesamiento de registro unose puede encontrar con muacuteltiples terminales abiertas inspeccionando numerososficheros de registro buscando posibles errores Ademaacutes no dejan de ser solucio-nes que para usar eficientemente se debe conocer parte de su funcionamientoy sintaxis a la hora de describir la tareas lo que supone un esfuerzo antildeadido yaque cada una tiene sus particularidades y liacutemites
45
82 Conclusiones
En una sociedad cada vez maacutes digital las empresas deben adaptarse a unmercado cuya demanda de contenido no deja de crecer Las nuevas arquitecturascomo microservicios asiacute como la gran cantidad de datos generada implica queuna mejor gestioacuten de los recursos y la rapidez para desplegar o escalar solucionesdando valor al cliente lo maacutes raacutepido posible es uno de los objetivos de todas lasempresas de base tecnoloacutegica
Las ventajas que ofrecen los planificadores con aplicaciones distribuidas sonnumerosas sin ir maacutes lejos empresas tan punteras como Google llevan maacutesde 10 antildeos orquestando contenedores24 Por un lado permiten aumentar elrendimiento de los equipos propios y por otro implementar un servicio comoplataforma para despliegues distribuidos sobre cualquier conjunto hardware deesta forma se provee un servicio similar al de la nube puacuteblica pero con laprincipal diferencia de que se elimina la independencia con el proveedor (vendorlock-in) esto es las aplicaciones no tienen limitaciones impuestas por eacuteste talescomo lenguaje de programacioacuten o herramientas y permite despliegues hiacutebridosentre recursos propios y la nube
83 Objetivos conseguidos
Implementacioacuten de los planificadores propuestos en la nube Se ha en-tendido y detallado el funcionamiento de estas herramientas y se hanimplementado en el servicio de infraestructura de Microsoft Azure
Despliegue de aplicaciones y servicios distribuidos Servicios que se usanactualmente en la industria del desarrollo software asiacute como una aplica-cioacuten web con una arquitectura moderna han sido desplegados de formadistribuida en los equipos cumpliendo con la funcionalidad esperada ade-maacutes de consiguiendo una alta disponibilidad
Aproximacioacuten de arquitectura escalable Se ha hecho una aproximacioacutende infraestructura escalable de forma que sea parcialmente extrapolable aotros proveedores
24httpwwwnextplatformcom20160322decade-container-control-google
46
84 Liacuteneas de investigacioacuten
Siguiendo con la materia de este proyecto se presentan posibles liacuteneas deinvestigacioacuten
Analizar el despliegue con estas herramientas de aplicaciones de Big Datay comparar la eficiencia con respecto a soluciones especializadas
Analizar el rendimiento de los algoritmos de planificacioacuten antes pruebasde estreacutes y situaciones de alta contienda
Comparar el uso de estas herramientas con las praacutecticas actuales de laindustria o implementacioacuten en un sistema de produccioacuten real
47
Referencias
[1] LA Barroso y U Houmllzle laquoThe Datacenter as a Computer An Introduc-tion to the Design of Warehouse-Scale Machinesraquo En Morgan amp ClaypoolPublishers ()
[2] Systems Research Group ndash NetOS (University of Cambridge) The evolu-tion of cluster scheduler architectures 2016 url httpswwwclcamacukresearchsrgnetoscamsasblog2016-03-09-scheduler-architectureshtml
[3] A Das I Gupta y A Motivala SWIM Scalable Weakly-consistent Infection-style Process Group Membership Protocol Inf teacutec Dept of ComputerScience Cornell University url https www cs cornell edu ~asdasresearchdsn02-swimpdf
[4] D Dubhashi y A Das Mastering Mesos PACKT Publishing mayo de2016
[5] The Apache Software Foundation Apache Mesos documentation urlhttpsmesosapacheorg
[6] David Greenberg Building Applications on Mesos OrsquoReilly Media 2016[7] Armand Grillet Comparison of Container Schedulers Inf teacutec Technische
Universitaumlt Berlin[8] HashiCorp Consul documentation url httpswwwconsulio[9] HashiCorp Nomad documentation url httpsdcosio[10] Dan C Marinescu Cloud computing theory and practice Morgan Kauf-
mann 2013[11] Mesosphere DCOS documentation url httpswwwnomadproject
io[12] Microsoft Azure documentation url httpsazuremicrosoftcom
es-esdocumentation[13] D Ongaro y J Ousterhout In Search of an Understandable Consensus
Algorithm Inf teacutec Stanford University url httpsraftgithubioraftpdf
[14] Fei Teng laquoRessource allocation and schelduling models for cloud compu-tingraquo Tesis de mtriacutea Ecole Centrale Paris 2011
[15] A Williams y col Automation and Orchestration with Docker and Contai-ners A Comprehensive Overview of the Docker and Container Ecosystem3 The New Stack 2016
48
- Resumen
- Summary
- Iacutendice de figuras
- Introduccioacuten y objetivos
-
- Contexto
- Objetivos
- Estructura del documento
-
- Cloud Computing
- Nuevas cargas de trabajo
- Gestioacuten de recursos Planificadores
-
- Sistemas distribuidos
-
- Clasificacioacuten
-
- Herramientas
-
- DCOS
-
- Apache Mesos
- Ejemplos de uso
-
- Nomad
-
- Protocolo de consenso Raft
- Protocolo gossip SWIM
- Planificacioacuten
-
- Casos de uso y despliegue
-
- Aplicacioacuten Web
-
- DCOS
- Nomad
-
- Servicio de integracioacuten continua
-
- DevOps
- Integracioacuten Continua
- Jenkins con Nomad
- Jenkins con DCOS
-
- Escalando la infraestructura
-
- Disentildeo
- Implementacioacuten
-
- Resultados y conclusiones
-
- Comparacioacuten
- Conclusiones
- Objetivos conseguidos
- Liacuteneas de investigacioacuten
-
Figura 12 Un equipo pasa a estado candidato (RAFT)
Si un candidato recibe un aviso de un liacuteder en el mismo plazo el primeropasa a ser seguidor y se acaba la eleccioacuten de liacuteder
Por otro lado si un equipo candidato no recibe los votos en el plazo y agotasu tiempo de espera avanza al siguiente plazo y repite el proceso de votacioacutenLa tercera posibilidad puede conllevar a un estado indefinido ya que varioscandidatos pueden agotar su tiempo de espera al mismo tiempo y repartir losvotos Para solventarlo el algoritmo establece tiempos de espera aleatorios paralos candidatos
Siguiendo con el ejemplo propuesto el servidor S1 pasa a ser el liacuteder Cadacierto tiempo eacuteste debe realizar avisos a los nodos seguidores para no agotar sutiempo de espera
En este momento el cluster de servidores estaacute en ldquoconsensordquo y la informacioacutenen todos los nodos estaacute actualizada Un cambio en la informacioacuten inicia unproceso de replicacioacuten el liacuteder registra el cambio lo pasa al resto de nodos yuna vez eacutestos responden el cambio se hace efectivo
Supoacutengase que se realiza un cambio en los datos en la figura 13 en la partederecha se observa el cambio en el registro del servidor S1 que informa a losnodos seguidores En consecuencia los nodos registran el cambio y responden aS1
Figura 13 Cambio en un registro (RAFT)
Una vez el cuoacuterum (en el ejemplo tres equipos) informa al liacuteder de que
22
ha registrado el cambio el liacuteder lo hace efectivo en su sistema y notifica a losnodos que hacen lo mismo En la figura 14 el enviacuteo todaviacutea no ha llegado ala maacutequina S3 y se observa que no ha hecho efectivo el cambio (en el registroaparece punteado)
Figura 14 Aprobacioacuten del resto de equipos (RAFT)
Este protocolo funcionaraacute correctamente mientras exista un nuacutemero de nodosen funcionamiento igual o superior al cuoacuterum en el ejemplo propuesto elcuoacuterum es tres por lo que el sistema puede tolerar la caiacuteda de dos de los equipos
522 Protocolo gossip SWIM
Nomad permite la gestioacuten simultaacutenea de varios centros de datos reparti-dos en regiones geograacuteficamente separadas requiriendo de un protocolo ligeroque mantenga a los miembros actualizados sobre los participantes del conjun-to Para ello usa una ligera variante del protocolo SWIM[3] (Scalable Weakly-consistent Infection-style Process Group Membership Protocol) desarrollada porHashiCorp Estaacute clasificado como un protocolo de tipo gossip que debe su nom-bre a la semejanza con coacutemo se distribuye un rumor en una red social
SWIM se sustenta en dos caracteriacutesticas fundamentales la deteccioacuten de fallosy la distribucioacuten de la informacioacuten relativa a los miembros A continuacioacuten sedetalla el funcionamiento de ambos componentes
Deteccioacuten de fallos
Este componente tiene dos paraacutemetros el periodo de protocolo T y el nuacutemerode subgrupos de deteccioacuten de fallos k en los que se dividen los nodos Paracomprobar la comunicacioacuten entre dos maacutequinas usa la utilidad ping basadaen el protocolo ICMP La deteccioacuten de caiacuteda de un servidor sigue el siguientealgoritmo
Durante el periodo T cada miembro Mi de un subgrupo elige otro al azar Mjdel mismo subgrupo y le enviacutea un mensaje ping para comprobar su estado Enel caso de que se cumpla un tiempo de espera determinado por una estimacioacuten
23
del tiempo de ida y vuelta (RTT por sus siglas en ingleacutes) de la red y no hayarespuesta Mi le vuelve a enviar un mensaje ping indirectamente a traveacutes deun nuacutemero k de miembros escogidos aleatoriamente De no recibir ninguna res-puesta Mi establece que Mj ha sufrido un fallo y lo etiqueta como ldquosospechosordquoinformando al componente de distribucioacuten
Figura 15 Diagrama de tiempo del protocolo SWIMFuente httpswwwcscornelledu
Componente de distribucioacuten
Se encarga de informar de cualquier cambio en los miembros a todo el con-junto Los eventos de nodo caiacutedo y la unioacuten o disociacioacuten de un miembro setransmiten a todos los servidores para que actualicen sus lista Para distribuirla informacioacuten a todos los nodos se podriacutea usar el meacutetodo de multicast perosuele estar deshabilitado Por ello se utiliza una teacutecnica de transmisioacuten denomi-nada Piggybacking mediante la cual se adjunta a los propios mensajes PINGy ACK del algoritmo la informacioacuten a distribuir reduciendo asiacute la congestioacutenen la red
523 Planificacioacuten
Proceso encargado de distribuir las tareas entre los nodos clientes de acuerdoa su estado
El planificador de Nomad estaacute basado en las publicaciones de Google sobresus herramientas de gestioacuten de clusters Borg y Omega14 y entiende los trabajosdescritos por el usuario como un estado deseado es decir su despliegue en unamaacutequina cliente de forma correcta y los clientes como el estado actual esto eslo que se encuentra en ejecucioacuten El registro actualizacioacuten o cancelacioacuten de un
14httpresearchgooglecompubspub43438html
24
trabajo asiacute como el fallo de un nodo cliente implican un cambio de estado atramitar por el sistema lo que se define como evaluacioacuten (evaluation) Esto uacutelti-mo supone comparar el estado actual (clientes) con el estado deseado (conjuntode trabajos registrados) y enviarlos a los planificadores correspondientes que seencargaraacuten de asignar las tareas a los nodos clientes
Figura 16 Procedimiento de asignacioacuten en NomadFuente httpswwwnomadprojectio
En la figura 16 se observa el flujo de trabajo en el que las distintas evalua-ciones se encolan en el evaluation broker que se ejecuta en el servidor liacuteder ygestiona las evaluaciones pendientes asignaacutendoles prioridades
A continuacioacuten los nodos servidores ejecutan los scheduling workers queprocesan las evaluaciones llamando a los distintos planificadores que generanun plan de asignacioacuten esto es un conjunto de relaciones entre las tareas y losnodos clientes donde se ejecutaraacuten Este proceso se divide en dos fases primerose descartan aquellos clientes que no cumplan los requisitos y posteriormentese asigna una calificacioacuten al resto Se selecciona el nodo con mayor puntuacioacuteny se encola el plan en el gestor que se ejecuta en el servidor liacuteder Existen tresplanificadores de acuerdo al tipo de trabajo
Service Incluye aquellos trabajos que estaacuten destinados a ejecutarse en un pe-riacuteodo largo de tiempo Para realizar las asignaciones el planificador evaluacuteala mayor parte de los nodos y usa una versioacuten del algoritmo Best fit in-fluenciada por el trabajo de Google en su herramienta Borg Se trata deun algoritmo de planificacioacuten que sacrifica tiempo a cambio de maximizarel rendimiento de los clientes asignando la tarea a la maacutequina que tengala mayor carga de trabajo con el objetivo de reducir equipos en funciona-
25
miento
Batch Tareas que incluyen listas de comandos en general de menor duracioacuteny que no requieren interaccioacuten con el usuario Se vale del algoritmo deSparrow desarrollado por la universidad de Berkeley15 para limitar losnodos clientes a evaluar
System Trabajos destinados a ejecutarse en todos los nodos incluso los que seunen al cluster posteriormente
Core Mantenimiento interno de Nomad
Una vez se ha realizado el proceso de planificacioacuten el nodo liacuteder lo registra enla cola de planes (plan queue) que se encarga de asignarles prioridad y manejarcondiciones de carrera es decir que no accedan a los recursos de los clientes sincontrol y evitar que eacutestos superen su capacidad
La maacutequina liacuteder del conjunto puede de este modo aceptar una asignacioacuteny ser ejecutada por los clientes o por el contrario rechazaacutersela al planificadorlo que implicariacutea realizar un plan parcial o totalmente nuevo
Finalmente el estado de las evaluaciones se actualizan y los clientes soninformados de las asignaciones ejecutaacutendose las tareas
15httppeopleeecsberkeleyedu~keopublicationssosp13-final17pdf
26
6 Casos de uso y despliegue
Con el objetivo de mostrar las posibles utilidades que este tipo de sistemaspueden tener en las infraestructuras TI actuales se han desplegado las dos he-rramientas en la nube Microsoft Azure usando su servicio cloud de instancias demaacutequinas virtuales Linux para simular un conjunto de ordenadores conectadosentre siacute por una red LAN Sobre ellas se ha implementado dos casos de usouna aplicacioacuten web con una arquitectura con cierta orientacioacuten a microserviciosy un sistema de integracioacuten continua
El coacutedigo y todos los ficheros de configuracioacuten se pueden encontrar en elrepositorio del proyecto en GitHub16
61 Aplicacioacuten Web
Se busca simular el proceso de adaptacioacuten de una solucioacuten web para su des-pliegue en un sistema distribuido con las herramientas anteriormente descritascon el objetivo de aumentar tanto su escalabilidad como disponibilidad medianteredundancia
Se ha partido de una aplicacioacuten ya existente17 un servicio de almacenamien-to y reproduccioacuten de canciones A grandes rasgos este servicio permite crearusuarios subir canciones con sus respectivas portadas tener playlists propias yescuchar las canciones a traveacutes de un navegador web
La solucioacuten estaacute dividida en 4 partes (figura 17)
Una vista web con la loacutegica
Un almacenamiento conectado en red (NAS por sus siglas en ingleacutes)
Una API REST para gestionar las peticiones al almacenamiento
Base de datos NoSQL basada en MongoDB
La nueva tendencia de los proyectos web es su implementacioacuten en contene-dores Docker ya que facilitan su portabilidad y ofrecen un procedimiento dedespliegue raacutepido sobre todo a la hora de desarrollar y realizar pruebas en en-tornos de produccioacuten simulados Por ello en este caso se va a hacer uso de los
16httpsgithubcomAntonioAlfrzCloud-Orchestrators17httpsgithubcomsonsoleslpCDPSfy
27
motores de orquestacioacuten de contenedores de ambas herramientas Marathon enDCOS y el controlador Docker en el caso de Nomad
Figura 17 Arquitectura aplicacioacuten web
A continuacioacuten vamos detallar el despliegue en ambas herramientas de es-ta solucioacuten y observar tanto queacute dificultades se encuentran como que ventajasofrecen El objetivo final es adaptar el proyecto modificaacutendolo lo menos posiblecon objeto de analizar la capacidad de estas herramientas para desplegar cual-quier aplicacioacuten sin que eso conlleve la modificacioacuten de la arquitectura de eacutestaes decir que no sea dependiente del entorno
611 DCOS
Se ha descrito DCOS como una herramienta que se despliega sobre un con-junto de ordenadores y que permite instalar gestionar el despliegue de sistemasdistribuidos
Microsoft Azure cuenta con una plantilla para desplegar en su servicio cloudun cluster de maacutequinas virtuales con DCOS ya instalado que cuenta con
Maacutequinas maestras (1 3 o 5 a seleccionar por el usuario) configuradascomo un conjunto de disponibilidad esto eso Azure da ciertas garantiacuteasde que al menos una maacutequina estaraacute en funcionamiento
Maacutequinas agentes Por motivos de seguridad se distinguen dos roles
bull Nodos privados solo accesibles desde la red interna y configuradoscomo un conjunto de escala un recurso de Azure para gestionar ydesplegar maacutequinas con configuraciones ideacutenticas para permitir unraacutepido escalado
bull Un equipo conectado accesible desde Internet a travntildees de un balan-ceador de carga puacuteblico y situado en una subred externa
28
Dos balanceadores de carga
bull La interfaz puacuteblica del cluster que se conecta con el cliente puacuteblicobull Acceso a los equipos maestros para el administrador que soacutelo permiteconexioacuten mediante SSH y credenciales
Almacenamiento para todas las maacutequinas
Configuraciones necesarias de red y seguridad
En la figura 18 se observa un diagrama de la infraestructura
Figura 18 Infraestructura en Azure
El primer obstaacuteculo es la persistencia de estado de la aplicacioacuten que seconsigue gracias a una base de datos no relacional basada en MongoDB asiacutecomo el almacenamiento de las canciones Para implementarla tenemos variasposibilidades
Montar un sistema externo de almacenamiento conectado en red en todoslos agentes donde se ejecuten las tareas de esta manera si una tarea pasade un nodo a otro por cualquier motivo puede tener acceso a los mismosficheros (opcioacuten del caso de uso original)
Implementar un sistema de ficheros distribuidos en los agentes
Usar los servicios de almacenamiento de las nubes puacuteblicas
Aprovechar el sistema de voluacutemenes persistentes de Apache Mesos Eacutestepermite reservar recursos de un agente de forma que al arrancar una tarease crea un volumen independiente del ciclo de vida de eacutesta con ello esosrecursos donde se ha almacenado la informacioacuten pueden volver a ofrecerseal mismo entorno de tal manera que otra tarea pueda acceder a ella
DCOS aprovecha este sistema de voluacutemenes persistentes y permite instalarbases de datos distribuidas como ArangoDB o Apache Cassandra sin embargoesto implicariacutea modificar todo el coacutedigo referente al modelo de la base de datos
29
Por motivos de eficiencia y latencia asiacute como de una mayor gobernabilidadde los datos la mejor opcioacuten es usar el recurso de voluacutemenes persistentes queofrece Apache Mesos ya que de esta manera se gestionariacutea la aplicacioacuten completamediante una uacutenica herramienta Sin embargo esto implica que la informacioacutense encuentra exclusivamente en el agente donde se haya ejecutado la tarea y porlo tanto se sigue requiriendo de software externo para distribuir la informacioacutenpara que se accesible para todos los agentes A la hora de realizar este proyectose encontraba en desarrollo Flocker una solucioacuten desarrollada por ClusterHQque permite compartir los voluacutemenes de Docker a traveacutes de un cluster quesi bien es compatible con el planificador de Mesos el proyecto se encontrabatodaviacutea en fases tempranas de desarrollo y los sistemas de almacenamiento quesoporta quedaban fuera del aacutembito de este trabajo
Por todo ello dado que las maacutequinas se han desplegado en la nube puacuteblicade Azure se decidioacute usar su servicio de almacenamiento de objetos para lascanciones y otra maacutequina para desplegar MongoDB y asiacute mantener el modelode datos original de la aplicacioacuten La diferencia del almacenamiento de obje-tos con respecto a nivel de fichero es que el primero no tiene jerarquiacutea paraorganizar los archivos eacutestos se guardan como objetos (con sus metadatos) enun mismo espacio soacutelo diferenciaacutendose por un identificador uacutenico esto implicaentre otras cosas que se puede acceder a un fichero dado uacutenicamente su IDindependientemente de la localizacioacuten fiacutesica de eacuteste facilitando pues la gestioacuteny el desarrollo
El coacutedigo del proyecto se ha modificado en los siguientes apartados
Las direcciones de la base de datos y los balanceadores de carga asiacute comosus puertos estaban originalmente fijos Se han configurado como variablesde entorno para facilitar el descubrimiento del servicio y hacer transpa-rente la aplicacioacuten al entorno de despliegue
La API REST se ha adaptado al almacenamiento en Azure en vez de enlocal
Estas modificaciones no suponen un cambio sustancial pero permiten separala persistencia de las tareas ejecutadas por DCOS lo que facilita en granmedida su ejecucioacuten al ser totalmente sin estado y ademaacutes implican tenerlos datos bajo un mayor control
Para la orquestacioacuten de contenedores se va a usar el entorno Marathondesarrollado tambieacuten por Mesosphere Eacuteste se puede usar a traveacutes de una interfazgraacutefica la interfaz de liacutenea de comandos (en lo que sigue CLI por sus siglas eningleacutes) de DCOS o con su API HTTP
Primero se han publicado la imaacutegenes de los contenedores que encapsulanla interfaz web y la api de la aplicacioacuten en el repositorio puacuteblico DockerHub
Los despliegues en este entorno se describen mediante ficheros JSON en losque se detalla entre otras opciones la imagen del contenedor los puertos a usar
30
los recursos que debe ocupar en un nodo o las instrucciones de monitorizacioacuten
Para el servicio de descubrimiento DCOS ofrece la posibilidad de asignardirecciones IP virtuales (VIP por sus siglas en ingleacutes) a tareas que se compartenen todos los nodos DCOS lleva integrado un balanceador de carga a nivel TCP(el componente denominado Minuteman) que balancea entre las direccionesvirtuales de las tareas y todas las instancias de eacutestas a lo largo del cluster Estoes necesario por dos motivos equilibrar la carga de los equipos con el fin deevitar un punto de uacutenico fallo mediante redundancia y evitar la contienda dedirecciones al ejecutar las tareas en puertos aleatorios
Este balanceador de carga estaacute basado en el trabajo de Michael Mitzenma-cher The Power of Two Choices in Randomized Load Balancing18 A grandesrasgos el algoritmo mantiene una media moacutevil exponencial de latencias paracada destino (backend) ademaacutes de las caiacutedas consecutivas Si un destino noresponde a una negociacioacuten en tres pasos (three way handshake) de forma con-secutiva en un periodo inferior a 5 ms se considera caiacutedo El algoritmo iterasobre los destinos disponibles en base a su histoacuterico de fallos y escoge dos deforma aleatoria de los cuales coge el de mejor meacutetrica
Las direcciones virtuales soacutelo se pueden resolver dentro del cluster porello para implementar la interfaz puacuteblica de la aplicacioacuten esto es el balancea-dor de carga de la interfaz web usaremos un paquete de DCOS denominadomarathon-lb un balanceador basado en HAProxy y adaptado por MesosphereEn este caso equilibra la carga de todas instancias de las tareas ejecutadas porel entorno Marathon por sus etiquetas y permite ademaacutes definir como puntode entrada muacuteltiples hosts virtuales definidos por sus nombres completos dedominio (FQDN por sus siglas en ingleacutes) en nuestro caso la interfaz puacuteblicadel balanceador de Azure para los agentes
Por motivos de seguridad todas las tareas se ejecutan en los agentes privadoses decir los que son exclusivamente accesibles desde la red interna Por su partemarathon-lb se ejecuta en el agente puacuteblico que cuenta con IP puacuteblica y lospuertos 80 (HTTP) y 8080 abiertos de forma que la aplicacioacuten sea accesibledesde Internet Esto es posible debido a que Apache Mesos permite reservarrecursos mediante roles asignados a nodos para un uso especiacutefico De esta formala arquitectura vista desde la aplicacioacuten quedariacutea como en la figura 19
18httpswwweecsharvardedu~michaelmpostscriptstpds2001pdf
31
Figura 19 Arquitectura de la aplicacioacuten web en DCOS
Ejecucioacuten
A la hora de desplegar la aplicacioacuten DCOS puede gestionarse medianteuna interfaz graacutefica o una interfaz de liacutenea de comandos La primera se accedea traveacutes de un navegador web en el puerto 80 (HTTP) y permite instalar losentornos disponibles observar el estado de los nodos y las tareas que se estaacutenejecutando y los ficheros de registros que eacutestas generan
La CLI permite el control desde un nodo o una maacutequina remota (suponiendoque los maestros tienen IP puacuteblica y el puerto 80 abierto) ya que DCOS tieneun sistema de autorizacioacuten que permite tener una interfaz puacuteblica con ciertasgarantiacuteas de seguridad
Por su parte cada entorno de trabajo puede ser controlado por la CLI peroademaacutes cuenta con sus propias interfaces Marathon expone una API HTTPen el puerto 8080 de la direccioacuten puacuteblica de los maestros del cluster asiacute comootra interfaz graacutefica Para desplegar un contenedor se podriacutea usar la CLI
$ dcos marathon app add lt f i l e j songt
O la API HTTP
$ cu r l minusX POST http lt ip_maestro gt8080v2apps minusd ltf i l e jsongt minusH Contentminustype app l i c a t i o n j son
32
612 Nomad
La arquitectura de Nomad es maacutes sencilla ya que solo requiere de un ficheroejecutable en todos los nodos para funcionar Si DCOS es la base de instala-cioacuten de entornos de terceros Nomad integra todas las funcionalidades baacutesicasesto es gestor de recursos planificador y ejecutor en los nodos cliente Estaherramienta cuenta con un menor tiempo de desarrollo y en el momento deescribir este documento cuenta exclusivamente con los siguientes controladoresen comparacioacuten con los entornos de DCOS
Motor Docker es decir funcioacuten de orquestacioacuten de contenedores
Ejecucioacuten de archivos binarios como comandos de Shell
Ejecucioacuten de aplicaciones Java
Virtualizacioacuten de maacutequinas mediante tecnologiacutea QEMU
Todos ellos necesitan que la tecnologiacutea subyacente esteacute instalada en las maacute-quinas clientes (Docker Java QEMU) Actualmente no permite el registro decontroladores por parte de terceros aunque estaacute planificado en un futuro ofreceruna interfaz para su desarrollo
Nomad no cuenta con el servicio de descubrimiento sin embargo puede inte-grarse con la herramienta Consul desarrollada por la misma empresa Por otrolado para el balanceo de carga usaremos un contenedor Docker con HAProxyuna herramienta de coacutedigo abierto que ofrece tanto servicios de proxy como debalanceador y cuyos ficheros de configuracioacuten completaremos con el proyectoConsul Template19
Consul
Consul sigue la misma arquitectura que Nomad es decir un nodo servidorque orquesta un conjunto de maacutequinas clientes y permite a los procesos que seejecutan en los equipos definirlos como servicios ofreciendo diversas caracteriacutes-ticas entorno a estos de los cuales vamos a usar dos
Descubrimiento de servicio Las maacutequinas clientes publican en el cataacutelogode servicios las tareas en ejecucioacuten y Consul les asigna nombres de dominioaccesibles por todos los miembros del cluster a traveacutes de la interfaz DNSincluida en esta herramientaConsul se integra con Nomad de forma que todas las tareas que se ejecu-ten en la segunda son automaacuteticamente publicados como servicios de laprimera de esta manera no hace falta conocer la direccioacuten de la maacutequinacliente donde se esteacute ejecutando el proceso ya que se puede acceder a eacutela traveacutes de su nombre de dominio de forma transparente Por ejemplo si
19[httpsgithubcomhashicorpconsul-template]
33
ejecutamos una tarea con ID web en el puerto 8080 se puede acceder aella en la direccioacuten webserviceconsul8080Para que las direcciones propias de Consul las resuelva su propio DNS y noel que esteacute asignado por defecto en la maacutequina usaremos la herramientadnsmasq20 que permite especificar la direccioacuten de un servidor DNS paraconsultas de direcciones especiacuteficas
Monitorizacioacuten Permite realizar comprobaciones del servicio y seguir su esta-do Aprovecharemos esta funcionalidad tanto para definir el propio procesode Nomad como servicio de Consul como las tareas desplegadas
HAProxy + Consul Template
HAProxy es una solucioacuten versaacutetil de coacutedigo abierto que ofrece solucionesde balanceo de carga y proxy Existen otras herramientas en el mercado comoNGINX o ldirectord sin embargo HAProxy suponiacutea una solucioacuten sencilla deconfigurar para mostrar el caso de uso
El uso de estas herramientas se debe a dos motivos para que no existacontienda con respecto a los puertos de los clientes usados por las tareas eacutestos sevan a asignar de forma dinaacutemica lo que en principio implicariacutea que la aplicacioacutendeberiacutea realizar consultas DNS de tipo SRV (que incluye puertos) a la interfazde Consul y balancear la carga entre tareas por redundancia y capacidad
Como la direccioacuten IP y puerto son variables cada vez que las tareas seactualicen o se reasignen es necesario volver a configurar HAProxy de formamanual Por ello HashiCorp ha desarrollado un programa denominado Con-sul Template que realiza peticiones sucesivas a la interfaz HTTP de Consul delas direcciones fiacutesicas de un servicio y reinicia automaacuteticamente el proceso deHAProxy Asiacute definiendo estas tareas como servicios Consul podremos tantomonitorizarlas como escalar las tareas dinaacutemicamente sin necesidad de cambiarel balanceador A partir del contenedor Docker oficial de HAProxy se ha desa-rrollado otro con la configuracioacuten baacutesica y con Consul Template para desplegarlocomo una tarea en Nomad
Despliegue
Se ha usado el mismo coacutedigo que en el apartado anterior con la persistenciaen el servicio de almacenamiento de Azure Desde la perspectiva del hardwarese implementaraacute la misma infraestructura que en el caso de DCOS (figura 18)estos es definiremos dos tipos de maacutequinas clientes un agente que se conectaraacutecon el balanceador de carga con nombre de dominio puacuteblico y donde se desple-garaacute el balanceador de carga de la vista web y agentes privados no accesiblesdesde fuera del cluster y donde se ejecutaraacuten el resto de tareas en la red inter-na La principal diferencia radica en las tareas que ejecutan HAproxy y ConsulTemplate que sustituye a las direcciones IP virtuales que ofrece DCOS
20httpwwwthekelleysorgukdnsmasqdochtml
34
Figura 20 Despliegue en Azure de Nomad+Consul
Cabe matizar que los balanceadores basados en HAProxy se implementanpor necesidad de la aplicacioacuten para el descubrimiento del servicio a diferenciade los de Azure que se implementan por motivos de seguridad y escalabilidaddel cluster en siacute
Configuracioacuten Nomad
Los ficheros de configuracioacuten de las maacutequinas maacutester y cliente son similaresy comparten la mayoriacutea de las opciones como por ejemplo el nombre del nodoo la interfaz de red donde escucha Nomad las peticiones Sus opciones son engeneral auto-explicativas sin embargo existen dos detalles que matizar
El proceso de Nomad escucha las peticiones tanto de los protocolos deconsenso como del usuario a traveacutes de una interfaz de red que se debeindicar en el fichero de configuracioacuten
En el caso de los clientes se deben indicar las direcciones de los servidoresdel cluster sin embargo se trata de un sistema dinaacutemico en el que losnodos pueden sufrir errores y cambiar de direccioacuten Por ello se ha definidoNomad como un servicio de Consul y asiacute poder definir la direccioacuten de losservidores como un nombre de dominio no por su direccioacuten fiacutesica que elservidor DNS de Consul se encargaraacute de resolver
Por defecto Nomad usa los siguientes puertos
API HTTP 4646 Peticiones HTTP y recepcioacuten de oacuterdenes mediante laliacutenea de comandos
RPC 4647 Protocolo de consenso entre los nodos del cluster
Serf 4648 Protocolo de gossip entre los servidores de los centros de datosgobernados por Nomad
35
Los dos uacuteltimos deben ser interfaces alcanzables por otros nodos sin embargo laAPI HTTP por motivos de seguridad deberiacutea ser local ya que en caso contrariocualquier persona con acceso a ella tiene el control sobre la herramienta Eacutestasolo deberiacutea estar accesible en un servidor o gestionarlo mediante una terminalSSH por ejemplo En este trabajo al ser una prueba de concepto se ha abiertoen todos los nodos
Trabajos de Nomad
Las tareas se detallan en ficheros con formato HashiCorp Configuration Lan-guage un derivado del formato JSON creado por la empresa que le da nombrecompatible con eacuteste y que permite comentarios
En estos ficheros se puede definir
La regioacuten y el centro de datos donde se ejecutaraacute (Nomad permite lagestioacuten de centros de datos geograacuteficamente distribuidos en regiones)
La poliacutetica de actualizacioacuten de la tarea
Grupo de tareas esto es que se ejecutaraacuten en el mismo nodo
El nuacutemero de grupos a ejecutarescalar asiacute como los liacutemite que debencumplir los nodos asignados
La poliacutetica de reinicio ante fallo o error
Tareas El controlador su configuracioacuten los paraacutemetros del servicio aso-ciado a registrar en Consul asiacute como los recursos que consume (puertosmemoria)
En nuestro caso usamos sobre todo el controlador Docker esto eso orques-tacioacuten de contenedores en los nodos clientes y tres de sus opciones
Imagen del contenedor Se han subido todas las imaacutegenes del proyecto a Doc-ker Hub donde por defecto se busca la imagen
Puertos Los puertos a usar por el contenedor que pueden ser estaacuteticos asigna-dos por el usuario o dinaacutemicos siendo Nomad el que se encarga de mapearun puerto libre del nodo cliente al expuesto por el contenedor
Servidores DNS Como usamos la interfaz DNS de Consul como descubri-miento de servicio se debe configurar el contenedor para que use cualquiernodo del cluster como servidor DNS
Configuracioacuten Consul
Al ser desarrolladas por la misma empresa los ficheros de configuracioacuten deConsul y Nomad comparten muchas opciones Consul tambieacuten acepta peticionesa traveacutes de una interfaz de red siendo los puertos usados por defecto
36
RPC 8300 8400 Maneja la peticiones del resto de nodos y usuarios
Serf 8301 8302 Protocolo gossip
HTTP API 8500
HTTPS API Desactivada por defecto
Interfaz DNS 8600
Se debe asignar a los protocolos internos del cluster esto es RPC y Serf unainterfaz alcanzable por los nodos y por el contrarioasignar a los dos uacuteltimos ala interfaz de loopback por motivos de seguridad
Cabe destacar que Consul tambieacuten cuenta con una interfaz graacutefica que per-mite ver el estado de los equipos y los servicios registrados y que se encuentra enel mismo puerto que la API HTTP en la direccioacuten httpIP_EQUIPO8500ui
Ejecucioacuten
Tanto Nomad como Consul requieren de la ejecucioacuten de un fichero en todoslos nodos integrantes del cluster Como prueba de concepto se ha decidido usardos servidores para ambos aunque cabe matizar que es un nuacutemero ineficienteya que la caiacuteda de uno de ellos supondriacutea la peacuterdida del cuoacuterum y por tantodel consenso del cluster
En primer lugar se arrancan los servidores que son los encargados de ejecu-tar el protocolo de consenso y gestionar el cluster y a continuacioacuten los clientesque no tienen praacutecticamente estado y dependen de los servidores
En el caso de Consul se debe indicar el directorio donde se guardan losficheros que describen los servicios asiacute como el archivo que especifica el resto delas opciones
1 Se inicia el primer servidor en uno de los equipos
$ consu l agent minuscon f i gminusd i r e t c consu l d s e r v i c e s minuscon f i gminus f i l e consu l_server j son
2 Los siguientes equipos deben unirse al anterior por lo que antildeadimos elargumento join con la direccioacuten del primer servidor Para el caso de otrosservidores
$ consu l agent minuscon f i gminusd i r e t c consu l d s e r v i c e s minuscon f i gminus f i l e consu l_server j son minus j o i n ltIP_servidor1gt
37
Una vez los servidores han alcanzado el consenso y elegido un liacuteder en losclientes
$ consu l agent minuscon f i gminusd i r e t c consu l d s e r v i c e s minuscon f i gminus f i l e c on su l_c l i en t j son minus j o i n ltIP_cualquierServ idorgt
El proceso para iniciar Nomad es igual y los comandos similares sin embargoya no es necesario indicar una direccioacuten IP fija en los equipos sino el nombre dedominio del servicio de Nomad registrado por Consul En el primer servidor
$ nomad agent minusc on f i g nomad_server j son
Y el resto de equipos (con su fichero de configuracioacuten correspondiente)$ nomad agent minusc on f i g nomad_server j son minus j o i n nomad s e r v i c e consu l
Por uacuteltimo para desplegar la aplicacioacuten web se han escrito tres ficherosque detallan las tareas de la interfaz web API y los balanceadores de cargaMediante la CLI
$ nomad run minusaddress=http lt ip_c lus te r gt4646 lt f i l e hclgt
O mediante la API HTTP de Nomad$ cu r l minusX POST minusd ltf i l e hclgthttp lt ip_c lus te r gt4646 jobltjob_namegt
Ansible
Como se puede comprobar con el aumento del nuacutemero de equipos pasa aser inviable manejar todos los nodos a traveacutes de terminal Ademaacutes como seha comentado con anterioridad Nomad requiere que en los nodos clientes es-teacuten instalados las herramientas que soporten las tareas por ejemplo el motorde Docker Por ello para facilitar tanto el arranque como la instalacioacuten de lasdependencias vamos a usar Ansible una herramienta de coacutedigo abierto desarro-llada en Python que permite gestionar configuraciones aprovisionar recursosdespliegue de aplicaciones de forma automaacutetica
A grandes rasgos esta herramienta funciona mediante ficheros en formatoYAML denominados play-books que describen un conjunto de pasos a ejecutaren una lista de equipos remotos Estos pasos son ejecutados por moacutedulos inde-pendientes a traveacutes de SSH es decir en cualquier ordenador con conexioacuten a los
38
hosts dado su contrasentildea o clave puacuteblica puede arrancar el script y realizariacutealos pasos de forma remota gestionando el cluster desde un solo equipo
Se han desarrollado guiones para lo siguiente
Descarga de los binarios de Nomad y Consul en todos los nodos copiade los ficheros de configuracioacuten baacutesicos y modificarlos de acuerdo a cadanodo (nombre del equipo direccioacuten IP)
Instalacioacuten de las dependencias
Arranque de Nomad y Consul
Ansible extiende su funcionalidad a traveacutes de moacutedulos independientes que per-miten por ejemplo instalar paquetes mediante herramientas de gestioacuten de pa-quetes (APT yum) aprovisionar automaacuteticamente maacutequinas virtuales de Ama-zon EC2
Algunas opciones de los ficheros de configuracioacuten de Nomad y Consul sondependientes del nodo particular por ejemplo la interfaz de red Para estetrabajo se ha realizado un moacutedulo para modificar los ficheros de configuracioacutende forma automaacutetica En el repositorio del proyecto se encuentra una carpetadonde se encuentran todos los ficheros necesarios para desplegar un clustertotalmente funcional solo requiere de una liacutenea de terminal con Ansible
$ ans ib l eminusplaybook minus i hos t s minusk ltssh_passgt minusu ltnode_usergt s i t e yml
39
62 Servicio de integracioacuten continua
Se ha implementado un sistema de integracioacuten continua que permite ejecu-tar tareas de compilacioacuten y pruebas de forma distribuida aumentando asiacute elrendimiento de los equipos En primer lugar se detallaraacute los motivos por los quepuede resultar beneficioso para las empresas una implementacioacuten de este tipo alo que seguiraacute los detalles del despliegue
621 DevOps
Metodologiacutea que defiende la comunicacioacuten y colaboracioacuten entre desarrolla-dores de software y los profesionales de operaciones a lo largo de todo el ciclo devida de una aplicacioacuten Estaacute muy relacionado con el desarrollo aacutegil de softwareesto es un enfoque para los proyectos que defiende el desarrollo iterativo e in-cremental donde los requisitos y soluciones evolucionan con el tiempo seguacuten lanecesidad del proyecto DevOps extiende esta filosofiacutea a todas los componentesde un servicio incluyendo sistemas y operaciones
Se trata de un concepto que cada organizacioacuten o empresa adapta a suspropias necesidades y procesos de negocio en este proyecto nos vamos a centraren la integracioacuten continua una praacutectica fundamental tanto del desarrollo aacutegilcomo de esta filosofiacutea
622 Integracioacuten Continua
Se define como una praacutectica de desarrollo software donde los miembros delequipo ponen en comuacuten su trabajo frecuentemente al menos una vez al diacutea21Cada integracioacuten se verifica con una compilacioacuten automaacutetica que incluye laejecucioacuten de pruebas para detectar errores de integracioacuten tan pronto como seaposible
Desde el punto de vista operativo esto supone automatizar la configuracioacutende equipos o el despliegue de maacutequinas virtuales donde compilar el proyecto yejecutar las pruebas y posteriormente eliminarlas Este flujo de trabajo se vebeneficiado en entornos distribuidos ya que el objetivo del desarrollador es com-probar el resultado de las pruebas raacutepidamente sin preocuparse del despliegueo los propios equipos
Para esta prueba de concepto vamos a usar Jenkins un servidor de integra-cioacuten continua escrito en Java que nos permite definir trabajos que contendraacutenla descripcioacuten tanto del entorno como su ejecucioacuten
Este sigue una estructura maestro-esclavo muy similar al de los gestores declusters usados en este proyecto el maestro contiene toda la loacutegica del servicio
21httpmartinfowlercomarticlescontinuousIntegrationhtml
40
trabajos autenticacioacuten y los esclavos son los encargados de la ejecucioacuten ensiacute Jenkins tiene varias viacuteas para aprovisionar los uacuteltimos
Mediante SSH
Interfaz graacutefica
Desarrollar un script propio
Ejecucioacuten de un fichero java
La ventaja de usar planificadores es que el despliegue de esclavos es dinaacutemicoes decir no tener una maacutequina especiacuteficamente configurada para ello DCOS yNomad se encargaraacuten de configurar estos despliegues en sus maacutequinas y poste-riormente eliminarlos Para ello se ha usado la uacuteltima opcioacuten definiendo tareasque descarguen el fichero java Con todo ello se consigue un entorno de inte-gracioacuten continua eficiente que ademaacutes permite la ejecucioacuten de otros servicios deforma independiente
Jenkins permite la creacioacuten de plugins que extienden sus funcionalidadesTanto Nomad22 como Apache Mesos cuentan con uno que permite su integra-cioacuten
Para esta prueba se va a usar el mismo proyecto que para el caso de usode orquestacioacuten de contenedores la aplicacioacuten web al que se le ha antildeadido untest para comprobar que se conecta correctamente a la base de datos medianteMocha un framework de Nodejs Por otro lado se antildeade el plugin de git ya queel coacutedigo se obtiene de GitHub el repositorio remoto de control de versiones delproyecto
El proceso general de ejecucioacuten seriacutea como sigue
1 Se ejecuta el maestro de Jenkins como tarea Docker partiendo de la imagenoficial
2 Al arrancar un trabajo se manda una tarea a los planificadores que laasignaraacuten a un nodo cliente Esta tarea consiste en la descarga del ficherode configuracioacuten Java y arrancarlo configurando el equipo como un clientede Jenkins temporalmente
3 Jenkins ejecuta el trabajo en el nuevo cliente en este caso iniciar la apli-cacioacuten web iniciar las pruebas y generar un informe
4 Se elimina el cliente
A continuacioacuten se detallan los matices de cada herramienta a la hora de imple-mentar este servicio
22Desarrollado por Ivo Verberk httpwwwivoverberknl
41
623 Jenkins con Nomad
El plugin permite la ejecucioacuten del fichero Java mediante dos controladorescontenedores Docker y Java En este proyecto nos hemos decantado por el pri-mero ya que nos ahorra instalar la maacutequina virtual de java en todos los nodoscliente Por ello se ha construido un contenedor base con Java para la ejecucioacutendel fichero de configuracioacuten y Nodejs para lanzar la aplicacioacuten web
El plugin se configura con la direccioacuten IP del cluster y el contenedor queejecuta el esclavo Jenkins Por su parte el trabajo en Jenkins se define conel repositorio en GitHub donde se aloja el coacutedigo del proyecto a probar y loscomandos a ejecutar en este caso npm update y npm test
624 Jenkins con DCOS
En el caso de DCOS su sistema de paquetes incluye Jenkins por lo queal instalarlo ya se tiene la configuracioacuten de Mesos totalmente funcional Sinembargo para ejecutar la aplicacioacuten en particular y las pruebas se requiere deNodejs en los equipos esclavos por ello debemos antildeadir un plugin de Jenkinsque permite instalar este entorno antes de ejecutar el trabajo Una vez hechoesto soacutelo queda definir la tarea igual que en el caso anterior
Cabe destacar que Mesosphere tambieacuten ha desarrollado un plugin que per-mite hacer despliegues en Marathon de tal manera que permitiriacutea con cadacommit del coacutedigo compilar la imagen del contenedor Docker y desplegarlaautomaacuteticamente aunque en este proyecto no se ha hecho pruebas de esta fun-cionalidad
42
7 Escalando la infraestructura
Uno de los factores clave que se busca a la hora de implementar sistemasdistribuidos es el poder escalar la infraestructura de forma maacutes sencilla estoes detectar que las maacutequinas estaacuten alcanzando el liacutemite de su capacidad yaumentar eacutesta ya sea mejorando sus caracteriacutesticas teacutecnicas o antildeadiendo maacutesnodos al cluster
El coacutedigo y todos los ficheros de configuracioacuten de esta seccioacuten tambieacuten sepueden encontrar en el repositorio del proyecto en GitHub23
71 Disentildeo
Microsoft Azure permite organizar los servicios cloud de forma loacutegica a traveacutesde grupos de recursos y asiacute poder crear o eliminar eacutestos en conjunto parauna aplicacioacuten determinada (por ejemplo una aplicacioacuten web suele requerir demaacutequinas virtuales bases de datos almacenamiento) Ademaacutes dispone dela opcioacuten de crear plantillas en formato JSON que permite al desarrolladordefinir los recursos y su interrelacioacuten para desplegar de forma automaacutetica unainfraestructura TI en la nube
Azure tambieacuten ofrece la posibilidad de monitorizar el estado de las maacutequinasvirtuales a traveacutes de extensiones lo que permite configurar el escalado automaacute-tico al alcanzar cierto liacutemite definido por el operador Eacutesta es a priori la formaen que deberiacutea implementarse hablando en teacuterminos de eficiencia sin embargoesta aproximacioacuten es totalmente dependiente de la plataforma es decir no sepuede extrapolar a otro proveedor o sobre recursos propios sin realizar un nue-vo disentildeo En este proyecto las tareas que son ejecutadas por estos equipos notienen estado ya que todo lo relativo a la persistencia lo hemos asignado fueradel cluster esto permite escalar la plataforma a traveacutes de otra aproximaciones
Las plantillas aceptan una serie de variables a indicar por el usuario entreotras los conjuntos de escala para definir los nodos aceptan una variable quedefine el nuacutemero de maacutequinas que los componen Por otro lado Azure ofreceuna API REST y kits de desarrollo software (SDK por sus siglas en ingleacutes) quepermiten su despliegue de forma programaacutetica Aprovechando estas facilidadesen este proyecto se va a aproximar la escalabilidad con el sucesivo desplieguede la infraestructura de forma automaacutetica se monitorizan los equipos y si sedetecta una maacutequina excesivamente cargada se aumenta el nuacutemero de equiposen la plantilla y se vuelve a desplegar
23httpsgithubcomAntonioAlfrzCloud-Orchestrators
43
En este proyecto se han disentildeado las plantillas para desplegar la arquitec-tura necesaria tanto de Nomad como de DCOS En el caso de la primera eldespliegue es maacutes descriptivo ya que incluye maacutequinas virtuales grupos de se-guridad redes En el caso de DCOS Azure cuenta con un servicio especiacuteficopara clusters gobernados por DCOS denominado Azure Container Service queincluye los componentes necesarios y la instalacioacuten ya realizada
72 Implementacioacuten
En primer lugar para monitorizar el estado de los equipos se va a usar laherramienta Nagios un sistema que permite controlar el estado del hardwarey los servicios de un equipo Se trata de una herramienta muy completa de laque se va a usar su capacidad para ejecutar comandos (plugins) en los nodospara detectar picos de carga generar alertas y ejecutar programas para estoseventos
Se ha desplegado una maacutequina virtual con esta herramienta en ambos siste-mas y se ha instalado una extensioacuten de Nagios (Nagios Remote Plugin Executor)en todos los nodos que permite ejecutar comprobaciones remotamente en con-creto para esta prueba de concepto medir el nivel de saturacioacuten de la unidadcentral de procesamiento (CPU por sus siglas del ingleacutes) Cuando sucede uncambio de estado de una maacutequina esto es cuando este paraacutemetro supera el liacutemi-te definido por el operador Nagios permite actuar en consecuencia ejecutandoprogramas por ello se ha desarrollado un script que ejecuta lo siguiente
Un programa desarrollado en Python con el SDK de Azure que modificalas plantillas y despliega los recursos
Un guioacuten de Ansible para instalar todos los componentes necesarios en lasnuevas maacutequinas y arrancar de nuevo el cluster y las aplicaciones
44
8 Resultados y conclusiones
En este uacuteltimo apartado se da una visioacuten global del proyecto asiacute como a lasconclusiones maacutes importantes a las que se ha llegado y posibles temas futurosde desarrollo
81 Comparacioacuten
Ambas herramientas ofrecen las funcionalidades para gestionar los recursoseficientemente ofreciendo a los desarrolladores una plataforma donde desplegarsus aplicaciones de forma distribuida independientemente de los equipos fiacutesicosy el hardware que las soporten
DCOS es una herramienta que en un comienzo fue privativa pero cuyos res-ponsables la empresa Mesosphere decidieron publicar una versioacuten de coacutedigoEacutesta nos permite gestionar un cluster de una forma sencilla y usable ademaacutes decomplementarlo con otras herramientas como el balanceador de carga integradoo la autenticacioacuten de usuarios ademaacutes estaacute basada en Apache Mesos un pro-yecto de relativa madurez y con el soporte de la Apache Software FoundationDe forma resumida DCOS ofrece muchas posibilidades y servicios a cambiode una arquitectura e instalacioacuten maacutes compleja
Por su parte HashiCorp con menor tiempo de desarrollo ha conseguidouna herramienta muy sencilla de desplegar que ademaacutes cumple con todas lasfuncionalidades baacutesicas ejecutando un simple binario en cada nodo se puededesplegar un gestor de clusters totalmente funcional Sin embargo no cuentacon todas las posibilidades de Mesos (Nomad cuenta con menos controladoresque entornos posibles de Mesos) ni con los antildeadidos de DCOS lo que implicael uso de otras herramientas para complementar el servicio (Consul HAProxy)
De entre las dificultades encontradas al usar estas herramientas y desplegaraplicaciones sobre ellas se puede destacar la depuracioacuten en ocasiones se desco-noce si un error viene de la propia herramienta de la aplicacioacuten desplegada o delequipo fiacutesico si no se cuenta con un sistema de procesamiento de registro unose puede encontrar con muacuteltiples terminales abiertas inspeccionando numerososficheros de registro buscando posibles errores Ademaacutes no dejan de ser solucio-nes que para usar eficientemente se debe conocer parte de su funcionamientoy sintaxis a la hora de describir la tareas lo que supone un esfuerzo antildeadido yaque cada una tiene sus particularidades y liacutemites
45
82 Conclusiones
En una sociedad cada vez maacutes digital las empresas deben adaptarse a unmercado cuya demanda de contenido no deja de crecer Las nuevas arquitecturascomo microservicios asiacute como la gran cantidad de datos generada implica queuna mejor gestioacuten de los recursos y la rapidez para desplegar o escalar solucionesdando valor al cliente lo maacutes raacutepido posible es uno de los objetivos de todas lasempresas de base tecnoloacutegica
Las ventajas que ofrecen los planificadores con aplicaciones distribuidas sonnumerosas sin ir maacutes lejos empresas tan punteras como Google llevan maacutesde 10 antildeos orquestando contenedores24 Por un lado permiten aumentar elrendimiento de los equipos propios y por otro implementar un servicio comoplataforma para despliegues distribuidos sobre cualquier conjunto hardware deesta forma se provee un servicio similar al de la nube puacuteblica pero con laprincipal diferencia de que se elimina la independencia con el proveedor (vendorlock-in) esto es las aplicaciones no tienen limitaciones impuestas por eacuteste talescomo lenguaje de programacioacuten o herramientas y permite despliegues hiacutebridosentre recursos propios y la nube
83 Objetivos conseguidos
Implementacioacuten de los planificadores propuestos en la nube Se ha en-tendido y detallado el funcionamiento de estas herramientas y se hanimplementado en el servicio de infraestructura de Microsoft Azure
Despliegue de aplicaciones y servicios distribuidos Servicios que se usanactualmente en la industria del desarrollo software asiacute como una aplica-cioacuten web con una arquitectura moderna han sido desplegados de formadistribuida en los equipos cumpliendo con la funcionalidad esperada ade-maacutes de consiguiendo una alta disponibilidad
Aproximacioacuten de arquitectura escalable Se ha hecho una aproximacioacutende infraestructura escalable de forma que sea parcialmente extrapolable aotros proveedores
24httpwwwnextplatformcom20160322decade-container-control-google
46
84 Liacuteneas de investigacioacuten
Siguiendo con la materia de este proyecto se presentan posibles liacuteneas deinvestigacioacuten
Analizar el despliegue con estas herramientas de aplicaciones de Big Datay comparar la eficiencia con respecto a soluciones especializadas
Analizar el rendimiento de los algoritmos de planificacioacuten antes pruebasde estreacutes y situaciones de alta contienda
Comparar el uso de estas herramientas con las praacutecticas actuales de laindustria o implementacioacuten en un sistema de produccioacuten real
47
Referencias
[1] LA Barroso y U Houmllzle laquoThe Datacenter as a Computer An Introduc-tion to the Design of Warehouse-Scale Machinesraquo En Morgan amp ClaypoolPublishers ()
[2] Systems Research Group ndash NetOS (University of Cambridge) The evolu-tion of cluster scheduler architectures 2016 url httpswwwclcamacukresearchsrgnetoscamsasblog2016-03-09-scheduler-architectureshtml
[3] A Das I Gupta y A Motivala SWIM Scalable Weakly-consistent Infection-style Process Group Membership Protocol Inf teacutec Dept of ComputerScience Cornell University url https www cs cornell edu ~asdasresearchdsn02-swimpdf
[4] D Dubhashi y A Das Mastering Mesos PACKT Publishing mayo de2016
[5] The Apache Software Foundation Apache Mesos documentation urlhttpsmesosapacheorg
[6] David Greenberg Building Applications on Mesos OrsquoReilly Media 2016[7] Armand Grillet Comparison of Container Schedulers Inf teacutec Technische
Universitaumlt Berlin[8] HashiCorp Consul documentation url httpswwwconsulio[9] HashiCorp Nomad documentation url httpsdcosio[10] Dan C Marinescu Cloud computing theory and practice Morgan Kauf-
mann 2013[11] Mesosphere DCOS documentation url httpswwwnomadproject
io[12] Microsoft Azure documentation url httpsazuremicrosoftcom
es-esdocumentation[13] D Ongaro y J Ousterhout In Search of an Understandable Consensus
Algorithm Inf teacutec Stanford University url httpsraftgithubioraftpdf
[14] Fei Teng laquoRessource allocation and schelduling models for cloud compu-tingraquo Tesis de mtriacutea Ecole Centrale Paris 2011
[15] A Williams y col Automation and Orchestration with Docker and Contai-ners A Comprehensive Overview of the Docker and Container Ecosystem3 The New Stack 2016
48
- Resumen
- Summary
- Iacutendice de figuras
- Introduccioacuten y objetivos
-
- Contexto
- Objetivos
- Estructura del documento
-
- Cloud Computing
- Nuevas cargas de trabajo
- Gestioacuten de recursos Planificadores
-
- Sistemas distribuidos
-
- Clasificacioacuten
-
- Herramientas
-
- DCOS
-
- Apache Mesos
- Ejemplos de uso
-
- Nomad
-
- Protocolo de consenso Raft
- Protocolo gossip SWIM
- Planificacioacuten
-
- Casos de uso y despliegue
-
- Aplicacioacuten Web
-
- DCOS
- Nomad
-
- Servicio de integracioacuten continua
-
- DevOps
- Integracioacuten Continua
- Jenkins con Nomad
- Jenkins con DCOS
-
- Escalando la infraestructura
-
- Disentildeo
- Implementacioacuten
-
- Resultados y conclusiones
-
- Comparacioacuten
- Conclusiones
- Objetivos conseguidos
- Liacuteneas de investigacioacuten
-
ha registrado el cambio el liacuteder lo hace efectivo en su sistema y notifica a losnodos que hacen lo mismo En la figura 14 el enviacuteo todaviacutea no ha llegado ala maacutequina S3 y se observa que no ha hecho efectivo el cambio (en el registroaparece punteado)
Figura 14 Aprobacioacuten del resto de equipos (RAFT)
Este protocolo funcionaraacute correctamente mientras exista un nuacutemero de nodosen funcionamiento igual o superior al cuoacuterum en el ejemplo propuesto elcuoacuterum es tres por lo que el sistema puede tolerar la caiacuteda de dos de los equipos
522 Protocolo gossip SWIM
Nomad permite la gestioacuten simultaacutenea de varios centros de datos reparti-dos en regiones geograacuteficamente separadas requiriendo de un protocolo ligeroque mantenga a los miembros actualizados sobre los participantes del conjun-to Para ello usa una ligera variante del protocolo SWIM[3] (Scalable Weakly-consistent Infection-style Process Group Membership Protocol) desarrollada porHashiCorp Estaacute clasificado como un protocolo de tipo gossip que debe su nom-bre a la semejanza con coacutemo se distribuye un rumor en una red social
SWIM se sustenta en dos caracteriacutesticas fundamentales la deteccioacuten de fallosy la distribucioacuten de la informacioacuten relativa a los miembros A continuacioacuten sedetalla el funcionamiento de ambos componentes
Deteccioacuten de fallos
Este componente tiene dos paraacutemetros el periodo de protocolo T y el nuacutemerode subgrupos de deteccioacuten de fallos k en los que se dividen los nodos Paracomprobar la comunicacioacuten entre dos maacutequinas usa la utilidad ping basadaen el protocolo ICMP La deteccioacuten de caiacuteda de un servidor sigue el siguientealgoritmo
Durante el periodo T cada miembro Mi de un subgrupo elige otro al azar Mjdel mismo subgrupo y le enviacutea un mensaje ping para comprobar su estado Enel caso de que se cumpla un tiempo de espera determinado por una estimacioacuten
23
del tiempo de ida y vuelta (RTT por sus siglas en ingleacutes) de la red y no hayarespuesta Mi le vuelve a enviar un mensaje ping indirectamente a traveacutes deun nuacutemero k de miembros escogidos aleatoriamente De no recibir ninguna res-puesta Mi establece que Mj ha sufrido un fallo y lo etiqueta como ldquosospechosordquoinformando al componente de distribucioacuten
Figura 15 Diagrama de tiempo del protocolo SWIMFuente httpswwwcscornelledu
Componente de distribucioacuten
Se encarga de informar de cualquier cambio en los miembros a todo el con-junto Los eventos de nodo caiacutedo y la unioacuten o disociacioacuten de un miembro setransmiten a todos los servidores para que actualicen sus lista Para distribuirla informacioacuten a todos los nodos se podriacutea usar el meacutetodo de multicast perosuele estar deshabilitado Por ello se utiliza una teacutecnica de transmisioacuten denomi-nada Piggybacking mediante la cual se adjunta a los propios mensajes PINGy ACK del algoritmo la informacioacuten a distribuir reduciendo asiacute la congestioacutenen la red
523 Planificacioacuten
Proceso encargado de distribuir las tareas entre los nodos clientes de acuerdoa su estado
El planificador de Nomad estaacute basado en las publicaciones de Google sobresus herramientas de gestioacuten de clusters Borg y Omega14 y entiende los trabajosdescritos por el usuario como un estado deseado es decir su despliegue en unamaacutequina cliente de forma correcta y los clientes como el estado actual esto eslo que se encuentra en ejecucioacuten El registro actualizacioacuten o cancelacioacuten de un
14httpresearchgooglecompubspub43438html
24
trabajo asiacute como el fallo de un nodo cliente implican un cambio de estado atramitar por el sistema lo que se define como evaluacioacuten (evaluation) Esto uacutelti-mo supone comparar el estado actual (clientes) con el estado deseado (conjuntode trabajos registrados) y enviarlos a los planificadores correspondientes que seencargaraacuten de asignar las tareas a los nodos clientes
Figura 16 Procedimiento de asignacioacuten en NomadFuente httpswwwnomadprojectio
En la figura 16 se observa el flujo de trabajo en el que las distintas evalua-ciones se encolan en el evaluation broker que se ejecuta en el servidor liacuteder ygestiona las evaluaciones pendientes asignaacutendoles prioridades
A continuacioacuten los nodos servidores ejecutan los scheduling workers queprocesan las evaluaciones llamando a los distintos planificadores que generanun plan de asignacioacuten esto es un conjunto de relaciones entre las tareas y losnodos clientes donde se ejecutaraacuten Este proceso se divide en dos fases primerose descartan aquellos clientes que no cumplan los requisitos y posteriormentese asigna una calificacioacuten al resto Se selecciona el nodo con mayor puntuacioacuteny se encola el plan en el gestor que se ejecuta en el servidor liacuteder Existen tresplanificadores de acuerdo al tipo de trabajo
Service Incluye aquellos trabajos que estaacuten destinados a ejecutarse en un pe-riacuteodo largo de tiempo Para realizar las asignaciones el planificador evaluacuteala mayor parte de los nodos y usa una versioacuten del algoritmo Best fit in-fluenciada por el trabajo de Google en su herramienta Borg Se trata deun algoritmo de planificacioacuten que sacrifica tiempo a cambio de maximizarel rendimiento de los clientes asignando la tarea a la maacutequina que tengala mayor carga de trabajo con el objetivo de reducir equipos en funciona-
25
miento
Batch Tareas que incluyen listas de comandos en general de menor duracioacuteny que no requieren interaccioacuten con el usuario Se vale del algoritmo deSparrow desarrollado por la universidad de Berkeley15 para limitar losnodos clientes a evaluar
System Trabajos destinados a ejecutarse en todos los nodos incluso los que seunen al cluster posteriormente
Core Mantenimiento interno de Nomad
Una vez se ha realizado el proceso de planificacioacuten el nodo liacuteder lo registra enla cola de planes (plan queue) que se encarga de asignarles prioridad y manejarcondiciones de carrera es decir que no accedan a los recursos de los clientes sincontrol y evitar que eacutestos superen su capacidad
La maacutequina liacuteder del conjunto puede de este modo aceptar una asignacioacuteny ser ejecutada por los clientes o por el contrario rechazaacutersela al planificadorlo que implicariacutea realizar un plan parcial o totalmente nuevo
Finalmente el estado de las evaluaciones se actualizan y los clientes soninformados de las asignaciones ejecutaacutendose las tareas
15httppeopleeecsberkeleyedu~keopublicationssosp13-final17pdf
26
6 Casos de uso y despliegue
Con el objetivo de mostrar las posibles utilidades que este tipo de sistemaspueden tener en las infraestructuras TI actuales se han desplegado las dos he-rramientas en la nube Microsoft Azure usando su servicio cloud de instancias demaacutequinas virtuales Linux para simular un conjunto de ordenadores conectadosentre siacute por una red LAN Sobre ellas se ha implementado dos casos de usouna aplicacioacuten web con una arquitectura con cierta orientacioacuten a microserviciosy un sistema de integracioacuten continua
El coacutedigo y todos los ficheros de configuracioacuten se pueden encontrar en elrepositorio del proyecto en GitHub16
61 Aplicacioacuten Web
Se busca simular el proceso de adaptacioacuten de una solucioacuten web para su des-pliegue en un sistema distribuido con las herramientas anteriormente descritascon el objetivo de aumentar tanto su escalabilidad como disponibilidad medianteredundancia
Se ha partido de una aplicacioacuten ya existente17 un servicio de almacenamien-to y reproduccioacuten de canciones A grandes rasgos este servicio permite crearusuarios subir canciones con sus respectivas portadas tener playlists propias yescuchar las canciones a traveacutes de un navegador web
La solucioacuten estaacute dividida en 4 partes (figura 17)
Una vista web con la loacutegica
Un almacenamiento conectado en red (NAS por sus siglas en ingleacutes)
Una API REST para gestionar las peticiones al almacenamiento
Base de datos NoSQL basada en MongoDB
La nueva tendencia de los proyectos web es su implementacioacuten en contene-dores Docker ya que facilitan su portabilidad y ofrecen un procedimiento dedespliegue raacutepido sobre todo a la hora de desarrollar y realizar pruebas en en-tornos de produccioacuten simulados Por ello en este caso se va a hacer uso de los
16httpsgithubcomAntonioAlfrzCloud-Orchestrators17httpsgithubcomsonsoleslpCDPSfy
27
motores de orquestacioacuten de contenedores de ambas herramientas Marathon enDCOS y el controlador Docker en el caso de Nomad
Figura 17 Arquitectura aplicacioacuten web
A continuacioacuten vamos detallar el despliegue en ambas herramientas de es-ta solucioacuten y observar tanto queacute dificultades se encuentran como que ventajasofrecen El objetivo final es adaptar el proyecto modificaacutendolo lo menos posiblecon objeto de analizar la capacidad de estas herramientas para desplegar cual-quier aplicacioacuten sin que eso conlleve la modificacioacuten de la arquitectura de eacutestaes decir que no sea dependiente del entorno
611 DCOS
Se ha descrito DCOS como una herramienta que se despliega sobre un con-junto de ordenadores y que permite instalar gestionar el despliegue de sistemasdistribuidos
Microsoft Azure cuenta con una plantilla para desplegar en su servicio cloudun cluster de maacutequinas virtuales con DCOS ya instalado que cuenta con
Maacutequinas maestras (1 3 o 5 a seleccionar por el usuario) configuradascomo un conjunto de disponibilidad esto eso Azure da ciertas garantiacuteasde que al menos una maacutequina estaraacute en funcionamiento
Maacutequinas agentes Por motivos de seguridad se distinguen dos roles
bull Nodos privados solo accesibles desde la red interna y configuradoscomo un conjunto de escala un recurso de Azure para gestionar ydesplegar maacutequinas con configuraciones ideacutenticas para permitir unraacutepido escalado
bull Un equipo conectado accesible desde Internet a travntildees de un balan-ceador de carga puacuteblico y situado en una subred externa
28
Dos balanceadores de carga
bull La interfaz puacuteblica del cluster que se conecta con el cliente puacuteblicobull Acceso a los equipos maestros para el administrador que soacutelo permiteconexioacuten mediante SSH y credenciales
Almacenamiento para todas las maacutequinas
Configuraciones necesarias de red y seguridad
En la figura 18 se observa un diagrama de la infraestructura
Figura 18 Infraestructura en Azure
El primer obstaacuteculo es la persistencia de estado de la aplicacioacuten que seconsigue gracias a una base de datos no relacional basada en MongoDB asiacutecomo el almacenamiento de las canciones Para implementarla tenemos variasposibilidades
Montar un sistema externo de almacenamiento conectado en red en todoslos agentes donde se ejecuten las tareas de esta manera si una tarea pasade un nodo a otro por cualquier motivo puede tener acceso a los mismosficheros (opcioacuten del caso de uso original)
Implementar un sistema de ficheros distribuidos en los agentes
Usar los servicios de almacenamiento de las nubes puacuteblicas
Aprovechar el sistema de voluacutemenes persistentes de Apache Mesos Eacutestepermite reservar recursos de un agente de forma que al arrancar una tarease crea un volumen independiente del ciclo de vida de eacutesta con ello esosrecursos donde se ha almacenado la informacioacuten pueden volver a ofrecerseal mismo entorno de tal manera que otra tarea pueda acceder a ella
DCOS aprovecha este sistema de voluacutemenes persistentes y permite instalarbases de datos distribuidas como ArangoDB o Apache Cassandra sin embargoesto implicariacutea modificar todo el coacutedigo referente al modelo de la base de datos
29
Por motivos de eficiencia y latencia asiacute como de una mayor gobernabilidadde los datos la mejor opcioacuten es usar el recurso de voluacutemenes persistentes queofrece Apache Mesos ya que de esta manera se gestionariacutea la aplicacioacuten completamediante una uacutenica herramienta Sin embargo esto implica que la informacioacutense encuentra exclusivamente en el agente donde se haya ejecutado la tarea y porlo tanto se sigue requiriendo de software externo para distribuir la informacioacutenpara que se accesible para todos los agentes A la hora de realizar este proyectose encontraba en desarrollo Flocker una solucioacuten desarrollada por ClusterHQque permite compartir los voluacutemenes de Docker a traveacutes de un cluster quesi bien es compatible con el planificador de Mesos el proyecto se encontrabatodaviacutea en fases tempranas de desarrollo y los sistemas de almacenamiento quesoporta quedaban fuera del aacutembito de este trabajo
Por todo ello dado que las maacutequinas se han desplegado en la nube puacuteblicade Azure se decidioacute usar su servicio de almacenamiento de objetos para lascanciones y otra maacutequina para desplegar MongoDB y asiacute mantener el modelode datos original de la aplicacioacuten La diferencia del almacenamiento de obje-tos con respecto a nivel de fichero es que el primero no tiene jerarquiacutea paraorganizar los archivos eacutestos se guardan como objetos (con sus metadatos) enun mismo espacio soacutelo diferenciaacutendose por un identificador uacutenico esto implicaentre otras cosas que se puede acceder a un fichero dado uacutenicamente su IDindependientemente de la localizacioacuten fiacutesica de eacuteste facilitando pues la gestioacuteny el desarrollo
El coacutedigo del proyecto se ha modificado en los siguientes apartados
Las direcciones de la base de datos y los balanceadores de carga asiacute comosus puertos estaban originalmente fijos Se han configurado como variablesde entorno para facilitar el descubrimiento del servicio y hacer transpa-rente la aplicacioacuten al entorno de despliegue
La API REST se ha adaptado al almacenamiento en Azure en vez de enlocal
Estas modificaciones no suponen un cambio sustancial pero permiten separala persistencia de las tareas ejecutadas por DCOS lo que facilita en granmedida su ejecucioacuten al ser totalmente sin estado y ademaacutes implican tenerlos datos bajo un mayor control
Para la orquestacioacuten de contenedores se va a usar el entorno Marathondesarrollado tambieacuten por Mesosphere Eacuteste se puede usar a traveacutes de una interfazgraacutefica la interfaz de liacutenea de comandos (en lo que sigue CLI por sus siglas eningleacutes) de DCOS o con su API HTTP
Primero se han publicado la imaacutegenes de los contenedores que encapsulanla interfaz web y la api de la aplicacioacuten en el repositorio puacuteblico DockerHub
Los despliegues en este entorno se describen mediante ficheros JSON en losque se detalla entre otras opciones la imagen del contenedor los puertos a usar
30
los recursos que debe ocupar en un nodo o las instrucciones de monitorizacioacuten
Para el servicio de descubrimiento DCOS ofrece la posibilidad de asignardirecciones IP virtuales (VIP por sus siglas en ingleacutes) a tareas que se compartenen todos los nodos DCOS lleva integrado un balanceador de carga a nivel TCP(el componente denominado Minuteman) que balancea entre las direccionesvirtuales de las tareas y todas las instancias de eacutestas a lo largo del cluster Estoes necesario por dos motivos equilibrar la carga de los equipos con el fin deevitar un punto de uacutenico fallo mediante redundancia y evitar la contienda dedirecciones al ejecutar las tareas en puertos aleatorios
Este balanceador de carga estaacute basado en el trabajo de Michael Mitzenma-cher The Power of Two Choices in Randomized Load Balancing18 A grandesrasgos el algoritmo mantiene una media moacutevil exponencial de latencias paracada destino (backend) ademaacutes de las caiacutedas consecutivas Si un destino noresponde a una negociacioacuten en tres pasos (three way handshake) de forma con-secutiva en un periodo inferior a 5 ms se considera caiacutedo El algoritmo iterasobre los destinos disponibles en base a su histoacuterico de fallos y escoge dos deforma aleatoria de los cuales coge el de mejor meacutetrica
Las direcciones virtuales soacutelo se pueden resolver dentro del cluster porello para implementar la interfaz puacuteblica de la aplicacioacuten esto es el balancea-dor de carga de la interfaz web usaremos un paquete de DCOS denominadomarathon-lb un balanceador basado en HAProxy y adaptado por MesosphereEn este caso equilibra la carga de todas instancias de las tareas ejecutadas porel entorno Marathon por sus etiquetas y permite ademaacutes definir como puntode entrada muacuteltiples hosts virtuales definidos por sus nombres completos dedominio (FQDN por sus siglas en ingleacutes) en nuestro caso la interfaz puacuteblicadel balanceador de Azure para los agentes
Por motivos de seguridad todas las tareas se ejecutan en los agentes privadoses decir los que son exclusivamente accesibles desde la red interna Por su partemarathon-lb se ejecuta en el agente puacuteblico que cuenta con IP puacuteblica y lospuertos 80 (HTTP) y 8080 abiertos de forma que la aplicacioacuten sea accesibledesde Internet Esto es posible debido a que Apache Mesos permite reservarrecursos mediante roles asignados a nodos para un uso especiacutefico De esta formala arquitectura vista desde la aplicacioacuten quedariacutea como en la figura 19
18httpswwweecsharvardedu~michaelmpostscriptstpds2001pdf
31
Figura 19 Arquitectura de la aplicacioacuten web en DCOS
Ejecucioacuten
A la hora de desplegar la aplicacioacuten DCOS puede gestionarse medianteuna interfaz graacutefica o una interfaz de liacutenea de comandos La primera se accedea traveacutes de un navegador web en el puerto 80 (HTTP) y permite instalar losentornos disponibles observar el estado de los nodos y las tareas que se estaacutenejecutando y los ficheros de registros que eacutestas generan
La CLI permite el control desde un nodo o una maacutequina remota (suponiendoque los maestros tienen IP puacuteblica y el puerto 80 abierto) ya que DCOS tieneun sistema de autorizacioacuten que permite tener una interfaz puacuteblica con ciertasgarantiacuteas de seguridad
Por su parte cada entorno de trabajo puede ser controlado por la CLI peroademaacutes cuenta con sus propias interfaces Marathon expone una API HTTPen el puerto 8080 de la direccioacuten puacuteblica de los maestros del cluster asiacute comootra interfaz graacutefica Para desplegar un contenedor se podriacutea usar la CLI
$ dcos marathon app add lt f i l e j songt
O la API HTTP
$ cu r l minusX POST http lt ip_maestro gt8080v2apps minusd ltf i l e jsongt minusH Contentminustype app l i c a t i o n j son
32
612 Nomad
La arquitectura de Nomad es maacutes sencilla ya que solo requiere de un ficheroejecutable en todos los nodos para funcionar Si DCOS es la base de instala-cioacuten de entornos de terceros Nomad integra todas las funcionalidades baacutesicasesto es gestor de recursos planificador y ejecutor en los nodos cliente Estaherramienta cuenta con un menor tiempo de desarrollo y en el momento deescribir este documento cuenta exclusivamente con los siguientes controladoresen comparacioacuten con los entornos de DCOS
Motor Docker es decir funcioacuten de orquestacioacuten de contenedores
Ejecucioacuten de archivos binarios como comandos de Shell
Ejecucioacuten de aplicaciones Java
Virtualizacioacuten de maacutequinas mediante tecnologiacutea QEMU
Todos ellos necesitan que la tecnologiacutea subyacente esteacute instalada en las maacute-quinas clientes (Docker Java QEMU) Actualmente no permite el registro decontroladores por parte de terceros aunque estaacute planificado en un futuro ofreceruna interfaz para su desarrollo
Nomad no cuenta con el servicio de descubrimiento sin embargo puede inte-grarse con la herramienta Consul desarrollada por la misma empresa Por otrolado para el balanceo de carga usaremos un contenedor Docker con HAProxyuna herramienta de coacutedigo abierto que ofrece tanto servicios de proxy como debalanceador y cuyos ficheros de configuracioacuten completaremos con el proyectoConsul Template19
Consul
Consul sigue la misma arquitectura que Nomad es decir un nodo servidorque orquesta un conjunto de maacutequinas clientes y permite a los procesos que seejecutan en los equipos definirlos como servicios ofreciendo diversas caracteriacutes-ticas entorno a estos de los cuales vamos a usar dos
Descubrimiento de servicio Las maacutequinas clientes publican en el cataacutelogode servicios las tareas en ejecucioacuten y Consul les asigna nombres de dominioaccesibles por todos los miembros del cluster a traveacutes de la interfaz DNSincluida en esta herramientaConsul se integra con Nomad de forma que todas las tareas que se ejecu-ten en la segunda son automaacuteticamente publicados como servicios de laprimera de esta manera no hace falta conocer la direccioacuten de la maacutequinacliente donde se esteacute ejecutando el proceso ya que se puede acceder a eacutela traveacutes de su nombre de dominio de forma transparente Por ejemplo si
19[httpsgithubcomhashicorpconsul-template]
33
ejecutamos una tarea con ID web en el puerto 8080 se puede acceder aella en la direccioacuten webserviceconsul8080Para que las direcciones propias de Consul las resuelva su propio DNS y noel que esteacute asignado por defecto en la maacutequina usaremos la herramientadnsmasq20 que permite especificar la direccioacuten de un servidor DNS paraconsultas de direcciones especiacuteficas
Monitorizacioacuten Permite realizar comprobaciones del servicio y seguir su esta-do Aprovecharemos esta funcionalidad tanto para definir el propio procesode Nomad como servicio de Consul como las tareas desplegadas
HAProxy + Consul Template
HAProxy es una solucioacuten versaacutetil de coacutedigo abierto que ofrece solucionesde balanceo de carga y proxy Existen otras herramientas en el mercado comoNGINX o ldirectord sin embargo HAProxy suponiacutea una solucioacuten sencilla deconfigurar para mostrar el caso de uso
El uso de estas herramientas se debe a dos motivos para que no existacontienda con respecto a los puertos de los clientes usados por las tareas eacutestos sevan a asignar de forma dinaacutemica lo que en principio implicariacutea que la aplicacioacutendeberiacutea realizar consultas DNS de tipo SRV (que incluye puertos) a la interfazde Consul y balancear la carga entre tareas por redundancia y capacidad
Como la direccioacuten IP y puerto son variables cada vez que las tareas seactualicen o se reasignen es necesario volver a configurar HAProxy de formamanual Por ello HashiCorp ha desarrollado un programa denominado Con-sul Template que realiza peticiones sucesivas a la interfaz HTTP de Consul delas direcciones fiacutesicas de un servicio y reinicia automaacuteticamente el proceso deHAProxy Asiacute definiendo estas tareas como servicios Consul podremos tantomonitorizarlas como escalar las tareas dinaacutemicamente sin necesidad de cambiarel balanceador A partir del contenedor Docker oficial de HAProxy se ha desa-rrollado otro con la configuracioacuten baacutesica y con Consul Template para desplegarlocomo una tarea en Nomad
Despliegue
Se ha usado el mismo coacutedigo que en el apartado anterior con la persistenciaen el servicio de almacenamiento de Azure Desde la perspectiva del hardwarese implementaraacute la misma infraestructura que en el caso de DCOS (figura 18)estos es definiremos dos tipos de maacutequinas clientes un agente que se conectaraacutecon el balanceador de carga con nombre de dominio puacuteblico y donde se desple-garaacute el balanceador de carga de la vista web y agentes privados no accesiblesdesde fuera del cluster y donde se ejecutaraacuten el resto de tareas en la red inter-na La principal diferencia radica en las tareas que ejecutan HAproxy y ConsulTemplate que sustituye a las direcciones IP virtuales que ofrece DCOS
20httpwwwthekelleysorgukdnsmasqdochtml
34
Figura 20 Despliegue en Azure de Nomad+Consul
Cabe matizar que los balanceadores basados en HAProxy se implementanpor necesidad de la aplicacioacuten para el descubrimiento del servicio a diferenciade los de Azure que se implementan por motivos de seguridad y escalabilidaddel cluster en siacute
Configuracioacuten Nomad
Los ficheros de configuracioacuten de las maacutequinas maacutester y cliente son similaresy comparten la mayoriacutea de las opciones como por ejemplo el nombre del nodoo la interfaz de red donde escucha Nomad las peticiones Sus opciones son engeneral auto-explicativas sin embargo existen dos detalles que matizar
El proceso de Nomad escucha las peticiones tanto de los protocolos deconsenso como del usuario a traveacutes de una interfaz de red que se debeindicar en el fichero de configuracioacuten
En el caso de los clientes se deben indicar las direcciones de los servidoresdel cluster sin embargo se trata de un sistema dinaacutemico en el que losnodos pueden sufrir errores y cambiar de direccioacuten Por ello se ha definidoNomad como un servicio de Consul y asiacute poder definir la direccioacuten de losservidores como un nombre de dominio no por su direccioacuten fiacutesica que elservidor DNS de Consul se encargaraacute de resolver
Por defecto Nomad usa los siguientes puertos
API HTTP 4646 Peticiones HTTP y recepcioacuten de oacuterdenes mediante laliacutenea de comandos
RPC 4647 Protocolo de consenso entre los nodos del cluster
Serf 4648 Protocolo de gossip entre los servidores de los centros de datosgobernados por Nomad
35
Los dos uacuteltimos deben ser interfaces alcanzables por otros nodos sin embargo laAPI HTTP por motivos de seguridad deberiacutea ser local ya que en caso contrariocualquier persona con acceso a ella tiene el control sobre la herramienta Eacutestasolo deberiacutea estar accesible en un servidor o gestionarlo mediante una terminalSSH por ejemplo En este trabajo al ser una prueba de concepto se ha abiertoen todos los nodos
Trabajos de Nomad
Las tareas se detallan en ficheros con formato HashiCorp Configuration Lan-guage un derivado del formato JSON creado por la empresa que le da nombrecompatible con eacuteste y que permite comentarios
En estos ficheros se puede definir
La regioacuten y el centro de datos donde se ejecutaraacute (Nomad permite lagestioacuten de centros de datos geograacuteficamente distribuidos en regiones)
La poliacutetica de actualizacioacuten de la tarea
Grupo de tareas esto es que se ejecutaraacuten en el mismo nodo
El nuacutemero de grupos a ejecutarescalar asiacute como los liacutemite que debencumplir los nodos asignados
La poliacutetica de reinicio ante fallo o error
Tareas El controlador su configuracioacuten los paraacutemetros del servicio aso-ciado a registrar en Consul asiacute como los recursos que consume (puertosmemoria)
En nuestro caso usamos sobre todo el controlador Docker esto eso orques-tacioacuten de contenedores en los nodos clientes y tres de sus opciones
Imagen del contenedor Se han subido todas las imaacutegenes del proyecto a Doc-ker Hub donde por defecto se busca la imagen
Puertos Los puertos a usar por el contenedor que pueden ser estaacuteticos asigna-dos por el usuario o dinaacutemicos siendo Nomad el que se encarga de mapearun puerto libre del nodo cliente al expuesto por el contenedor
Servidores DNS Como usamos la interfaz DNS de Consul como descubri-miento de servicio se debe configurar el contenedor para que use cualquiernodo del cluster como servidor DNS
Configuracioacuten Consul
Al ser desarrolladas por la misma empresa los ficheros de configuracioacuten deConsul y Nomad comparten muchas opciones Consul tambieacuten acepta peticionesa traveacutes de una interfaz de red siendo los puertos usados por defecto
36
RPC 8300 8400 Maneja la peticiones del resto de nodos y usuarios
Serf 8301 8302 Protocolo gossip
HTTP API 8500
HTTPS API Desactivada por defecto
Interfaz DNS 8600
Se debe asignar a los protocolos internos del cluster esto es RPC y Serf unainterfaz alcanzable por los nodos y por el contrarioasignar a los dos uacuteltimos ala interfaz de loopback por motivos de seguridad
Cabe destacar que Consul tambieacuten cuenta con una interfaz graacutefica que per-mite ver el estado de los equipos y los servicios registrados y que se encuentra enel mismo puerto que la API HTTP en la direccioacuten httpIP_EQUIPO8500ui
Ejecucioacuten
Tanto Nomad como Consul requieren de la ejecucioacuten de un fichero en todoslos nodos integrantes del cluster Como prueba de concepto se ha decidido usardos servidores para ambos aunque cabe matizar que es un nuacutemero ineficienteya que la caiacuteda de uno de ellos supondriacutea la peacuterdida del cuoacuterum y por tantodel consenso del cluster
En primer lugar se arrancan los servidores que son los encargados de ejecu-tar el protocolo de consenso y gestionar el cluster y a continuacioacuten los clientesque no tienen praacutecticamente estado y dependen de los servidores
En el caso de Consul se debe indicar el directorio donde se guardan losficheros que describen los servicios asiacute como el archivo que especifica el resto delas opciones
1 Se inicia el primer servidor en uno de los equipos
$ consu l agent minuscon f i gminusd i r e t c consu l d s e r v i c e s minuscon f i gminus f i l e consu l_server j son
2 Los siguientes equipos deben unirse al anterior por lo que antildeadimos elargumento join con la direccioacuten del primer servidor Para el caso de otrosservidores
$ consu l agent minuscon f i gminusd i r e t c consu l d s e r v i c e s minuscon f i gminus f i l e consu l_server j son minus j o i n ltIP_servidor1gt
37
Una vez los servidores han alcanzado el consenso y elegido un liacuteder en losclientes
$ consu l agent minuscon f i gminusd i r e t c consu l d s e r v i c e s minuscon f i gminus f i l e c on su l_c l i en t j son minus j o i n ltIP_cualquierServ idorgt
El proceso para iniciar Nomad es igual y los comandos similares sin embargoya no es necesario indicar una direccioacuten IP fija en los equipos sino el nombre dedominio del servicio de Nomad registrado por Consul En el primer servidor
$ nomad agent minusc on f i g nomad_server j son
Y el resto de equipos (con su fichero de configuracioacuten correspondiente)$ nomad agent minusc on f i g nomad_server j son minus j o i n nomad s e r v i c e consu l
Por uacuteltimo para desplegar la aplicacioacuten web se han escrito tres ficherosque detallan las tareas de la interfaz web API y los balanceadores de cargaMediante la CLI
$ nomad run minusaddress=http lt ip_c lus te r gt4646 lt f i l e hclgt
O mediante la API HTTP de Nomad$ cu r l minusX POST minusd ltf i l e hclgthttp lt ip_c lus te r gt4646 jobltjob_namegt
Ansible
Como se puede comprobar con el aumento del nuacutemero de equipos pasa aser inviable manejar todos los nodos a traveacutes de terminal Ademaacutes como seha comentado con anterioridad Nomad requiere que en los nodos clientes es-teacuten instalados las herramientas que soporten las tareas por ejemplo el motorde Docker Por ello para facilitar tanto el arranque como la instalacioacuten de lasdependencias vamos a usar Ansible una herramienta de coacutedigo abierto desarro-llada en Python que permite gestionar configuraciones aprovisionar recursosdespliegue de aplicaciones de forma automaacutetica
A grandes rasgos esta herramienta funciona mediante ficheros en formatoYAML denominados play-books que describen un conjunto de pasos a ejecutaren una lista de equipos remotos Estos pasos son ejecutados por moacutedulos inde-pendientes a traveacutes de SSH es decir en cualquier ordenador con conexioacuten a los
38
hosts dado su contrasentildea o clave puacuteblica puede arrancar el script y realizariacutealos pasos de forma remota gestionando el cluster desde un solo equipo
Se han desarrollado guiones para lo siguiente
Descarga de los binarios de Nomad y Consul en todos los nodos copiade los ficheros de configuracioacuten baacutesicos y modificarlos de acuerdo a cadanodo (nombre del equipo direccioacuten IP)
Instalacioacuten de las dependencias
Arranque de Nomad y Consul
Ansible extiende su funcionalidad a traveacutes de moacutedulos independientes que per-miten por ejemplo instalar paquetes mediante herramientas de gestioacuten de pa-quetes (APT yum) aprovisionar automaacuteticamente maacutequinas virtuales de Ama-zon EC2
Algunas opciones de los ficheros de configuracioacuten de Nomad y Consul sondependientes del nodo particular por ejemplo la interfaz de red Para estetrabajo se ha realizado un moacutedulo para modificar los ficheros de configuracioacutende forma automaacutetica En el repositorio del proyecto se encuentra una carpetadonde se encuentran todos los ficheros necesarios para desplegar un clustertotalmente funcional solo requiere de una liacutenea de terminal con Ansible
$ ans ib l eminusplaybook minus i hos t s minusk ltssh_passgt minusu ltnode_usergt s i t e yml
39
62 Servicio de integracioacuten continua
Se ha implementado un sistema de integracioacuten continua que permite ejecu-tar tareas de compilacioacuten y pruebas de forma distribuida aumentando asiacute elrendimiento de los equipos En primer lugar se detallaraacute los motivos por los quepuede resultar beneficioso para las empresas una implementacioacuten de este tipo alo que seguiraacute los detalles del despliegue
621 DevOps
Metodologiacutea que defiende la comunicacioacuten y colaboracioacuten entre desarrolla-dores de software y los profesionales de operaciones a lo largo de todo el ciclo devida de una aplicacioacuten Estaacute muy relacionado con el desarrollo aacutegil de softwareesto es un enfoque para los proyectos que defiende el desarrollo iterativo e in-cremental donde los requisitos y soluciones evolucionan con el tiempo seguacuten lanecesidad del proyecto DevOps extiende esta filosofiacutea a todas los componentesde un servicio incluyendo sistemas y operaciones
Se trata de un concepto que cada organizacioacuten o empresa adapta a suspropias necesidades y procesos de negocio en este proyecto nos vamos a centraren la integracioacuten continua una praacutectica fundamental tanto del desarrollo aacutegilcomo de esta filosofiacutea
622 Integracioacuten Continua
Se define como una praacutectica de desarrollo software donde los miembros delequipo ponen en comuacuten su trabajo frecuentemente al menos una vez al diacutea21Cada integracioacuten se verifica con una compilacioacuten automaacutetica que incluye laejecucioacuten de pruebas para detectar errores de integracioacuten tan pronto como seaposible
Desde el punto de vista operativo esto supone automatizar la configuracioacutende equipos o el despliegue de maacutequinas virtuales donde compilar el proyecto yejecutar las pruebas y posteriormente eliminarlas Este flujo de trabajo se vebeneficiado en entornos distribuidos ya que el objetivo del desarrollador es com-probar el resultado de las pruebas raacutepidamente sin preocuparse del despliegueo los propios equipos
Para esta prueba de concepto vamos a usar Jenkins un servidor de integra-cioacuten continua escrito en Java que nos permite definir trabajos que contendraacutenla descripcioacuten tanto del entorno como su ejecucioacuten
Este sigue una estructura maestro-esclavo muy similar al de los gestores declusters usados en este proyecto el maestro contiene toda la loacutegica del servicio
21httpmartinfowlercomarticlescontinuousIntegrationhtml
40
trabajos autenticacioacuten y los esclavos son los encargados de la ejecucioacuten ensiacute Jenkins tiene varias viacuteas para aprovisionar los uacuteltimos
Mediante SSH
Interfaz graacutefica
Desarrollar un script propio
Ejecucioacuten de un fichero java
La ventaja de usar planificadores es que el despliegue de esclavos es dinaacutemicoes decir no tener una maacutequina especiacuteficamente configurada para ello DCOS yNomad se encargaraacuten de configurar estos despliegues en sus maacutequinas y poste-riormente eliminarlos Para ello se ha usado la uacuteltima opcioacuten definiendo tareasque descarguen el fichero java Con todo ello se consigue un entorno de inte-gracioacuten continua eficiente que ademaacutes permite la ejecucioacuten de otros servicios deforma independiente
Jenkins permite la creacioacuten de plugins que extienden sus funcionalidadesTanto Nomad22 como Apache Mesos cuentan con uno que permite su integra-cioacuten
Para esta prueba se va a usar el mismo proyecto que para el caso de usode orquestacioacuten de contenedores la aplicacioacuten web al que se le ha antildeadido untest para comprobar que se conecta correctamente a la base de datos medianteMocha un framework de Nodejs Por otro lado se antildeade el plugin de git ya queel coacutedigo se obtiene de GitHub el repositorio remoto de control de versiones delproyecto
El proceso general de ejecucioacuten seriacutea como sigue
1 Se ejecuta el maestro de Jenkins como tarea Docker partiendo de la imagenoficial
2 Al arrancar un trabajo se manda una tarea a los planificadores que laasignaraacuten a un nodo cliente Esta tarea consiste en la descarga del ficherode configuracioacuten Java y arrancarlo configurando el equipo como un clientede Jenkins temporalmente
3 Jenkins ejecuta el trabajo en el nuevo cliente en este caso iniciar la apli-cacioacuten web iniciar las pruebas y generar un informe
4 Se elimina el cliente
A continuacioacuten se detallan los matices de cada herramienta a la hora de imple-mentar este servicio
22Desarrollado por Ivo Verberk httpwwwivoverberknl
41
623 Jenkins con Nomad
El plugin permite la ejecucioacuten del fichero Java mediante dos controladorescontenedores Docker y Java En este proyecto nos hemos decantado por el pri-mero ya que nos ahorra instalar la maacutequina virtual de java en todos los nodoscliente Por ello se ha construido un contenedor base con Java para la ejecucioacutendel fichero de configuracioacuten y Nodejs para lanzar la aplicacioacuten web
El plugin se configura con la direccioacuten IP del cluster y el contenedor queejecuta el esclavo Jenkins Por su parte el trabajo en Jenkins se define conel repositorio en GitHub donde se aloja el coacutedigo del proyecto a probar y loscomandos a ejecutar en este caso npm update y npm test
624 Jenkins con DCOS
En el caso de DCOS su sistema de paquetes incluye Jenkins por lo queal instalarlo ya se tiene la configuracioacuten de Mesos totalmente funcional Sinembargo para ejecutar la aplicacioacuten en particular y las pruebas se requiere deNodejs en los equipos esclavos por ello debemos antildeadir un plugin de Jenkinsque permite instalar este entorno antes de ejecutar el trabajo Una vez hechoesto soacutelo queda definir la tarea igual que en el caso anterior
Cabe destacar que Mesosphere tambieacuten ha desarrollado un plugin que per-mite hacer despliegues en Marathon de tal manera que permitiriacutea con cadacommit del coacutedigo compilar la imagen del contenedor Docker y desplegarlaautomaacuteticamente aunque en este proyecto no se ha hecho pruebas de esta fun-cionalidad
42
7 Escalando la infraestructura
Uno de los factores clave que se busca a la hora de implementar sistemasdistribuidos es el poder escalar la infraestructura de forma maacutes sencilla estoes detectar que las maacutequinas estaacuten alcanzando el liacutemite de su capacidad yaumentar eacutesta ya sea mejorando sus caracteriacutesticas teacutecnicas o antildeadiendo maacutesnodos al cluster
El coacutedigo y todos los ficheros de configuracioacuten de esta seccioacuten tambieacuten sepueden encontrar en el repositorio del proyecto en GitHub23
71 Disentildeo
Microsoft Azure permite organizar los servicios cloud de forma loacutegica a traveacutesde grupos de recursos y asiacute poder crear o eliminar eacutestos en conjunto parauna aplicacioacuten determinada (por ejemplo una aplicacioacuten web suele requerir demaacutequinas virtuales bases de datos almacenamiento) Ademaacutes dispone dela opcioacuten de crear plantillas en formato JSON que permite al desarrolladordefinir los recursos y su interrelacioacuten para desplegar de forma automaacutetica unainfraestructura TI en la nube
Azure tambieacuten ofrece la posibilidad de monitorizar el estado de las maacutequinasvirtuales a traveacutes de extensiones lo que permite configurar el escalado automaacute-tico al alcanzar cierto liacutemite definido por el operador Eacutesta es a priori la formaen que deberiacutea implementarse hablando en teacuterminos de eficiencia sin embargoesta aproximacioacuten es totalmente dependiente de la plataforma es decir no sepuede extrapolar a otro proveedor o sobre recursos propios sin realizar un nue-vo disentildeo En este proyecto las tareas que son ejecutadas por estos equipos notienen estado ya que todo lo relativo a la persistencia lo hemos asignado fueradel cluster esto permite escalar la plataforma a traveacutes de otra aproximaciones
Las plantillas aceptan una serie de variables a indicar por el usuario entreotras los conjuntos de escala para definir los nodos aceptan una variable quedefine el nuacutemero de maacutequinas que los componen Por otro lado Azure ofreceuna API REST y kits de desarrollo software (SDK por sus siglas en ingleacutes) quepermiten su despliegue de forma programaacutetica Aprovechando estas facilidadesen este proyecto se va a aproximar la escalabilidad con el sucesivo desplieguede la infraestructura de forma automaacutetica se monitorizan los equipos y si sedetecta una maacutequina excesivamente cargada se aumenta el nuacutemero de equiposen la plantilla y se vuelve a desplegar
23httpsgithubcomAntonioAlfrzCloud-Orchestrators
43
En este proyecto se han disentildeado las plantillas para desplegar la arquitec-tura necesaria tanto de Nomad como de DCOS En el caso de la primera eldespliegue es maacutes descriptivo ya que incluye maacutequinas virtuales grupos de se-guridad redes En el caso de DCOS Azure cuenta con un servicio especiacuteficopara clusters gobernados por DCOS denominado Azure Container Service queincluye los componentes necesarios y la instalacioacuten ya realizada
72 Implementacioacuten
En primer lugar para monitorizar el estado de los equipos se va a usar laherramienta Nagios un sistema que permite controlar el estado del hardwarey los servicios de un equipo Se trata de una herramienta muy completa de laque se va a usar su capacidad para ejecutar comandos (plugins) en los nodospara detectar picos de carga generar alertas y ejecutar programas para estoseventos
Se ha desplegado una maacutequina virtual con esta herramienta en ambos siste-mas y se ha instalado una extensioacuten de Nagios (Nagios Remote Plugin Executor)en todos los nodos que permite ejecutar comprobaciones remotamente en con-creto para esta prueba de concepto medir el nivel de saturacioacuten de la unidadcentral de procesamiento (CPU por sus siglas del ingleacutes) Cuando sucede uncambio de estado de una maacutequina esto es cuando este paraacutemetro supera el liacutemi-te definido por el operador Nagios permite actuar en consecuencia ejecutandoprogramas por ello se ha desarrollado un script que ejecuta lo siguiente
Un programa desarrollado en Python con el SDK de Azure que modificalas plantillas y despliega los recursos
Un guioacuten de Ansible para instalar todos los componentes necesarios en lasnuevas maacutequinas y arrancar de nuevo el cluster y las aplicaciones
44
8 Resultados y conclusiones
En este uacuteltimo apartado se da una visioacuten global del proyecto asiacute como a lasconclusiones maacutes importantes a las que se ha llegado y posibles temas futurosde desarrollo
81 Comparacioacuten
Ambas herramientas ofrecen las funcionalidades para gestionar los recursoseficientemente ofreciendo a los desarrolladores una plataforma donde desplegarsus aplicaciones de forma distribuida independientemente de los equipos fiacutesicosy el hardware que las soporten
DCOS es una herramienta que en un comienzo fue privativa pero cuyos res-ponsables la empresa Mesosphere decidieron publicar una versioacuten de coacutedigoEacutesta nos permite gestionar un cluster de una forma sencilla y usable ademaacutes decomplementarlo con otras herramientas como el balanceador de carga integradoo la autenticacioacuten de usuarios ademaacutes estaacute basada en Apache Mesos un pro-yecto de relativa madurez y con el soporte de la Apache Software FoundationDe forma resumida DCOS ofrece muchas posibilidades y servicios a cambiode una arquitectura e instalacioacuten maacutes compleja
Por su parte HashiCorp con menor tiempo de desarrollo ha conseguidouna herramienta muy sencilla de desplegar que ademaacutes cumple con todas lasfuncionalidades baacutesicas ejecutando un simple binario en cada nodo se puededesplegar un gestor de clusters totalmente funcional Sin embargo no cuentacon todas las posibilidades de Mesos (Nomad cuenta con menos controladoresque entornos posibles de Mesos) ni con los antildeadidos de DCOS lo que implicael uso de otras herramientas para complementar el servicio (Consul HAProxy)
De entre las dificultades encontradas al usar estas herramientas y desplegaraplicaciones sobre ellas se puede destacar la depuracioacuten en ocasiones se desco-noce si un error viene de la propia herramienta de la aplicacioacuten desplegada o delequipo fiacutesico si no se cuenta con un sistema de procesamiento de registro unose puede encontrar con muacuteltiples terminales abiertas inspeccionando numerososficheros de registro buscando posibles errores Ademaacutes no dejan de ser solucio-nes que para usar eficientemente se debe conocer parte de su funcionamientoy sintaxis a la hora de describir la tareas lo que supone un esfuerzo antildeadido yaque cada una tiene sus particularidades y liacutemites
45
82 Conclusiones
En una sociedad cada vez maacutes digital las empresas deben adaptarse a unmercado cuya demanda de contenido no deja de crecer Las nuevas arquitecturascomo microservicios asiacute como la gran cantidad de datos generada implica queuna mejor gestioacuten de los recursos y la rapidez para desplegar o escalar solucionesdando valor al cliente lo maacutes raacutepido posible es uno de los objetivos de todas lasempresas de base tecnoloacutegica
Las ventajas que ofrecen los planificadores con aplicaciones distribuidas sonnumerosas sin ir maacutes lejos empresas tan punteras como Google llevan maacutesde 10 antildeos orquestando contenedores24 Por un lado permiten aumentar elrendimiento de los equipos propios y por otro implementar un servicio comoplataforma para despliegues distribuidos sobre cualquier conjunto hardware deesta forma se provee un servicio similar al de la nube puacuteblica pero con laprincipal diferencia de que se elimina la independencia con el proveedor (vendorlock-in) esto es las aplicaciones no tienen limitaciones impuestas por eacuteste talescomo lenguaje de programacioacuten o herramientas y permite despliegues hiacutebridosentre recursos propios y la nube
83 Objetivos conseguidos
Implementacioacuten de los planificadores propuestos en la nube Se ha en-tendido y detallado el funcionamiento de estas herramientas y se hanimplementado en el servicio de infraestructura de Microsoft Azure
Despliegue de aplicaciones y servicios distribuidos Servicios que se usanactualmente en la industria del desarrollo software asiacute como una aplica-cioacuten web con una arquitectura moderna han sido desplegados de formadistribuida en los equipos cumpliendo con la funcionalidad esperada ade-maacutes de consiguiendo una alta disponibilidad
Aproximacioacuten de arquitectura escalable Se ha hecho una aproximacioacutende infraestructura escalable de forma que sea parcialmente extrapolable aotros proveedores
24httpwwwnextplatformcom20160322decade-container-control-google
46
84 Liacuteneas de investigacioacuten
Siguiendo con la materia de este proyecto se presentan posibles liacuteneas deinvestigacioacuten
Analizar el despliegue con estas herramientas de aplicaciones de Big Datay comparar la eficiencia con respecto a soluciones especializadas
Analizar el rendimiento de los algoritmos de planificacioacuten antes pruebasde estreacutes y situaciones de alta contienda
Comparar el uso de estas herramientas con las praacutecticas actuales de laindustria o implementacioacuten en un sistema de produccioacuten real
47
Referencias
[1] LA Barroso y U Houmllzle laquoThe Datacenter as a Computer An Introduc-tion to the Design of Warehouse-Scale Machinesraquo En Morgan amp ClaypoolPublishers ()
[2] Systems Research Group ndash NetOS (University of Cambridge) The evolu-tion of cluster scheduler architectures 2016 url httpswwwclcamacukresearchsrgnetoscamsasblog2016-03-09-scheduler-architectureshtml
[3] A Das I Gupta y A Motivala SWIM Scalable Weakly-consistent Infection-style Process Group Membership Protocol Inf teacutec Dept of ComputerScience Cornell University url https www cs cornell edu ~asdasresearchdsn02-swimpdf
[4] D Dubhashi y A Das Mastering Mesos PACKT Publishing mayo de2016
[5] The Apache Software Foundation Apache Mesos documentation urlhttpsmesosapacheorg
[6] David Greenberg Building Applications on Mesos OrsquoReilly Media 2016[7] Armand Grillet Comparison of Container Schedulers Inf teacutec Technische
Universitaumlt Berlin[8] HashiCorp Consul documentation url httpswwwconsulio[9] HashiCorp Nomad documentation url httpsdcosio[10] Dan C Marinescu Cloud computing theory and practice Morgan Kauf-
mann 2013[11] Mesosphere DCOS documentation url httpswwwnomadproject
io[12] Microsoft Azure documentation url httpsazuremicrosoftcom
es-esdocumentation[13] D Ongaro y J Ousterhout In Search of an Understandable Consensus
Algorithm Inf teacutec Stanford University url httpsraftgithubioraftpdf
[14] Fei Teng laquoRessource allocation and schelduling models for cloud compu-tingraquo Tesis de mtriacutea Ecole Centrale Paris 2011
[15] A Williams y col Automation and Orchestration with Docker and Contai-ners A Comprehensive Overview of the Docker and Container Ecosystem3 The New Stack 2016
48
- Resumen
- Summary
- Iacutendice de figuras
- Introduccioacuten y objetivos
-
- Contexto
- Objetivos
- Estructura del documento
-
- Cloud Computing
- Nuevas cargas de trabajo
- Gestioacuten de recursos Planificadores
-
- Sistemas distribuidos
-
- Clasificacioacuten
-
- Herramientas
-
- DCOS
-
- Apache Mesos
- Ejemplos de uso
-
- Nomad
-
- Protocolo de consenso Raft
- Protocolo gossip SWIM
- Planificacioacuten
-
- Casos de uso y despliegue
-
- Aplicacioacuten Web
-
- DCOS
- Nomad
-
- Servicio de integracioacuten continua
-
- DevOps
- Integracioacuten Continua
- Jenkins con Nomad
- Jenkins con DCOS
-
- Escalando la infraestructura
-
- Disentildeo
- Implementacioacuten
-
- Resultados y conclusiones
-
- Comparacioacuten
- Conclusiones
- Objetivos conseguidos
- Liacuteneas de investigacioacuten
-
del tiempo de ida y vuelta (RTT por sus siglas en ingleacutes) de la red y no hayarespuesta Mi le vuelve a enviar un mensaje ping indirectamente a traveacutes deun nuacutemero k de miembros escogidos aleatoriamente De no recibir ninguna res-puesta Mi establece que Mj ha sufrido un fallo y lo etiqueta como ldquosospechosordquoinformando al componente de distribucioacuten
Figura 15 Diagrama de tiempo del protocolo SWIMFuente httpswwwcscornelledu
Componente de distribucioacuten
Se encarga de informar de cualquier cambio en los miembros a todo el con-junto Los eventos de nodo caiacutedo y la unioacuten o disociacioacuten de un miembro setransmiten a todos los servidores para que actualicen sus lista Para distribuirla informacioacuten a todos los nodos se podriacutea usar el meacutetodo de multicast perosuele estar deshabilitado Por ello se utiliza una teacutecnica de transmisioacuten denomi-nada Piggybacking mediante la cual se adjunta a los propios mensajes PINGy ACK del algoritmo la informacioacuten a distribuir reduciendo asiacute la congestioacutenen la red
523 Planificacioacuten
Proceso encargado de distribuir las tareas entre los nodos clientes de acuerdoa su estado
El planificador de Nomad estaacute basado en las publicaciones de Google sobresus herramientas de gestioacuten de clusters Borg y Omega14 y entiende los trabajosdescritos por el usuario como un estado deseado es decir su despliegue en unamaacutequina cliente de forma correcta y los clientes como el estado actual esto eslo que se encuentra en ejecucioacuten El registro actualizacioacuten o cancelacioacuten de un
14httpresearchgooglecompubspub43438html
24
trabajo asiacute como el fallo de un nodo cliente implican un cambio de estado atramitar por el sistema lo que se define como evaluacioacuten (evaluation) Esto uacutelti-mo supone comparar el estado actual (clientes) con el estado deseado (conjuntode trabajos registrados) y enviarlos a los planificadores correspondientes que seencargaraacuten de asignar las tareas a los nodos clientes
Figura 16 Procedimiento de asignacioacuten en NomadFuente httpswwwnomadprojectio
En la figura 16 se observa el flujo de trabajo en el que las distintas evalua-ciones se encolan en el evaluation broker que se ejecuta en el servidor liacuteder ygestiona las evaluaciones pendientes asignaacutendoles prioridades
A continuacioacuten los nodos servidores ejecutan los scheduling workers queprocesan las evaluaciones llamando a los distintos planificadores que generanun plan de asignacioacuten esto es un conjunto de relaciones entre las tareas y losnodos clientes donde se ejecutaraacuten Este proceso se divide en dos fases primerose descartan aquellos clientes que no cumplan los requisitos y posteriormentese asigna una calificacioacuten al resto Se selecciona el nodo con mayor puntuacioacuteny se encola el plan en el gestor que se ejecuta en el servidor liacuteder Existen tresplanificadores de acuerdo al tipo de trabajo
Service Incluye aquellos trabajos que estaacuten destinados a ejecutarse en un pe-riacuteodo largo de tiempo Para realizar las asignaciones el planificador evaluacuteala mayor parte de los nodos y usa una versioacuten del algoritmo Best fit in-fluenciada por el trabajo de Google en su herramienta Borg Se trata deun algoritmo de planificacioacuten que sacrifica tiempo a cambio de maximizarel rendimiento de los clientes asignando la tarea a la maacutequina que tengala mayor carga de trabajo con el objetivo de reducir equipos en funciona-
25
miento
Batch Tareas que incluyen listas de comandos en general de menor duracioacuteny que no requieren interaccioacuten con el usuario Se vale del algoritmo deSparrow desarrollado por la universidad de Berkeley15 para limitar losnodos clientes a evaluar
System Trabajos destinados a ejecutarse en todos los nodos incluso los que seunen al cluster posteriormente
Core Mantenimiento interno de Nomad
Una vez se ha realizado el proceso de planificacioacuten el nodo liacuteder lo registra enla cola de planes (plan queue) que se encarga de asignarles prioridad y manejarcondiciones de carrera es decir que no accedan a los recursos de los clientes sincontrol y evitar que eacutestos superen su capacidad
La maacutequina liacuteder del conjunto puede de este modo aceptar una asignacioacuteny ser ejecutada por los clientes o por el contrario rechazaacutersela al planificadorlo que implicariacutea realizar un plan parcial o totalmente nuevo
Finalmente el estado de las evaluaciones se actualizan y los clientes soninformados de las asignaciones ejecutaacutendose las tareas
15httppeopleeecsberkeleyedu~keopublicationssosp13-final17pdf
26
6 Casos de uso y despliegue
Con el objetivo de mostrar las posibles utilidades que este tipo de sistemaspueden tener en las infraestructuras TI actuales se han desplegado las dos he-rramientas en la nube Microsoft Azure usando su servicio cloud de instancias demaacutequinas virtuales Linux para simular un conjunto de ordenadores conectadosentre siacute por una red LAN Sobre ellas se ha implementado dos casos de usouna aplicacioacuten web con una arquitectura con cierta orientacioacuten a microserviciosy un sistema de integracioacuten continua
El coacutedigo y todos los ficheros de configuracioacuten se pueden encontrar en elrepositorio del proyecto en GitHub16
61 Aplicacioacuten Web
Se busca simular el proceso de adaptacioacuten de una solucioacuten web para su des-pliegue en un sistema distribuido con las herramientas anteriormente descritascon el objetivo de aumentar tanto su escalabilidad como disponibilidad medianteredundancia
Se ha partido de una aplicacioacuten ya existente17 un servicio de almacenamien-to y reproduccioacuten de canciones A grandes rasgos este servicio permite crearusuarios subir canciones con sus respectivas portadas tener playlists propias yescuchar las canciones a traveacutes de un navegador web
La solucioacuten estaacute dividida en 4 partes (figura 17)
Una vista web con la loacutegica
Un almacenamiento conectado en red (NAS por sus siglas en ingleacutes)
Una API REST para gestionar las peticiones al almacenamiento
Base de datos NoSQL basada en MongoDB
La nueva tendencia de los proyectos web es su implementacioacuten en contene-dores Docker ya que facilitan su portabilidad y ofrecen un procedimiento dedespliegue raacutepido sobre todo a la hora de desarrollar y realizar pruebas en en-tornos de produccioacuten simulados Por ello en este caso se va a hacer uso de los
16httpsgithubcomAntonioAlfrzCloud-Orchestrators17httpsgithubcomsonsoleslpCDPSfy
27
motores de orquestacioacuten de contenedores de ambas herramientas Marathon enDCOS y el controlador Docker en el caso de Nomad
Figura 17 Arquitectura aplicacioacuten web
A continuacioacuten vamos detallar el despliegue en ambas herramientas de es-ta solucioacuten y observar tanto queacute dificultades se encuentran como que ventajasofrecen El objetivo final es adaptar el proyecto modificaacutendolo lo menos posiblecon objeto de analizar la capacidad de estas herramientas para desplegar cual-quier aplicacioacuten sin que eso conlleve la modificacioacuten de la arquitectura de eacutestaes decir que no sea dependiente del entorno
611 DCOS
Se ha descrito DCOS como una herramienta que se despliega sobre un con-junto de ordenadores y que permite instalar gestionar el despliegue de sistemasdistribuidos
Microsoft Azure cuenta con una plantilla para desplegar en su servicio cloudun cluster de maacutequinas virtuales con DCOS ya instalado que cuenta con
Maacutequinas maestras (1 3 o 5 a seleccionar por el usuario) configuradascomo un conjunto de disponibilidad esto eso Azure da ciertas garantiacuteasde que al menos una maacutequina estaraacute en funcionamiento
Maacutequinas agentes Por motivos de seguridad se distinguen dos roles
bull Nodos privados solo accesibles desde la red interna y configuradoscomo un conjunto de escala un recurso de Azure para gestionar ydesplegar maacutequinas con configuraciones ideacutenticas para permitir unraacutepido escalado
bull Un equipo conectado accesible desde Internet a travntildees de un balan-ceador de carga puacuteblico y situado en una subred externa
28
Dos balanceadores de carga
bull La interfaz puacuteblica del cluster que se conecta con el cliente puacuteblicobull Acceso a los equipos maestros para el administrador que soacutelo permiteconexioacuten mediante SSH y credenciales
Almacenamiento para todas las maacutequinas
Configuraciones necesarias de red y seguridad
En la figura 18 se observa un diagrama de la infraestructura
Figura 18 Infraestructura en Azure
El primer obstaacuteculo es la persistencia de estado de la aplicacioacuten que seconsigue gracias a una base de datos no relacional basada en MongoDB asiacutecomo el almacenamiento de las canciones Para implementarla tenemos variasposibilidades
Montar un sistema externo de almacenamiento conectado en red en todoslos agentes donde se ejecuten las tareas de esta manera si una tarea pasade un nodo a otro por cualquier motivo puede tener acceso a los mismosficheros (opcioacuten del caso de uso original)
Implementar un sistema de ficheros distribuidos en los agentes
Usar los servicios de almacenamiento de las nubes puacuteblicas
Aprovechar el sistema de voluacutemenes persistentes de Apache Mesos Eacutestepermite reservar recursos de un agente de forma que al arrancar una tarease crea un volumen independiente del ciclo de vida de eacutesta con ello esosrecursos donde se ha almacenado la informacioacuten pueden volver a ofrecerseal mismo entorno de tal manera que otra tarea pueda acceder a ella
DCOS aprovecha este sistema de voluacutemenes persistentes y permite instalarbases de datos distribuidas como ArangoDB o Apache Cassandra sin embargoesto implicariacutea modificar todo el coacutedigo referente al modelo de la base de datos
29
Por motivos de eficiencia y latencia asiacute como de una mayor gobernabilidadde los datos la mejor opcioacuten es usar el recurso de voluacutemenes persistentes queofrece Apache Mesos ya que de esta manera se gestionariacutea la aplicacioacuten completamediante una uacutenica herramienta Sin embargo esto implica que la informacioacutense encuentra exclusivamente en el agente donde se haya ejecutado la tarea y porlo tanto se sigue requiriendo de software externo para distribuir la informacioacutenpara que se accesible para todos los agentes A la hora de realizar este proyectose encontraba en desarrollo Flocker una solucioacuten desarrollada por ClusterHQque permite compartir los voluacutemenes de Docker a traveacutes de un cluster quesi bien es compatible con el planificador de Mesos el proyecto se encontrabatodaviacutea en fases tempranas de desarrollo y los sistemas de almacenamiento quesoporta quedaban fuera del aacutembito de este trabajo
Por todo ello dado que las maacutequinas se han desplegado en la nube puacuteblicade Azure se decidioacute usar su servicio de almacenamiento de objetos para lascanciones y otra maacutequina para desplegar MongoDB y asiacute mantener el modelode datos original de la aplicacioacuten La diferencia del almacenamiento de obje-tos con respecto a nivel de fichero es que el primero no tiene jerarquiacutea paraorganizar los archivos eacutestos se guardan como objetos (con sus metadatos) enun mismo espacio soacutelo diferenciaacutendose por un identificador uacutenico esto implicaentre otras cosas que se puede acceder a un fichero dado uacutenicamente su IDindependientemente de la localizacioacuten fiacutesica de eacuteste facilitando pues la gestioacuteny el desarrollo
El coacutedigo del proyecto se ha modificado en los siguientes apartados
Las direcciones de la base de datos y los balanceadores de carga asiacute comosus puertos estaban originalmente fijos Se han configurado como variablesde entorno para facilitar el descubrimiento del servicio y hacer transpa-rente la aplicacioacuten al entorno de despliegue
La API REST se ha adaptado al almacenamiento en Azure en vez de enlocal
Estas modificaciones no suponen un cambio sustancial pero permiten separala persistencia de las tareas ejecutadas por DCOS lo que facilita en granmedida su ejecucioacuten al ser totalmente sin estado y ademaacutes implican tenerlos datos bajo un mayor control
Para la orquestacioacuten de contenedores se va a usar el entorno Marathondesarrollado tambieacuten por Mesosphere Eacuteste se puede usar a traveacutes de una interfazgraacutefica la interfaz de liacutenea de comandos (en lo que sigue CLI por sus siglas eningleacutes) de DCOS o con su API HTTP
Primero se han publicado la imaacutegenes de los contenedores que encapsulanla interfaz web y la api de la aplicacioacuten en el repositorio puacuteblico DockerHub
Los despliegues en este entorno se describen mediante ficheros JSON en losque se detalla entre otras opciones la imagen del contenedor los puertos a usar
30
los recursos que debe ocupar en un nodo o las instrucciones de monitorizacioacuten
Para el servicio de descubrimiento DCOS ofrece la posibilidad de asignardirecciones IP virtuales (VIP por sus siglas en ingleacutes) a tareas que se compartenen todos los nodos DCOS lleva integrado un balanceador de carga a nivel TCP(el componente denominado Minuteman) que balancea entre las direccionesvirtuales de las tareas y todas las instancias de eacutestas a lo largo del cluster Estoes necesario por dos motivos equilibrar la carga de los equipos con el fin deevitar un punto de uacutenico fallo mediante redundancia y evitar la contienda dedirecciones al ejecutar las tareas en puertos aleatorios
Este balanceador de carga estaacute basado en el trabajo de Michael Mitzenma-cher The Power of Two Choices in Randomized Load Balancing18 A grandesrasgos el algoritmo mantiene una media moacutevil exponencial de latencias paracada destino (backend) ademaacutes de las caiacutedas consecutivas Si un destino noresponde a una negociacioacuten en tres pasos (three way handshake) de forma con-secutiva en un periodo inferior a 5 ms se considera caiacutedo El algoritmo iterasobre los destinos disponibles en base a su histoacuterico de fallos y escoge dos deforma aleatoria de los cuales coge el de mejor meacutetrica
Las direcciones virtuales soacutelo se pueden resolver dentro del cluster porello para implementar la interfaz puacuteblica de la aplicacioacuten esto es el balancea-dor de carga de la interfaz web usaremos un paquete de DCOS denominadomarathon-lb un balanceador basado en HAProxy y adaptado por MesosphereEn este caso equilibra la carga de todas instancias de las tareas ejecutadas porel entorno Marathon por sus etiquetas y permite ademaacutes definir como puntode entrada muacuteltiples hosts virtuales definidos por sus nombres completos dedominio (FQDN por sus siglas en ingleacutes) en nuestro caso la interfaz puacuteblicadel balanceador de Azure para los agentes
Por motivos de seguridad todas las tareas se ejecutan en los agentes privadoses decir los que son exclusivamente accesibles desde la red interna Por su partemarathon-lb se ejecuta en el agente puacuteblico que cuenta con IP puacuteblica y lospuertos 80 (HTTP) y 8080 abiertos de forma que la aplicacioacuten sea accesibledesde Internet Esto es posible debido a que Apache Mesos permite reservarrecursos mediante roles asignados a nodos para un uso especiacutefico De esta formala arquitectura vista desde la aplicacioacuten quedariacutea como en la figura 19
18httpswwweecsharvardedu~michaelmpostscriptstpds2001pdf
31
Figura 19 Arquitectura de la aplicacioacuten web en DCOS
Ejecucioacuten
A la hora de desplegar la aplicacioacuten DCOS puede gestionarse medianteuna interfaz graacutefica o una interfaz de liacutenea de comandos La primera se accedea traveacutes de un navegador web en el puerto 80 (HTTP) y permite instalar losentornos disponibles observar el estado de los nodos y las tareas que se estaacutenejecutando y los ficheros de registros que eacutestas generan
La CLI permite el control desde un nodo o una maacutequina remota (suponiendoque los maestros tienen IP puacuteblica y el puerto 80 abierto) ya que DCOS tieneun sistema de autorizacioacuten que permite tener una interfaz puacuteblica con ciertasgarantiacuteas de seguridad
Por su parte cada entorno de trabajo puede ser controlado por la CLI peroademaacutes cuenta con sus propias interfaces Marathon expone una API HTTPen el puerto 8080 de la direccioacuten puacuteblica de los maestros del cluster asiacute comootra interfaz graacutefica Para desplegar un contenedor se podriacutea usar la CLI
$ dcos marathon app add lt f i l e j songt
O la API HTTP
$ cu r l minusX POST http lt ip_maestro gt8080v2apps minusd ltf i l e jsongt minusH Contentminustype app l i c a t i o n j son
32
612 Nomad
La arquitectura de Nomad es maacutes sencilla ya que solo requiere de un ficheroejecutable en todos los nodos para funcionar Si DCOS es la base de instala-cioacuten de entornos de terceros Nomad integra todas las funcionalidades baacutesicasesto es gestor de recursos planificador y ejecutor en los nodos cliente Estaherramienta cuenta con un menor tiempo de desarrollo y en el momento deescribir este documento cuenta exclusivamente con los siguientes controladoresen comparacioacuten con los entornos de DCOS
Motor Docker es decir funcioacuten de orquestacioacuten de contenedores
Ejecucioacuten de archivos binarios como comandos de Shell
Ejecucioacuten de aplicaciones Java
Virtualizacioacuten de maacutequinas mediante tecnologiacutea QEMU
Todos ellos necesitan que la tecnologiacutea subyacente esteacute instalada en las maacute-quinas clientes (Docker Java QEMU) Actualmente no permite el registro decontroladores por parte de terceros aunque estaacute planificado en un futuro ofreceruna interfaz para su desarrollo
Nomad no cuenta con el servicio de descubrimiento sin embargo puede inte-grarse con la herramienta Consul desarrollada por la misma empresa Por otrolado para el balanceo de carga usaremos un contenedor Docker con HAProxyuna herramienta de coacutedigo abierto que ofrece tanto servicios de proxy como debalanceador y cuyos ficheros de configuracioacuten completaremos con el proyectoConsul Template19
Consul
Consul sigue la misma arquitectura que Nomad es decir un nodo servidorque orquesta un conjunto de maacutequinas clientes y permite a los procesos que seejecutan en los equipos definirlos como servicios ofreciendo diversas caracteriacutes-ticas entorno a estos de los cuales vamos a usar dos
Descubrimiento de servicio Las maacutequinas clientes publican en el cataacutelogode servicios las tareas en ejecucioacuten y Consul les asigna nombres de dominioaccesibles por todos los miembros del cluster a traveacutes de la interfaz DNSincluida en esta herramientaConsul se integra con Nomad de forma que todas las tareas que se ejecu-ten en la segunda son automaacuteticamente publicados como servicios de laprimera de esta manera no hace falta conocer la direccioacuten de la maacutequinacliente donde se esteacute ejecutando el proceso ya que se puede acceder a eacutela traveacutes de su nombre de dominio de forma transparente Por ejemplo si
19[httpsgithubcomhashicorpconsul-template]
33
ejecutamos una tarea con ID web en el puerto 8080 se puede acceder aella en la direccioacuten webserviceconsul8080Para que las direcciones propias de Consul las resuelva su propio DNS y noel que esteacute asignado por defecto en la maacutequina usaremos la herramientadnsmasq20 que permite especificar la direccioacuten de un servidor DNS paraconsultas de direcciones especiacuteficas
Monitorizacioacuten Permite realizar comprobaciones del servicio y seguir su esta-do Aprovecharemos esta funcionalidad tanto para definir el propio procesode Nomad como servicio de Consul como las tareas desplegadas
HAProxy + Consul Template
HAProxy es una solucioacuten versaacutetil de coacutedigo abierto que ofrece solucionesde balanceo de carga y proxy Existen otras herramientas en el mercado comoNGINX o ldirectord sin embargo HAProxy suponiacutea una solucioacuten sencilla deconfigurar para mostrar el caso de uso
El uso de estas herramientas se debe a dos motivos para que no existacontienda con respecto a los puertos de los clientes usados por las tareas eacutestos sevan a asignar de forma dinaacutemica lo que en principio implicariacutea que la aplicacioacutendeberiacutea realizar consultas DNS de tipo SRV (que incluye puertos) a la interfazde Consul y balancear la carga entre tareas por redundancia y capacidad
Como la direccioacuten IP y puerto son variables cada vez que las tareas seactualicen o se reasignen es necesario volver a configurar HAProxy de formamanual Por ello HashiCorp ha desarrollado un programa denominado Con-sul Template que realiza peticiones sucesivas a la interfaz HTTP de Consul delas direcciones fiacutesicas de un servicio y reinicia automaacuteticamente el proceso deHAProxy Asiacute definiendo estas tareas como servicios Consul podremos tantomonitorizarlas como escalar las tareas dinaacutemicamente sin necesidad de cambiarel balanceador A partir del contenedor Docker oficial de HAProxy se ha desa-rrollado otro con la configuracioacuten baacutesica y con Consul Template para desplegarlocomo una tarea en Nomad
Despliegue
Se ha usado el mismo coacutedigo que en el apartado anterior con la persistenciaen el servicio de almacenamiento de Azure Desde la perspectiva del hardwarese implementaraacute la misma infraestructura que en el caso de DCOS (figura 18)estos es definiremos dos tipos de maacutequinas clientes un agente que se conectaraacutecon el balanceador de carga con nombre de dominio puacuteblico y donde se desple-garaacute el balanceador de carga de la vista web y agentes privados no accesiblesdesde fuera del cluster y donde se ejecutaraacuten el resto de tareas en la red inter-na La principal diferencia radica en las tareas que ejecutan HAproxy y ConsulTemplate que sustituye a las direcciones IP virtuales que ofrece DCOS
20httpwwwthekelleysorgukdnsmasqdochtml
34
Figura 20 Despliegue en Azure de Nomad+Consul
Cabe matizar que los balanceadores basados en HAProxy se implementanpor necesidad de la aplicacioacuten para el descubrimiento del servicio a diferenciade los de Azure que se implementan por motivos de seguridad y escalabilidaddel cluster en siacute
Configuracioacuten Nomad
Los ficheros de configuracioacuten de las maacutequinas maacutester y cliente son similaresy comparten la mayoriacutea de las opciones como por ejemplo el nombre del nodoo la interfaz de red donde escucha Nomad las peticiones Sus opciones son engeneral auto-explicativas sin embargo existen dos detalles que matizar
El proceso de Nomad escucha las peticiones tanto de los protocolos deconsenso como del usuario a traveacutes de una interfaz de red que se debeindicar en el fichero de configuracioacuten
En el caso de los clientes se deben indicar las direcciones de los servidoresdel cluster sin embargo se trata de un sistema dinaacutemico en el que losnodos pueden sufrir errores y cambiar de direccioacuten Por ello se ha definidoNomad como un servicio de Consul y asiacute poder definir la direccioacuten de losservidores como un nombre de dominio no por su direccioacuten fiacutesica que elservidor DNS de Consul se encargaraacute de resolver
Por defecto Nomad usa los siguientes puertos
API HTTP 4646 Peticiones HTTP y recepcioacuten de oacuterdenes mediante laliacutenea de comandos
RPC 4647 Protocolo de consenso entre los nodos del cluster
Serf 4648 Protocolo de gossip entre los servidores de los centros de datosgobernados por Nomad
35
Los dos uacuteltimos deben ser interfaces alcanzables por otros nodos sin embargo laAPI HTTP por motivos de seguridad deberiacutea ser local ya que en caso contrariocualquier persona con acceso a ella tiene el control sobre la herramienta Eacutestasolo deberiacutea estar accesible en un servidor o gestionarlo mediante una terminalSSH por ejemplo En este trabajo al ser una prueba de concepto se ha abiertoen todos los nodos
Trabajos de Nomad
Las tareas se detallan en ficheros con formato HashiCorp Configuration Lan-guage un derivado del formato JSON creado por la empresa que le da nombrecompatible con eacuteste y que permite comentarios
En estos ficheros se puede definir
La regioacuten y el centro de datos donde se ejecutaraacute (Nomad permite lagestioacuten de centros de datos geograacuteficamente distribuidos en regiones)
La poliacutetica de actualizacioacuten de la tarea
Grupo de tareas esto es que se ejecutaraacuten en el mismo nodo
El nuacutemero de grupos a ejecutarescalar asiacute como los liacutemite que debencumplir los nodos asignados
La poliacutetica de reinicio ante fallo o error
Tareas El controlador su configuracioacuten los paraacutemetros del servicio aso-ciado a registrar en Consul asiacute como los recursos que consume (puertosmemoria)
En nuestro caso usamos sobre todo el controlador Docker esto eso orques-tacioacuten de contenedores en los nodos clientes y tres de sus opciones
Imagen del contenedor Se han subido todas las imaacutegenes del proyecto a Doc-ker Hub donde por defecto se busca la imagen
Puertos Los puertos a usar por el contenedor que pueden ser estaacuteticos asigna-dos por el usuario o dinaacutemicos siendo Nomad el que se encarga de mapearun puerto libre del nodo cliente al expuesto por el contenedor
Servidores DNS Como usamos la interfaz DNS de Consul como descubri-miento de servicio se debe configurar el contenedor para que use cualquiernodo del cluster como servidor DNS
Configuracioacuten Consul
Al ser desarrolladas por la misma empresa los ficheros de configuracioacuten deConsul y Nomad comparten muchas opciones Consul tambieacuten acepta peticionesa traveacutes de una interfaz de red siendo los puertos usados por defecto
36
RPC 8300 8400 Maneja la peticiones del resto de nodos y usuarios
Serf 8301 8302 Protocolo gossip
HTTP API 8500
HTTPS API Desactivada por defecto
Interfaz DNS 8600
Se debe asignar a los protocolos internos del cluster esto es RPC y Serf unainterfaz alcanzable por los nodos y por el contrarioasignar a los dos uacuteltimos ala interfaz de loopback por motivos de seguridad
Cabe destacar que Consul tambieacuten cuenta con una interfaz graacutefica que per-mite ver el estado de los equipos y los servicios registrados y que se encuentra enel mismo puerto que la API HTTP en la direccioacuten httpIP_EQUIPO8500ui
Ejecucioacuten
Tanto Nomad como Consul requieren de la ejecucioacuten de un fichero en todoslos nodos integrantes del cluster Como prueba de concepto se ha decidido usardos servidores para ambos aunque cabe matizar que es un nuacutemero ineficienteya que la caiacuteda de uno de ellos supondriacutea la peacuterdida del cuoacuterum y por tantodel consenso del cluster
En primer lugar se arrancan los servidores que son los encargados de ejecu-tar el protocolo de consenso y gestionar el cluster y a continuacioacuten los clientesque no tienen praacutecticamente estado y dependen de los servidores
En el caso de Consul se debe indicar el directorio donde se guardan losficheros que describen los servicios asiacute como el archivo que especifica el resto delas opciones
1 Se inicia el primer servidor en uno de los equipos
$ consu l agent minuscon f i gminusd i r e t c consu l d s e r v i c e s minuscon f i gminus f i l e consu l_server j son
2 Los siguientes equipos deben unirse al anterior por lo que antildeadimos elargumento join con la direccioacuten del primer servidor Para el caso de otrosservidores
$ consu l agent minuscon f i gminusd i r e t c consu l d s e r v i c e s minuscon f i gminus f i l e consu l_server j son minus j o i n ltIP_servidor1gt
37
Una vez los servidores han alcanzado el consenso y elegido un liacuteder en losclientes
$ consu l agent minuscon f i gminusd i r e t c consu l d s e r v i c e s minuscon f i gminus f i l e c on su l_c l i en t j son minus j o i n ltIP_cualquierServ idorgt
El proceso para iniciar Nomad es igual y los comandos similares sin embargoya no es necesario indicar una direccioacuten IP fija en los equipos sino el nombre dedominio del servicio de Nomad registrado por Consul En el primer servidor
$ nomad agent minusc on f i g nomad_server j son
Y el resto de equipos (con su fichero de configuracioacuten correspondiente)$ nomad agent minusc on f i g nomad_server j son minus j o i n nomad s e r v i c e consu l
Por uacuteltimo para desplegar la aplicacioacuten web se han escrito tres ficherosque detallan las tareas de la interfaz web API y los balanceadores de cargaMediante la CLI
$ nomad run minusaddress=http lt ip_c lus te r gt4646 lt f i l e hclgt
O mediante la API HTTP de Nomad$ cu r l minusX POST minusd ltf i l e hclgthttp lt ip_c lus te r gt4646 jobltjob_namegt
Ansible
Como se puede comprobar con el aumento del nuacutemero de equipos pasa aser inviable manejar todos los nodos a traveacutes de terminal Ademaacutes como seha comentado con anterioridad Nomad requiere que en los nodos clientes es-teacuten instalados las herramientas que soporten las tareas por ejemplo el motorde Docker Por ello para facilitar tanto el arranque como la instalacioacuten de lasdependencias vamos a usar Ansible una herramienta de coacutedigo abierto desarro-llada en Python que permite gestionar configuraciones aprovisionar recursosdespliegue de aplicaciones de forma automaacutetica
A grandes rasgos esta herramienta funciona mediante ficheros en formatoYAML denominados play-books que describen un conjunto de pasos a ejecutaren una lista de equipos remotos Estos pasos son ejecutados por moacutedulos inde-pendientes a traveacutes de SSH es decir en cualquier ordenador con conexioacuten a los
38
hosts dado su contrasentildea o clave puacuteblica puede arrancar el script y realizariacutealos pasos de forma remota gestionando el cluster desde un solo equipo
Se han desarrollado guiones para lo siguiente
Descarga de los binarios de Nomad y Consul en todos los nodos copiade los ficheros de configuracioacuten baacutesicos y modificarlos de acuerdo a cadanodo (nombre del equipo direccioacuten IP)
Instalacioacuten de las dependencias
Arranque de Nomad y Consul
Ansible extiende su funcionalidad a traveacutes de moacutedulos independientes que per-miten por ejemplo instalar paquetes mediante herramientas de gestioacuten de pa-quetes (APT yum) aprovisionar automaacuteticamente maacutequinas virtuales de Ama-zon EC2
Algunas opciones de los ficheros de configuracioacuten de Nomad y Consul sondependientes del nodo particular por ejemplo la interfaz de red Para estetrabajo se ha realizado un moacutedulo para modificar los ficheros de configuracioacutende forma automaacutetica En el repositorio del proyecto se encuentra una carpetadonde se encuentran todos los ficheros necesarios para desplegar un clustertotalmente funcional solo requiere de una liacutenea de terminal con Ansible
$ ans ib l eminusplaybook minus i hos t s minusk ltssh_passgt minusu ltnode_usergt s i t e yml
39
62 Servicio de integracioacuten continua
Se ha implementado un sistema de integracioacuten continua que permite ejecu-tar tareas de compilacioacuten y pruebas de forma distribuida aumentando asiacute elrendimiento de los equipos En primer lugar se detallaraacute los motivos por los quepuede resultar beneficioso para las empresas una implementacioacuten de este tipo alo que seguiraacute los detalles del despliegue
621 DevOps
Metodologiacutea que defiende la comunicacioacuten y colaboracioacuten entre desarrolla-dores de software y los profesionales de operaciones a lo largo de todo el ciclo devida de una aplicacioacuten Estaacute muy relacionado con el desarrollo aacutegil de softwareesto es un enfoque para los proyectos que defiende el desarrollo iterativo e in-cremental donde los requisitos y soluciones evolucionan con el tiempo seguacuten lanecesidad del proyecto DevOps extiende esta filosofiacutea a todas los componentesde un servicio incluyendo sistemas y operaciones
Se trata de un concepto que cada organizacioacuten o empresa adapta a suspropias necesidades y procesos de negocio en este proyecto nos vamos a centraren la integracioacuten continua una praacutectica fundamental tanto del desarrollo aacutegilcomo de esta filosofiacutea
622 Integracioacuten Continua
Se define como una praacutectica de desarrollo software donde los miembros delequipo ponen en comuacuten su trabajo frecuentemente al menos una vez al diacutea21Cada integracioacuten se verifica con una compilacioacuten automaacutetica que incluye laejecucioacuten de pruebas para detectar errores de integracioacuten tan pronto como seaposible
Desde el punto de vista operativo esto supone automatizar la configuracioacutende equipos o el despliegue de maacutequinas virtuales donde compilar el proyecto yejecutar las pruebas y posteriormente eliminarlas Este flujo de trabajo se vebeneficiado en entornos distribuidos ya que el objetivo del desarrollador es com-probar el resultado de las pruebas raacutepidamente sin preocuparse del despliegueo los propios equipos
Para esta prueba de concepto vamos a usar Jenkins un servidor de integra-cioacuten continua escrito en Java que nos permite definir trabajos que contendraacutenla descripcioacuten tanto del entorno como su ejecucioacuten
Este sigue una estructura maestro-esclavo muy similar al de los gestores declusters usados en este proyecto el maestro contiene toda la loacutegica del servicio
21httpmartinfowlercomarticlescontinuousIntegrationhtml
40
trabajos autenticacioacuten y los esclavos son los encargados de la ejecucioacuten ensiacute Jenkins tiene varias viacuteas para aprovisionar los uacuteltimos
Mediante SSH
Interfaz graacutefica
Desarrollar un script propio
Ejecucioacuten de un fichero java
La ventaja de usar planificadores es que el despliegue de esclavos es dinaacutemicoes decir no tener una maacutequina especiacuteficamente configurada para ello DCOS yNomad se encargaraacuten de configurar estos despliegues en sus maacutequinas y poste-riormente eliminarlos Para ello se ha usado la uacuteltima opcioacuten definiendo tareasque descarguen el fichero java Con todo ello se consigue un entorno de inte-gracioacuten continua eficiente que ademaacutes permite la ejecucioacuten de otros servicios deforma independiente
Jenkins permite la creacioacuten de plugins que extienden sus funcionalidadesTanto Nomad22 como Apache Mesos cuentan con uno que permite su integra-cioacuten
Para esta prueba se va a usar el mismo proyecto que para el caso de usode orquestacioacuten de contenedores la aplicacioacuten web al que se le ha antildeadido untest para comprobar que se conecta correctamente a la base de datos medianteMocha un framework de Nodejs Por otro lado se antildeade el plugin de git ya queel coacutedigo se obtiene de GitHub el repositorio remoto de control de versiones delproyecto
El proceso general de ejecucioacuten seriacutea como sigue
1 Se ejecuta el maestro de Jenkins como tarea Docker partiendo de la imagenoficial
2 Al arrancar un trabajo se manda una tarea a los planificadores que laasignaraacuten a un nodo cliente Esta tarea consiste en la descarga del ficherode configuracioacuten Java y arrancarlo configurando el equipo como un clientede Jenkins temporalmente
3 Jenkins ejecuta el trabajo en el nuevo cliente en este caso iniciar la apli-cacioacuten web iniciar las pruebas y generar un informe
4 Se elimina el cliente
A continuacioacuten se detallan los matices de cada herramienta a la hora de imple-mentar este servicio
22Desarrollado por Ivo Verberk httpwwwivoverberknl
41
623 Jenkins con Nomad
El plugin permite la ejecucioacuten del fichero Java mediante dos controladorescontenedores Docker y Java En este proyecto nos hemos decantado por el pri-mero ya que nos ahorra instalar la maacutequina virtual de java en todos los nodoscliente Por ello se ha construido un contenedor base con Java para la ejecucioacutendel fichero de configuracioacuten y Nodejs para lanzar la aplicacioacuten web
El plugin se configura con la direccioacuten IP del cluster y el contenedor queejecuta el esclavo Jenkins Por su parte el trabajo en Jenkins se define conel repositorio en GitHub donde se aloja el coacutedigo del proyecto a probar y loscomandos a ejecutar en este caso npm update y npm test
624 Jenkins con DCOS
En el caso de DCOS su sistema de paquetes incluye Jenkins por lo queal instalarlo ya se tiene la configuracioacuten de Mesos totalmente funcional Sinembargo para ejecutar la aplicacioacuten en particular y las pruebas se requiere deNodejs en los equipos esclavos por ello debemos antildeadir un plugin de Jenkinsque permite instalar este entorno antes de ejecutar el trabajo Una vez hechoesto soacutelo queda definir la tarea igual que en el caso anterior
Cabe destacar que Mesosphere tambieacuten ha desarrollado un plugin que per-mite hacer despliegues en Marathon de tal manera que permitiriacutea con cadacommit del coacutedigo compilar la imagen del contenedor Docker y desplegarlaautomaacuteticamente aunque en este proyecto no se ha hecho pruebas de esta fun-cionalidad
42
7 Escalando la infraestructura
Uno de los factores clave que se busca a la hora de implementar sistemasdistribuidos es el poder escalar la infraestructura de forma maacutes sencilla estoes detectar que las maacutequinas estaacuten alcanzando el liacutemite de su capacidad yaumentar eacutesta ya sea mejorando sus caracteriacutesticas teacutecnicas o antildeadiendo maacutesnodos al cluster
El coacutedigo y todos los ficheros de configuracioacuten de esta seccioacuten tambieacuten sepueden encontrar en el repositorio del proyecto en GitHub23
71 Disentildeo
Microsoft Azure permite organizar los servicios cloud de forma loacutegica a traveacutesde grupos de recursos y asiacute poder crear o eliminar eacutestos en conjunto parauna aplicacioacuten determinada (por ejemplo una aplicacioacuten web suele requerir demaacutequinas virtuales bases de datos almacenamiento) Ademaacutes dispone dela opcioacuten de crear plantillas en formato JSON que permite al desarrolladordefinir los recursos y su interrelacioacuten para desplegar de forma automaacutetica unainfraestructura TI en la nube
Azure tambieacuten ofrece la posibilidad de monitorizar el estado de las maacutequinasvirtuales a traveacutes de extensiones lo que permite configurar el escalado automaacute-tico al alcanzar cierto liacutemite definido por el operador Eacutesta es a priori la formaen que deberiacutea implementarse hablando en teacuterminos de eficiencia sin embargoesta aproximacioacuten es totalmente dependiente de la plataforma es decir no sepuede extrapolar a otro proveedor o sobre recursos propios sin realizar un nue-vo disentildeo En este proyecto las tareas que son ejecutadas por estos equipos notienen estado ya que todo lo relativo a la persistencia lo hemos asignado fueradel cluster esto permite escalar la plataforma a traveacutes de otra aproximaciones
Las plantillas aceptan una serie de variables a indicar por el usuario entreotras los conjuntos de escala para definir los nodos aceptan una variable quedefine el nuacutemero de maacutequinas que los componen Por otro lado Azure ofreceuna API REST y kits de desarrollo software (SDK por sus siglas en ingleacutes) quepermiten su despliegue de forma programaacutetica Aprovechando estas facilidadesen este proyecto se va a aproximar la escalabilidad con el sucesivo desplieguede la infraestructura de forma automaacutetica se monitorizan los equipos y si sedetecta una maacutequina excesivamente cargada se aumenta el nuacutemero de equiposen la plantilla y se vuelve a desplegar
23httpsgithubcomAntonioAlfrzCloud-Orchestrators
43
En este proyecto se han disentildeado las plantillas para desplegar la arquitec-tura necesaria tanto de Nomad como de DCOS En el caso de la primera eldespliegue es maacutes descriptivo ya que incluye maacutequinas virtuales grupos de se-guridad redes En el caso de DCOS Azure cuenta con un servicio especiacuteficopara clusters gobernados por DCOS denominado Azure Container Service queincluye los componentes necesarios y la instalacioacuten ya realizada
72 Implementacioacuten
En primer lugar para monitorizar el estado de los equipos se va a usar laherramienta Nagios un sistema que permite controlar el estado del hardwarey los servicios de un equipo Se trata de una herramienta muy completa de laque se va a usar su capacidad para ejecutar comandos (plugins) en los nodospara detectar picos de carga generar alertas y ejecutar programas para estoseventos
Se ha desplegado una maacutequina virtual con esta herramienta en ambos siste-mas y se ha instalado una extensioacuten de Nagios (Nagios Remote Plugin Executor)en todos los nodos que permite ejecutar comprobaciones remotamente en con-creto para esta prueba de concepto medir el nivel de saturacioacuten de la unidadcentral de procesamiento (CPU por sus siglas del ingleacutes) Cuando sucede uncambio de estado de una maacutequina esto es cuando este paraacutemetro supera el liacutemi-te definido por el operador Nagios permite actuar en consecuencia ejecutandoprogramas por ello se ha desarrollado un script que ejecuta lo siguiente
Un programa desarrollado en Python con el SDK de Azure que modificalas plantillas y despliega los recursos
Un guioacuten de Ansible para instalar todos los componentes necesarios en lasnuevas maacutequinas y arrancar de nuevo el cluster y las aplicaciones
44
8 Resultados y conclusiones
En este uacuteltimo apartado se da una visioacuten global del proyecto asiacute como a lasconclusiones maacutes importantes a las que se ha llegado y posibles temas futurosde desarrollo
81 Comparacioacuten
Ambas herramientas ofrecen las funcionalidades para gestionar los recursoseficientemente ofreciendo a los desarrolladores una plataforma donde desplegarsus aplicaciones de forma distribuida independientemente de los equipos fiacutesicosy el hardware que las soporten
DCOS es una herramienta que en un comienzo fue privativa pero cuyos res-ponsables la empresa Mesosphere decidieron publicar una versioacuten de coacutedigoEacutesta nos permite gestionar un cluster de una forma sencilla y usable ademaacutes decomplementarlo con otras herramientas como el balanceador de carga integradoo la autenticacioacuten de usuarios ademaacutes estaacute basada en Apache Mesos un pro-yecto de relativa madurez y con el soporte de la Apache Software FoundationDe forma resumida DCOS ofrece muchas posibilidades y servicios a cambiode una arquitectura e instalacioacuten maacutes compleja
Por su parte HashiCorp con menor tiempo de desarrollo ha conseguidouna herramienta muy sencilla de desplegar que ademaacutes cumple con todas lasfuncionalidades baacutesicas ejecutando un simple binario en cada nodo se puededesplegar un gestor de clusters totalmente funcional Sin embargo no cuentacon todas las posibilidades de Mesos (Nomad cuenta con menos controladoresque entornos posibles de Mesos) ni con los antildeadidos de DCOS lo que implicael uso de otras herramientas para complementar el servicio (Consul HAProxy)
De entre las dificultades encontradas al usar estas herramientas y desplegaraplicaciones sobre ellas se puede destacar la depuracioacuten en ocasiones se desco-noce si un error viene de la propia herramienta de la aplicacioacuten desplegada o delequipo fiacutesico si no se cuenta con un sistema de procesamiento de registro unose puede encontrar con muacuteltiples terminales abiertas inspeccionando numerososficheros de registro buscando posibles errores Ademaacutes no dejan de ser solucio-nes que para usar eficientemente se debe conocer parte de su funcionamientoy sintaxis a la hora de describir la tareas lo que supone un esfuerzo antildeadido yaque cada una tiene sus particularidades y liacutemites
45
82 Conclusiones
En una sociedad cada vez maacutes digital las empresas deben adaptarse a unmercado cuya demanda de contenido no deja de crecer Las nuevas arquitecturascomo microservicios asiacute como la gran cantidad de datos generada implica queuna mejor gestioacuten de los recursos y la rapidez para desplegar o escalar solucionesdando valor al cliente lo maacutes raacutepido posible es uno de los objetivos de todas lasempresas de base tecnoloacutegica
Las ventajas que ofrecen los planificadores con aplicaciones distribuidas sonnumerosas sin ir maacutes lejos empresas tan punteras como Google llevan maacutesde 10 antildeos orquestando contenedores24 Por un lado permiten aumentar elrendimiento de los equipos propios y por otro implementar un servicio comoplataforma para despliegues distribuidos sobre cualquier conjunto hardware deesta forma se provee un servicio similar al de la nube puacuteblica pero con laprincipal diferencia de que se elimina la independencia con el proveedor (vendorlock-in) esto es las aplicaciones no tienen limitaciones impuestas por eacuteste talescomo lenguaje de programacioacuten o herramientas y permite despliegues hiacutebridosentre recursos propios y la nube
83 Objetivos conseguidos
Implementacioacuten de los planificadores propuestos en la nube Se ha en-tendido y detallado el funcionamiento de estas herramientas y se hanimplementado en el servicio de infraestructura de Microsoft Azure
Despliegue de aplicaciones y servicios distribuidos Servicios que se usanactualmente en la industria del desarrollo software asiacute como una aplica-cioacuten web con una arquitectura moderna han sido desplegados de formadistribuida en los equipos cumpliendo con la funcionalidad esperada ade-maacutes de consiguiendo una alta disponibilidad
Aproximacioacuten de arquitectura escalable Se ha hecho una aproximacioacutende infraestructura escalable de forma que sea parcialmente extrapolable aotros proveedores
24httpwwwnextplatformcom20160322decade-container-control-google
46
84 Liacuteneas de investigacioacuten
Siguiendo con la materia de este proyecto se presentan posibles liacuteneas deinvestigacioacuten
Analizar el despliegue con estas herramientas de aplicaciones de Big Datay comparar la eficiencia con respecto a soluciones especializadas
Analizar el rendimiento de los algoritmos de planificacioacuten antes pruebasde estreacutes y situaciones de alta contienda
Comparar el uso de estas herramientas con las praacutecticas actuales de laindustria o implementacioacuten en un sistema de produccioacuten real
47
Referencias
[1] LA Barroso y U Houmllzle laquoThe Datacenter as a Computer An Introduc-tion to the Design of Warehouse-Scale Machinesraquo En Morgan amp ClaypoolPublishers ()
[2] Systems Research Group ndash NetOS (University of Cambridge) The evolu-tion of cluster scheduler architectures 2016 url httpswwwclcamacukresearchsrgnetoscamsasblog2016-03-09-scheduler-architectureshtml
[3] A Das I Gupta y A Motivala SWIM Scalable Weakly-consistent Infection-style Process Group Membership Protocol Inf teacutec Dept of ComputerScience Cornell University url https www cs cornell edu ~asdasresearchdsn02-swimpdf
[4] D Dubhashi y A Das Mastering Mesos PACKT Publishing mayo de2016
[5] The Apache Software Foundation Apache Mesos documentation urlhttpsmesosapacheorg
[6] David Greenberg Building Applications on Mesos OrsquoReilly Media 2016[7] Armand Grillet Comparison of Container Schedulers Inf teacutec Technische
Universitaumlt Berlin[8] HashiCorp Consul documentation url httpswwwconsulio[9] HashiCorp Nomad documentation url httpsdcosio[10] Dan C Marinescu Cloud computing theory and practice Morgan Kauf-
mann 2013[11] Mesosphere DCOS documentation url httpswwwnomadproject
io[12] Microsoft Azure documentation url httpsazuremicrosoftcom
es-esdocumentation[13] D Ongaro y J Ousterhout In Search of an Understandable Consensus
Algorithm Inf teacutec Stanford University url httpsraftgithubioraftpdf
[14] Fei Teng laquoRessource allocation and schelduling models for cloud compu-tingraquo Tesis de mtriacutea Ecole Centrale Paris 2011
[15] A Williams y col Automation and Orchestration with Docker and Contai-ners A Comprehensive Overview of the Docker and Container Ecosystem3 The New Stack 2016
48
- Resumen
- Summary
- Iacutendice de figuras
- Introduccioacuten y objetivos
-
- Contexto
- Objetivos
- Estructura del documento
-
- Cloud Computing
- Nuevas cargas de trabajo
- Gestioacuten de recursos Planificadores
-
- Sistemas distribuidos
-
- Clasificacioacuten
-
- Herramientas
-
- DCOS
-
- Apache Mesos
- Ejemplos de uso
-
- Nomad
-
- Protocolo de consenso Raft
- Protocolo gossip SWIM
- Planificacioacuten
-
- Casos de uso y despliegue
-
- Aplicacioacuten Web
-
- DCOS
- Nomad
-
- Servicio de integracioacuten continua
-
- DevOps
- Integracioacuten Continua
- Jenkins con Nomad
- Jenkins con DCOS
-
- Escalando la infraestructura
-
- Disentildeo
- Implementacioacuten
-
- Resultados y conclusiones
-
- Comparacioacuten
- Conclusiones
- Objetivos conseguidos
- Liacuteneas de investigacioacuten
-
trabajo asiacute como el fallo de un nodo cliente implican un cambio de estado atramitar por el sistema lo que se define como evaluacioacuten (evaluation) Esto uacutelti-mo supone comparar el estado actual (clientes) con el estado deseado (conjuntode trabajos registrados) y enviarlos a los planificadores correspondientes que seencargaraacuten de asignar las tareas a los nodos clientes
Figura 16 Procedimiento de asignacioacuten en NomadFuente httpswwwnomadprojectio
En la figura 16 se observa el flujo de trabajo en el que las distintas evalua-ciones se encolan en el evaluation broker que se ejecuta en el servidor liacuteder ygestiona las evaluaciones pendientes asignaacutendoles prioridades
A continuacioacuten los nodos servidores ejecutan los scheduling workers queprocesan las evaluaciones llamando a los distintos planificadores que generanun plan de asignacioacuten esto es un conjunto de relaciones entre las tareas y losnodos clientes donde se ejecutaraacuten Este proceso se divide en dos fases primerose descartan aquellos clientes que no cumplan los requisitos y posteriormentese asigna una calificacioacuten al resto Se selecciona el nodo con mayor puntuacioacuteny se encola el plan en el gestor que se ejecuta en el servidor liacuteder Existen tresplanificadores de acuerdo al tipo de trabajo
Service Incluye aquellos trabajos que estaacuten destinados a ejecutarse en un pe-riacuteodo largo de tiempo Para realizar las asignaciones el planificador evaluacuteala mayor parte de los nodos y usa una versioacuten del algoritmo Best fit in-fluenciada por el trabajo de Google en su herramienta Borg Se trata deun algoritmo de planificacioacuten que sacrifica tiempo a cambio de maximizarel rendimiento de los clientes asignando la tarea a la maacutequina que tengala mayor carga de trabajo con el objetivo de reducir equipos en funciona-
25
miento
Batch Tareas que incluyen listas de comandos en general de menor duracioacuteny que no requieren interaccioacuten con el usuario Se vale del algoritmo deSparrow desarrollado por la universidad de Berkeley15 para limitar losnodos clientes a evaluar
System Trabajos destinados a ejecutarse en todos los nodos incluso los que seunen al cluster posteriormente
Core Mantenimiento interno de Nomad
Una vez se ha realizado el proceso de planificacioacuten el nodo liacuteder lo registra enla cola de planes (plan queue) que se encarga de asignarles prioridad y manejarcondiciones de carrera es decir que no accedan a los recursos de los clientes sincontrol y evitar que eacutestos superen su capacidad
La maacutequina liacuteder del conjunto puede de este modo aceptar una asignacioacuteny ser ejecutada por los clientes o por el contrario rechazaacutersela al planificadorlo que implicariacutea realizar un plan parcial o totalmente nuevo
Finalmente el estado de las evaluaciones se actualizan y los clientes soninformados de las asignaciones ejecutaacutendose las tareas
15httppeopleeecsberkeleyedu~keopublicationssosp13-final17pdf
26
6 Casos de uso y despliegue
Con el objetivo de mostrar las posibles utilidades que este tipo de sistemaspueden tener en las infraestructuras TI actuales se han desplegado las dos he-rramientas en la nube Microsoft Azure usando su servicio cloud de instancias demaacutequinas virtuales Linux para simular un conjunto de ordenadores conectadosentre siacute por una red LAN Sobre ellas se ha implementado dos casos de usouna aplicacioacuten web con una arquitectura con cierta orientacioacuten a microserviciosy un sistema de integracioacuten continua
El coacutedigo y todos los ficheros de configuracioacuten se pueden encontrar en elrepositorio del proyecto en GitHub16
61 Aplicacioacuten Web
Se busca simular el proceso de adaptacioacuten de una solucioacuten web para su des-pliegue en un sistema distribuido con las herramientas anteriormente descritascon el objetivo de aumentar tanto su escalabilidad como disponibilidad medianteredundancia
Se ha partido de una aplicacioacuten ya existente17 un servicio de almacenamien-to y reproduccioacuten de canciones A grandes rasgos este servicio permite crearusuarios subir canciones con sus respectivas portadas tener playlists propias yescuchar las canciones a traveacutes de un navegador web
La solucioacuten estaacute dividida en 4 partes (figura 17)
Una vista web con la loacutegica
Un almacenamiento conectado en red (NAS por sus siglas en ingleacutes)
Una API REST para gestionar las peticiones al almacenamiento
Base de datos NoSQL basada en MongoDB
La nueva tendencia de los proyectos web es su implementacioacuten en contene-dores Docker ya que facilitan su portabilidad y ofrecen un procedimiento dedespliegue raacutepido sobre todo a la hora de desarrollar y realizar pruebas en en-tornos de produccioacuten simulados Por ello en este caso se va a hacer uso de los
16httpsgithubcomAntonioAlfrzCloud-Orchestrators17httpsgithubcomsonsoleslpCDPSfy
27
motores de orquestacioacuten de contenedores de ambas herramientas Marathon enDCOS y el controlador Docker en el caso de Nomad
Figura 17 Arquitectura aplicacioacuten web
A continuacioacuten vamos detallar el despliegue en ambas herramientas de es-ta solucioacuten y observar tanto queacute dificultades se encuentran como que ventajasofrecen El objetivo final es adaptar el proyecto modificaacutendolo lo menos posiblecon objeto de analizar la capacidad de estas herramientas para desplegar cual-quier aplicacioacuten sin que eso conlleve la modificacioacuten de la arquitectura de eacutestaes decir que no sea dependiente del entorno
611 DCOS
Se ha descrito DCOS como una herramienta que se despliega sobre un con-junto de ordenadores y que permite instalar gestionar el despliegue de sistemasdistribuidos
Microsoft Azure cuenta con una plantilla para desplegar en su servicio cloudun cluster de maacutequinas virtuales con DCOS ya instalado que cuenta con
Maacutequinas maestras (1 3 o 5 a seleccionar por el usuario) configuradascomo un conjunto de disponibilidad esto eso Azure da ciertas garantiacuteasde que al menos una maacutequina estaraacute en funcionamiento
Maacutequinas agentes Por motivos de seguridad se distinguen dos roles
bull Nodos privados solo accesibles desde la red interna y configuradoscomo un conjunto de escala un recurso de Azure para gestionar ydesplegar maacutequinas con configuraciones ideacutenticas para permitir unraacutepido escalado
bull Un equipo conectado accesible desde Internet a travntildees de un balan-ceador de carga puacuteblico y situado en una subred externa
28
Dos balanceadores de carga
bull La interfaz puacuteblica del cluster que se conecta con el cliente puacuteblicobull Acceso a los equipos maestros para el administrador que soacutelo permiteconexioacuten mediante SSH y credenciales
Almacenamiento para todas las maacutequinas
Configuraciones necesarias de red y seguridad
En la figura 18 se observa un diagrama de la infraestructura
Figura 18 Infraestructura en Azure
El primer obstaacuteculo es la persistencia de estado de la aplicacioacuten que seconsigue gracias a una base de datos no relacional basada en MongoDB asiacutecomo el almacenamiento de las canciones Para implementarla tenemos variasposibilidades
Montar un sistema externo de almacenamiento conectado en red en todoslos agentes donde se ejecuten las tareas de esta manera si una tarea pasade un nodo a otro por cualquier motivo puede tener acceso a los mismosficheros (opcioacuten del caso de uso original)
Implementar un sistema de ficheros distribuidos en los agentes
Usar los servicios de almacenamiento de las nubes puacuteblicas
Aprovechar el sistema de voluacutemenes persistentes de Apache Mesos Eacutestepermite reservar recursos de un agente de forma que al arrancar una tarease crea un volumen independiente del ciclo de vida de eacutesta con ello esosrecursos donde se ha almacenado la informacioacuten pueden volver a ofrecerseal mismo entorno de tal manera que otra tarea pueda acceder a ella
DCOS aprovecha este sistema de voluacutemenes persistentes y permite instalarbases de datos distribuidas como ArangoDB o Apache Cassandra sin embargoesto implicariacutea modificar todo el coacutedigo referente al modelo de la base de datos
29
Por motivos de eficiencia y latencia asiacute como de una mayor gobernabilidadde los datos la mejor opcioacuten es usar el recurso de voluacutemenes persistentes queofrece Apache Mesos ya que de esta manera se gestionariacutea la aplicacioacuten completamediante una uacutenica herramienta Sin embargo esto implica que la informacioacutense encuentra exclusivamente en el agente donde se haya ejecutado la tarea y porlo tanto se sigue requiriendo de software externo para distribuir la informacioacutenpara que se accesible para todos los agentes A la hora de realizar este proyectose encontraba en desarrollo Flocker una solucioacuten desarrollada por ClusterHQque permite compartir los voluacutemenes de Docker a traveacutes de un cluster quesi bien es compatible con el planificador de Mesos el proyecto se encontrabatodaviacutea en fases tempranas de desarrollo y los sistemas de almacenamiento quesoporta quedaban fuera del aacutembito de este trabajo
Por todo ello dado que las maacutequinas se han desplegado en la nube puacuteblicade Azure se decidioacute usar su servicio de almacenamiento de objetos para lascanciones y otra maacutequina para desplegar MongoDB y asiacute mantener el modelode datos original de la aplicacioacuten La diferencia del almacenamiento de obje-tos con respecto a nivel de fichero es que el primero no tiene jerarquiacutea paraorganizar los archivos eacutestos se guardan como objetos (con sus metadatos) enun mismo espacio soacutelo diferenciaacutendose por un identificador uacutenico esto implicaentre otras cosas que se puede acceder a un fichero dado uacutenicamente su IDindependientemente de la localizacioacuten fiacutesica de eacuteste facilitando pues la gestioacuteny el desarrollo
El coacutedigo del proyecto se ha modificado en los siguientes apartados
Las direcciones de la base de datos y los balanceadores de carga asiacute comosus puertos estaban originalmente fijos Se han configurado como variablesde entorno para facilitar el descubrimiento del servicio y hacer transpa-rente la aplicacioacuten al entorno de despliegue
La API REST se ha adaptado al almacenamiento en Azure en vez de enlocal
Estas modificaciones no suponen un cambio sustancial pero permiten separala persistencia de las tareas ejecutadas por DCOS lo que facilita en granmedida su ejecucioacuten al ser totalmente sin estado y ademaacutes implican tenerlos datos bajo un mayor control
Para la orquestacioacuten de contenedores se va a usar el entorno Marathondesarrollado tambieacuten por Mesosphere Eacuteste se puede usar a traveacutes de una interfazgraacutefica la interfaz de liacutenea de comandos (en lo que sigue CLI por sus siglas eningleacutes) de DCOS o con su API HTTP
Primero se han publicado la imaacutegenes de los contenedores que encapsulanla interfaz web y la api de la aplicacioacuten en el repositorio puacuteblico DockerHub
Los despliegues en este entorno se describen mediante ficheros JSON en losque se detalla entre otras opciones la imagen del contenedor los puertos a usar
30
los recursos que debe ocupar en un nodo o las instrucciones de monitorizacioacuten
Para el servicio de descubrimiento DCOS ofrece la posibilidad de asignardirecciones IP virtuales (VIP por sus siglas en ingleacutes) a tareas que se compartenen todos los nodos DCOS lleva integrado un balanceador de carga a nivel TCP(el componente denominado Minuteman) que balancea entre las direccionesvirtuales de las tareas y todas las instancias de eacutestas a lo largo del cluster Estoes necesario por dos motivos equilibrar la carga de los equipos con el fin deevitar un punto de uacutenico fallo mediante redundancia y evitar la contienda dedirecciones al ejecutar las tareas en puertos aleatorios
Este balanceador de carga estaacute basado en el trabajo de Michael Mitzenma-cher The Power of Two Choices in Randomized Load Balancing18 A grandesrasgos el algoritmo mantiene una media moacutevil exponencial de latencias paracada destino (backend) ademaacutes de las caiacutedas consecutivas Si un destino noresponde a una negociacioacuten en tres pasos (three way handshake) de forma con-secutiva en un periodo inferior a 5 ms se considera caiacutedo El algoritmo iterasobre los destinos disponibles en base a su histoacuterico de fallos y escoge dos deforma aleatoria de los cuales coge el de mejor meacutetrica
Las direcciones virtuales soacutelo se pueden resolver dentro del cluster porello para implementar la interfaz puacuteblica de la aplicacioacuten esto es el balancea-dor de carga de la interfaz web usaremos un paquete de DCOS denominadomarathon-lb un balanceador basado en HAProxy y adaptado por MesosphereEn este caso equilibra la carga de todas instancias de las tareas ejecutadas porel entorno Marathon por sus etiquetas y permite ademaacutes definir como puntode entrada muacuteltiples hosts virtuales definidos por sus nombres completos dedominio (FQDN por sus siglas en ingleacutes) en nuestro caso la interfaz puacuteblicadel balanceador de Azure para los agentes
Por motivos de seguridad todas las tareas se ejecutan en los agentes privadoses decir los que son exclusivamente accesibles desde la red interna Por su partemarathon-lb se ejecuta en el agente puacuteblico que cuenta con IP puacuteblica y lospuertos 80 (HTTP) y 8080 abiertos de forma que la aplicacioacuten sea accesibledesde Internet Esto es posible debido a que Apache Mesos permite reservarrecursos mediante roles asignados a nodos para un uso especiacutefico De esta formala arquitectura vista desde la aplicacioacuten quedariacutea como en la figura 19
18httpswwweecsharvardedu~michaelmpostscriptstpds2001pdf
31
Figura 19 Arquitectura de la aplicacioacuten web en DCOS
Ejecucioacuten
A la hora de desplegar la aplicacioacuten DCOS puede gestionarse medianteuna interfaz graacutefica o una interfaz de liacutenea de comandos La primera se accedea traveacutes de un navegador web en el puerto 80 (HTTP) y permite instalar losentornos disponibles observar el estado de los nodos y las tareas que se estaacutenejecutando y los ficheros de registros que eacutestas generan
La CLI permite el control desde un nodo o una maacutequina remota (suponiendoque los maestros tienen IP puacuteblica y el puerto 80 abierto) ya que DCOS tieneun sistema de autorizacioacuten que permite tener una interfaz puacuteblica con ciertasgarantiacuteas de seguridad
Por su parte cada entorno de trabajo puede ser controlado por la CLI peroademaacutes cuenta con sus propias interfaces Marathon expone una API HTTPen el puerto 8080 de la direccioacuten puacuteblica de los maestros del cluster asiacute comootra interfaz graacutefica Para desplegar un contenedor se podriacutea usar la CLI
$ dcos marathon app add lt f i l e j songt
O la API HTTP
$ cu r l minusX POST http lt ip_maestro gt8080v2apps minusd ltf i l e jsongt minusH Contentminustype app l i c a t i o n j son
32
612 Nomad
La arquitectura de Nomad es maacutes sencilla ya que solo requiere de un ficheroejecutable en todos los nodos para funcionar Si DCOS es la base de instala-cioacuten de entornos de terceros Nomad integra todas las funcionalidades baacutesicasesto es gestor de recursos planificador y ejecutor en los nodos cliente Estaherramienta cuenta con un menor tiempo de desarrollo y en el momento deescribir este documento cuenta exclusivamente con los siguientes controladoresen comparacioacuten con los entornos de DCOS
Motor Docker es decir funcioacuten de orquestacioacuten de contenedores
Ejecucioacuten de archivos binarios como comandos de Shell
Ejecucioacuten de aplicaciones Java
Virtualizacioacuten de maacutequinas mediante tecnologiacutea QEMU
Todos ellos necesitan que la tecnologiacutea subyacente esteacute instalada en las maacute-quinas clientes (Docker Java QEMU) Actualmente no permite el registro decontroladores por parte de terceros aunque estaacute planificado en un futuro ofreceruna interfaz para su desarrollo
Nomad no cuenta con el servicio de descubrimiento sin embargo puede inte-grarse con la herramienta Consul desarrollada por la misma empresa Por otrolado para el balanceo de carga usaremos un contenedor Docker con HAProxyuna herramienta de coacutedigo abierto que ofrece tanto servicios de proxy como debalanceador y cuyos ficheros de configuracioacuten completaremos con el proyectoConsul Template19
Consul
Consul sigue la misma arquitectura que Nomad es decir un nodo servidorque orquesta un conjunto de maacutequinas clientes y permite a los procesos que seejecutan en los equipos definirlos como servicios ofreciendo diversas caracteriacutes-ticas entorno a estos de los cuales vamos a usar dos
Descubrimiento de servicio Las maacutequinas clientes publican en el cataacutelogode servicios las tareas en ejecucioacuten y Consul les asigna nombres de dominioaccesibles por todos los miembros del cluster a traveacutes de la interfaz DNSincluida en esta herramientaConsul se integra con Nomad de forma que todas las tareas que se ejecu-ten en la segunda son automaacuteticamente publicados como servicios de laprimera de esta manera no hace falta conocer la direccioacuten de la maacutequinacliente donde se esteacute ejecutando el proceso ya que se puede acceder a eacutela traveacutes de su nombre de dominio de forma transparente Por ejemplo si
19[httpsgithubcomhashicorpconsul-template]
33
ejecutamos una tarea con ID web en el puerto 8080 se puede acceder aella en la direccioacuten webserviceconsul8080Para que las direcciones propias de Consul las resuelva su propio DNS y noel que esteacute asignado por defecto en la maacutequina usaremos la herramientadnsmasq20 que permite especificar la direccioacuten de un servidor DNS paraconsultas de direcciones especiacuteficas
Monitorizacioacuten Permite realizar comprobaciones del servicio y seguir su esta-do Aprovecharemos esta funcionalidad tanto para definir el propio procesode Nomad como servicio de Consul como las tareas desplegadas
HAProxy + Consul Template
HAProxy es una solucioacuten versaacutetil de coacutedigo abierto que ofrece solucionesde balanceo de carga y proxy Existen otras herramientas en el mercado comoNGINX o ldirectord sin embargo HAProxy suponiacutea una solucioacuten sencilla deconfigurar para mostrar el caso de uso
El uso de estas herramientas se debe a dos motivos para que no existacontienda con respecto a los puertos de los clientes usados por las tareas eacutestos sevan a asignar de forma dinaacutemica lo que en principio implicariacutea que la aplicacioacutendeberiacutea realizar consultas DNS de tipo SRV (que incluye puertos) a la interfazde Consul y balancear la carga entre tareas por redundancia y capacidad
Como la direccioacuten IP y puerto son variables cada vez que las tareas seactualicen o se reasignen es necesario volver a configurar HAProxy de formamanual Por ello HashiCorp ha desarrollado un programa denominado Con-sul Template que realiza peticiones sucesivas a la interfaz HTTP de Consul delas direcciones fiacutesicas de un servicio y reinicia automaacuteticamente el proceso deHAProxy Asiacute definiendo estas tareas como servicios Consul podremos tantomonitorizarlas como escalar las tareas dinaacutemicamente sin necesidad de cambiarel balanceador A partir del contenedor Docker oficial de HAProxy se ha desa-rrollado otro con la configuracioacuten baacutesica y con Consul Template para desplegarlocomo una tarea en Nomad
Despliegue
Se ha usado el mismo coacutedigo que en el apartado anterior con la persistenciaen el servicio de almacenamiento de Azure Desde la perspectiva del hardwarese implementaraacute la misma infraestructura que en el caso de DCOS (figura 18)estos es definiremos dos tipos de maacutequinas clientes un agente que se conectaraacutecon el balanceador de carga con nombre de dominio puacuteblico y donde se desple-garaacute el balanceador de carga de la vista web y agentes privados no accesiblesdesde fuera del cluster y donde se ejecutaraacuten el resto de tareas en la red inter-na La principal diferencia radica en las tareas que ejecutan HAproxy y ConsulTemplate que sustituye a las direcciones IP virtuales que ofrece DCOS
20httpwwwthekelleysorgukdnsmasqdochtml
34
Figura 20 Despliegue en Azure de Nomad+Consul
Cabe matizar que los balanceadores basados en HAProxy se implementanpor necesidad de la aplicacioacuten para el descubrimiento del servicio a diferenciade los de Azure que se implementan por motivos de seguridad y escalabilidaddel cluster en siacute
Configuracioacuten Nomad
Los ficheros de configuracioacuten de las maacutequinas maacutester y cliente son similaresy comparten la mayoriacutea de las opciones como por ejemplo el nombre del nodoo la interfaz de red donde escucha Nomad las peticiones Sus opciones son engeneral auto-explicativas sin embargo existen dos detalles que matizar
El proceso de Nomad escucha las peticiones tanto de los protocolos deconsenso como del usuario a traveacutes de una interfaz de red que se debeindicar en el fichero de configuracioacuten
En el caso de los clientes se deben indicar las direcciones de los servidoresdel cluster sin embargo se trata de un sistema dinaacutemico en el que losnodos pueden sufrir errores y cambiar de direccioacuten Por ello se ha definidoNomad como un servicio de Consul y asiacute poder definir la direccioacuten de losservidores como un nombre de dominio no por su direccioacuten fiacutesica que elservidor DNS de Consul se encargaraacute de resolver
Por defecto Nomad usa los siguientes puertos
API HTTP 4646 Peticiones HTTP y recepcioacuten de oacuterdenes mediante laliacutenea de comandos
RPC 4647 Protocolo de consenso entre los nodos del cluster
Serf 4648 Protocolo de gossip entre los servidores de los centros de datosgobernados por Nomad
35
Los dos uacuteltimos deben ser interfaces alcanzables por otros nodos sin embargo laAPI HTTP por motivos de seguridad deberiacutea ser local ya que en caso contrariocualquier persona con acceso a ella tiene el control sobre la herramienta Eacutestasolo deberiacutea estar accesible en un servidor o gestionarlo mediante una terminalSSH por ejemplo En este trabajo al ser una prueba de concepto se ha abiertoen todos los nodos
Trabajos de Nomad
Las tareas se detallan en ficheros con formato HashiCorp Configuration Lan-guage un derivado del formato JSON creado por la empresa que le da nombrecompatible con eacuteste y que permite comentarios
En estos ficheros se puede definir
La regioacuten y el centro de datos donde se ejecutaraacute (Nomad permite lagestioacuten de centros de datos geograacuteficamente distribuidos en regiones)
La poliacutetica de actualizacioacuten de la tarea
Grupo de tareas esto es que se ejecutaraacuten en el mismo nodo
El nuacutemero de grupos a ejecutarescalar asiacute como los liacutemite que debencumplir los nodos asignados
La poliacutetica de reinicio ante fallo o error
Tareas El controlador su configuracioacuten los paraacutemetros del servicio aso-ciado a registrar en Consul asiacute como los recursos que consume (puertosmemoria)
En nuestro caso usamos sobre todo el controlador Docker esto eso orques-tacioacuten de contenedores en los nodos clientes y tres de sus opciones
Imagen del contenedor Se han subido todas las imaacutegenes del proyecto a Doc-ker Hub donde por defecto se busca la imagen
Puertos Los puertos a usar por el contenedor que pueden ser estaacuteticos asigna-dos por el usuario o dinaacutemicos siendo Nomad el que se encarga de mapearun puerto libre del nodo cliente al expuesto por el contenedor
Servidores DNS Como usamos la interfaz DNS de Consul como descubri-miento de servicio se debe configurar el contenedor para que use cualquiernodo del cluster como servidor DNS
Configuracioacuten Consul
Al ser desarrolladas por la misma empresa los ficheros de configuracioacuten deConsul y Nomad comparten muchas opciones Consul tambieacuten acepta peticionesa traveacutes de una interfaz de red siendo los puertos usados por defecto
36
RPC 8300 8400 Maneja la peticiones del resto de nodos y usuarios
Serf 8301 8302 Protocolo gossip
HTTP API 8500
HTTPS API Desactivada por defecto
Interfaz DNS 8600
Se debe asignar a los protocolos internos del cluster esto es RPC y Serf unainterfaz alcanzable por los nodos y por el contrarioasignar a los dos uacuteltimos ala interfaz de loopback por motivos de seguridad
Cabe destacar que Consul tambieacuten cuenta con una interfaz graacutefica que per-mite ver el estado de los equipos y los servicios registrados y que se encuentra enel mismo puerto que la API HTTP en la direccioacuten httpIP_EQUIPO8500ui
Ejecucioacuten
Tanto Nomad como Consul requieren de la ejecucioacuten de un fichero en todoslos nodos integrantes del cluster Como prueba de concepto se ha decidido usardos servidores para ambos aunque cabe matizar que es un nuacutemero ineficienteya que la caiacuteda de uno de ellos supondriacutea la peacuterdida del cuoacuterum y por tantodel consenso del cluster
En primer lugar se arrancan los servidores que son los encargados de ejecu-tar el protocolo de consenso y gestionar el cluster y a continuacioacuten los clientesque no tienen praacutecticamente estado y dependen de los servidores
En el caso de Consul se debe indicar el directorio donde se guardan losficheros que describen los servicios asiacute como el archivo que especifica el resto delas opciones
1 Se inicia el primer servidor en uno de los equipos
$ consu l agent minuscon f i gminusd i r e t c consu l d s e r v i c e s minuscon f i gminus f i l e consu l_server j son
2 Los siguientes equipos deben unirse al anterior por lo que antildeadimos elargumento join con la direccioacuten del primer servidor Para el caso de otrosservidores
$ consu l agent minuscon f i gminusd i r e t c consu l d s e r v i c e s minuscon f i gminus f i l e consu l_server j son minus j o i n ltIP_servidor1gt
37
Una vez los servidores han alcanzado el consenso y elegido un liacuteder en losclientes
$ consu l agent minuscon f i gminusd i r e t c consu l d s e r v i c e s minuscon f i gminus f i l e c on su l_c l i en t j son minus j o i n ltIP_cualquierServ idorgt
El proceso para iniciar Nomad es igual y los comandos similares sin embargoya no es necesario indicar una direccioacuten IP fija en los equipos sino el nombre dedominio del servicio de Nomad registrado por Consul En el primer servidor
$ nomad agent minusc on f i g nomad_server j son
Y el resto de equipos (con su fichero de configuracioacuten correspondiente)$ nomad agent minusc on f i g nomad_server j son minus j o i n nomad s e r v i c e consu l
Por uacuteltimo para desplegar la aplicacioacuten web se han escrito tres ficherosque detallan las tareas de la interfaz web API y los balanceadores de cargaMediante la CLI
$ nomad run minusaddress=http lt ip_c lus te r gt4646 lt f i l e hclgt
O mediante la API HTTP de Nomad$ cu r l minusX POST minusd ltf i l e hclgthttp lt ip_c lus te r gt4646 jobltjob_namegt
Ansible
Como se puede comprobar con el aumento del nuacutemero de equipos pasa aser inviable manejar todos los nodos a traveacutes de terminal Ademaacutes como seha comentado con anterioridad Nomad requiere que en los nodos clientes es-teacuten instalados las herramientas que soporten las tareas por ejemplo el motorde Docker Por ello para facilitar tanto el arranque como la instalacioacuten de lasdependencias vamos a usar Ansible una herramienta de coacutedigo abierto desarro-llada en Python que permite gestionar configuraciones aprovisionar recursosdespliegue de aplicaciones de forma automaacutetica
A grandes rasgos esta herramienta funciona mediante ficheros en formatoYAML denominados play-books que describen un conjunto de pasos a ejecutaren una lista de equipos remotos Estos pasos son ejecutados por moacutedulos inde-pendientes a traveacutes de SSH es decir en cualquier ordenador con conexioacuten a los
38
hosts dado su contrasentildea o clave puacuteblica puede arrancar el script y realizariacutealos pasos de forma remota gestionando el cluster desde un solo equipo
Se han desarrollado guiones para lo siguiente
Descarga de los binarios de Nomad y Consul en todos los nodos copiade los ficheros de configuracioacuten baacutesicos y modificarlos de acuerdo a cadanodo (nombre del equipo direccioacuten IP)
Instalacioacuten de las dependencias
Arranque de Nomad y Consul
Ansible extiende su funcionalidad a traveacutes de moacutedulos independientes que per-miten por ejemplo instalar paquetes mediante herramientas de gestioacuten de pa-quetes (APT yum) aprovisionar automaacuteticamente maacutequinas virtuales de Ama-zon EC2
Algunas opciones de los ficheros de configuracioacuten de Nomad y Consul sondependientes del nodo particular por ejemplo la interfaz de red Para estetrabajo se ha realizado un moacutedulo para modificar los ficheros de configuracioacutende forma automaacutetica En el repositorio del proyecto se encuentra una carpetadonde se encuentran todos los ficheros necesarios para desplegar un clustertotalmente funcional solo requiere de una liacutenea de terminal con Ansible
$ ans ib l eminusplaybook minus i hos t s minusk ltssh_passgt minusu ltnode_usergt s i t e yml
39
62 Servicio de integracioacuten continua
Se ha implementado un sistema de integracioacuten continua que permite ejecu-tar tareas de compilacioacuten y pruebas de forma distribuida aumentando asiacute elrendimiento de los equipos En primer lugar se detallaraacute los motivos por los quepuede resultar beneficioso para las empresas una implementacioacuten de este tipo alo que seguiraacute los detalles del despliegue
621 DevOps
Metodologiacutea que defiende la comunicacioacuten y colaboracioacuten entre desarrolla-dores de software y los profesionales de operaciones a lo largo de todo el ciclo devida de una aplicacioacuten Estaacute muy relacionado con el desarrollo aacutegil de softwareesto es un enfoque para los proyectos que defiende el desarrollo iterativo e in-cremental donde los requisitos y soluciones evolucionan con el tiempo seguacuten lanecesidad del proyecto DevOps extiende esta filosofiacutea a todas los componentesde un servicio incluyendo sistemas y operaciones
Se trata de un concepto que cada organizacioacuten o empresa adapta a suspropias necesidades y procesos de negocio en este proyecto nos vamos a centraren la integracioacuten continua una praacutectica fundamental tanto del desarrollo aacutegilcomo de esta filosofiacutea
622 Integracioacuten Continua
Se define como una praacutectica de desarrollo software donde los miembros delequipo ponen en comuacuten su trabajo frecuentemente al menos una vez al diacutea21Cada integracioacuten se verifica con una compilacioacuten automaacutetica que incluye laejecucioacuten de pruebas para detectar errores de integracioacuten tan pronto como seaposible
Desde el punto de vista operativo esto supone automatizar la configuracioacutende equipos o el despliegue de maacutequinas virtuales donde compilar el proyecto yejecutar las pruebas y posteriormente eliminarlas Este flujo de trabajo se vebeneficiado en entornos distribuidos ya que el objetivo del desarrollador es com-probar el resultado de las pruebas raacutepidamente sin preocuparse del despliegueo los propios equipos
Para esta prueba de concepto vamos a usar Jenkins un servidor de integra-cioacuten continua escrito en Java que nos permite definir trabajos que contendraacutenla descripcioacuten tanto del entorno como su ejecucioacuten
Este sigue una estructura maestro-esclavo muy similar al de los gestores declusters usados en este proyecto el maestro contiene toda la loacutegica del servicio
21httpmartinfowlercomarticlescontinuousIntegrationhtml
40
trabajos autenticacioacuten y los esclavos son los encargados de la ejecucioacuten ensiacute Jenkins tiene varias viacuteas para aprovisionar los uacuteltimos
Mediante SSH
Interfaz graacutefica
Desarrollar un script propio
Ejecucioacuten de un fichero java
La ventaja de usar planificadores es que el despliegue de esclavos es dinaacutemicoes decir no tener una maacutequina especiacuteficamente configurada para ello DCOS yNomad se encargaraacuten de configurar estos despliegues en sus maacutequinas y poste-riormente eliminarlos Para ello se ha usado la uacuteltima opcioacuten definiendo tareasque descarguen el fichero java Con todo ello se consigue un entorno de inte-gracioacuten continua eficiente que ademaacutes permite la ejecucioacuten de otros servicios deforma independiente
Jenkins permite la creacioacuten de plugins que extienden sus funcionalidadesTanto Nomad22 como Apache Mesos cuentan con uno que permite su integra-cioacuten
Para esta prueba se va a usar el mismo proyecto que para el caso de usode orquestacioacuten de contenedores la aplicacioacuten web al que se le ha antildeadido untest para comprobar que se conecta correctamente a la base de datos medianteMocha un framework de Nodejs Por otro lado se antildeade el plugin de git ya queel coacutedigo se obtiene de GitHub el repositorio remoto de control de versiones delproyecto
El proceso general de ejecucioacuten seriacutea como sigue
1 Se ejecuta el maestro de Jenkins como tarea Docker partiendo de la imagenoficial
2 Al arrancar un trabajo se manda una tarea a los planificadores que laasignaraacuten a un nodo cliente Esta tarea consiste en la descarga del ficherode configuracioacuten Java y arrancarlo configurando el equipo como un clientede Jenkins temporalmente
3 Jenkins ejecuta el trabajo en el nuevo cliente en este caso iniciar la apli-cacioacuten web iniciar las pruebas y generar un informe
4 Se elimina el cliente
A continuacioacuten se detallan los matices de cada herramienta a la hora de imple-mentar este servicio
22Desarrollado por Ivo Verberk httpwwwivoverberknl
41
623 Jenkins con Nomad
El plugin permite la ejecucioacuten del fichero Java mediante dos controladorescontenedores Docker y Java En este proyecto nos hemos decantado por el pri-mero ya que nos ahorra instalar la maacutequina virtual de java en todos los nodoscliente Por ello se ha construido un contenedor base con Java para la ejecucioacutendel fichero de configuracioacuten y Nodejs para lanzar la aplicacioacuten web
El plugin se configura con la direccioacuten IP del cluster y el contenedor queejecuta el esclavo Jenkins Por su parte el trabajo en Jenkins se define conel repositorio en GitHub donde se aloja el coacutedigo del proyecto a probar y loscomandos a ejecutar en este caso npm update y npm test
624 Jenkins con DCOS
En el caso de DCOS su sistema de paquetes incluye Jenkins por lo queal instalarlo ya se tiene la configuracioacuten de Mesos totalmente funcional Sinembargo para ejecutar la aplicacioacuten en particular y las pruebas se requiere deNodejs en los equipos esclavos por ello debemos antildeadir un plugin de Jenkinsque permite instalar este entorno antes de ejecutar el trabajo Una vez hechoesto soacutelo queda definir la tarea igual que en el caso anterior
Cabe destacar que Mesosphere tambieacuten ha desarrollado un plugin que per-mite hacer despliegues en Marathon de tal manera que permitiriacutea con cadacommit del coacutedigo compilar la imagen del contenedor Docker y desplegarlaautomaacuteticamente aunque en este proyecto no se ha hecho pruebas de esta fun-cionalidad
42
7 Escalando la infraestructura
Uno de los factores clave que se busca a la hora de implementar sistemasdistribuidos es el poder escalar la infraestructura de forma maacutes sencilla estoes detectar que las maacutequinas estaacuten alcanzando el liacutemite de su capacidad yaumentar eacutesta ya sea mejorando sus caracteriacutesticas teacutecnicas o antildeadiendo maacutesnodos al cluster
El coacutedigo y todos los ficheros de configuracioacuten de esta seccioacuten tambieacuten sepueden encontrar en el repositorio del proyecto en GitHub23
71 Disentildeo
Microsoft Azure permite organizar los servicios cloud de forma loacutegica a traveacutesde grupos de recursos y asiacute poder crear o eliminar eacutestos en conjunto parauna aplicacioacuten determinada (por ejemplo una aplicacioacuten web suele requerir demaacutequinas virtuales bases de datos almacenamiento) Ademaacutes dispone dela opcioacuten de crear plantillas en formato JSON que permite al desarrolladordefinir los recursos y su interrelacioacuten para desplegar de forma automaacutetica unainfraestructura TI en la nube
Azure tambieacuten ofrece la posibilidad de monitorizar el estado de las maacutequinasvirtuales a traveacutes de extensiones lo que permite configurar el escalado automaacute-tico al alcanzar cierto liacutemite definido por el operador Eacutesta es a priori la formaen que deberiacutea implementarse hablando en teacuterminos de eficiencia sin embargoesta aproximacioacuten es totalmente dependiente de la plataforma es decir no sepuede extrapolar a otro proveedor o sobre recursos propios sin realizar un nue-vo disentildeo En este proyecto las tareas que son ejecutadas por estos equipos notienen estado ya que todo lo relativo a la persistencia lo hemos asignado fueradel cluster esto permite escalar la plataforma a traveacutes de otra aproximaciones
Las plantillas aceptan una serie de variables a indicar por el usuario entreotras los conjuntos de escala para definir los nodos aceptan una variable quedefine el nuacutemero de maacutequinas que los componen Por otro lado Azure ofreceuna API REST y kits de desarrollo software (SDK por sus siglas en ingleacutes) quepermiten su despliegue de forma programaacutetica Aprovechando estas facilidadesen este proyecto se va a aproximar la escalabilidad con el sucesivo desplieguede la infraestructura de forma automaacutetica se monitorizan los equipos y si sedetecta una maacutequina excesivamente cargada se aumenta el nuacutemero de equiposen la plantilla y se vuelve a desplegar
23httpsgithubcomAntonioAlfrzCloud-Orchestrators
43
En este proyecto se han disentildeado las plantillas para desplegar la arquitec-tura necesaria tanto de Nomad como de DCOS En el caso de la primera eldespliegue es maacutes descriptivo ya que incluye maacutequinas virtuales grupos de se-guridad redes En el caso de DCOS Azure cuenta con un servicio especiacuteficopara clusters gobernados por DCOS denominado Azure Container Service queincluye los componentes necesarios y la instalacioacuten ya realizada
72 Implementacioacuten
En primer lugar para monitorizar el estado de los equipos se va a usar laherramienta Nagios un sistema que permite controlar el estado del hardwarey los servicios de un equipo Se trata de una herramienta muy completa de laque se va a usar su capacidad para ejecutar comandos (plugins) en los nodospara detectar picos de carga generar alertas y ejecutar programas para estoseventos
Se ha desplegado una maacutequina virtual con esta herramienta en ambos siste-mas y se ha instalado una extensioacuten de Nagios (Nagios Remote Plugin Executor)en todos los nodos que permite ejecutar comprobaciones remotamente en con-creto para esta prueba de concepto medir el nivel de saturacioacuten de la unidadcentral de procesamiento (CPU por sus siglas del ingleacutes) Cuando sucede uncambio de estado de una maacutequina esto es cuando este paraacutemetro supera el liacutemi-te definido por el operador Nagios permite actuar en consecuencia ejecutandoprogramas por ello se ha desarrollado un script que ejecuta lo siguiente
Un programa desarrollado en Python con el SDK de Azure que modificalas plantillas y despliega los recursos
Un guioacuten de Ansible para instalar todos los componentes necesarios en lasnuevas maacutequinas y arrancar de nuevo el cluster y las aplicaciones
44
8 Resultados y conclusiones
En este uacuteltimo apartado se da una visioacuten global del proyecto asiacute como a lasconclusiones maacutes importantes a las que se ha llegado y posibles temas futurosde desarrollo
81 Comparacioacuten
Ambas herramientas ofrecen las funcionalidades para gestionar los recursoseficientemente ofreciendo a los desarrolladores una plataforma donde desplegarsus aplicaciones de forma distribuida independientemente de los equipos fiacutesicosy el hardware que las soporten
DCOS es una herramienta que en un comienzo fue privativa pero cuyos res-ponsables la empresa Mesosphere decidieron publicar una versioacuten de coacutedigoEacutesta nos permite gestionar un cluster de una forma sencilla y usable ademaacutes decomplementarlo con otras herramientas como el balanceador de carga integradoo la autenticacioacuten de usuarios ademaacutes estaacute basada en Apache Mesos un pro-yecto de relativa madurez y con el soporte de la Apache Software FoundationDe forma resumida DCOS ofrece muchas posibilidades y servicios a cambiode una arquitectura e instalacioacuten maacutes compleja
Por su parte HashiCorp con menor tiempo de desarrollo ha conseguidouna herramienta muy sencilla de desplegar que ademaacutes cumple con todas lasfuncionalidades baacutesicas ejecutando un simple binario en cada nodo se puededesplegar un gestor de clusters totalmente funcional Sin embargo no cuentacon todas las posibilidades de Mesos (Nomad cuenta con menos controladoresque entornos posibles de Mesos) ni con los antildeadidos de DCOS lo que implicael uso de otras herramientas para complementar el servicio (Consul HAProxy)
De entre las dificultades encontradas al usar estas herramientas y desplegaraplicaciones sobre ellas se puede destacar la depuracioacuten en ocasiones se desco-noce si un error viene de la propia herramienta de la aplicacioacuten desplegada o delequipo fiacutesico si no se cuenta con un sistema de procesamiento de registro unose puede encontrar con muacuteltiples terminales abiertas inspeccionando numerososficheros de registro buscando posibles errores Ademaacutes no dejan de ser solucio-nes que para usar eficientemente se debe conocer parte de su funcionamientoy sintaxis a la hora de describir la tareas lo que supone un esfuerzo antildeadido yaque cada una tiene sus particularidades y liacutemites
45
82 Conclusiones
En una sociedad cada vez maacutes digital las empresas deben adaptarse a unmercado cuya demanda de contenido no deja de crecer Las nuevas arquitecturascomo microservicios asiacute como la gran cantidad de datos generada implica queuna mejor gestioacuten de los recursos y la rapidez para desplegar o escalar solucionesdando valor al cliente lo maacutes raacutepido posible es uno de los objetivos de todas lasempresas de base tecnoloacutegica
Las ventajas que ofrecen los planificadores con aplicaciones distribuidas sonnumerosas sin ir maacutes lejos empresas tan punteras como Google llevan maacutesde 10 antildeos orquestando contenedores24 Por un lado permiten aumentar elrendimiento de los equipos propios y por otro implementar un servicio comoplataforma para despliegues distribuidos sobre cualquier conjunto hardware deesta forma se provee un servicio similar al de la nube puacuteblica pero con laprincipal diferencia de que se elimina la independencia con el proveedor (vendorlock-in) esto es las aplicaciones no tienen limitaciones impuestas por eacuteste talescomo lenguaje de programacioacuten o herramientas y permite despliegues hiacutebridosentre recursos propios y la nube
83 Objetivos conseguidos
Implementacioacuten de los planificadores propuestos en la nube Se ha en-tendido y detallado el funcionamiento de estas herramientas y se hanimplementado en el servicio de infraestructura de Microsoft Azure
Despliegue de aplicaciones y servicios distribuidos Servicios que se usanactualmente en la industria del desarrollo software asiacute como una aplica-cioacuten web con una arquitectura moderna han sido desplegados de formadistribuida en los equipos cumpliendo con la funcionalidad esperada ade-maacutes de consiguiendo una alta disponibilidad
Aproximacioacuten de arquitectura escalable Se ha hecho una aproximacioacutende infraestructura escalable de forma que sea parcialmente extrapolable aotros proveedores
24httpwwwnextplatformcom20160322decade-container-control-google
46
84 Liacuteneas de investigacioacuten
Siguiendo con la materia de este proyecto se presentan posibles liacuteneas deinvestigacioacuten
Analizar el despliegue con estas herramientas de aplicaciones de Big Datay comparar la eficiencia con respecto a soluciones especializadas
Analizar el rendimiento de los algoritmos de planificacioacuten antes pruebasde estreacutes y situaciones de alta contienda
Comparar el uso de estas herramientas con las praacutecticas actuales de laindustria o implementacioacuten en un sistema de produccioacuten real
47
Referencias
[1] LA Barroso y U Houmllzle laquoThe Datacenter as a Computer An Introduc-tion to the Design of Warehouse-Scale Machinesraquo En Morgan amp ClaypoolPublishers ()
[2] Systems Research Group ndash NetOS (University of Cambridge) The evolu-tion of cluster scheduler architectures 2016 url httpswwwclcamacukresearchsrgnetoscamsasblog2016-03-09-scheduler-architectureshtml
[3] A Das I Gupta y A Motivala SWIM Scalable Weakly-consistent Infection-style Process Group Membership Protocol Inf teacutec Dept of ComputerScience Cornell University url https www cs cornell edu ~asdasresearchdsn02-swimpdf
[4] D Dubhashi y A Das Mastering Mesos PACKT Publishing mayo de2016
[5] The Apache Software Foundation Apache Mesos documentation urlhttpsmesosapacheorg
[6] David Greenberg Building Applications on Mesos OrsquoReilly Media 2016[7] Armand Grillet Comparison of Container Schedulers Inf teacutec Technische
Universitaumlt Berlin[8] HashiCorp Consul documentation url httpswwwconsulio[9] HashiCorp Nomad documentation url httpsdcosio[10] Dan C Marinescu Cloud computing theory and practice Morgan Kauf-
mann 2013[11] Mesosphere DCOS documentation url httpswwwnomadproject
io[12] Microsoft Azure documentation url httpsazuremicrosoftcom
es-esdocumentation[13] D Ongaro y J Ousterhout In Search of an Understandable Consensus
Algorithm Inf teacutec Stanford University url httpsraftgithubioraftpdf
[14] Fei Teng laquoRessource allocation and schelduling models for cloud compu-tingraquo Tesis de mtriacutea Ecole Centrale Paris 2011
[15] A Williams y col Automation and Orchestration with Docker and Contai-ners A Comprehensive Overview of the Docker and Container Ecosystem3 The New Stack 2016
48
- Resumen
- Summary
- Iacutendice de figuras
- Introduccioacuten y objetivos
-
- Contexto
- Objetivos
- Estructura del documento
-
- Cloud Computing
- Nuevas cargas de trabajo
- Gestioacuten de recursos Planificadores
-
- Sistemas distribuidos
-
- Clasificacioacuten
-
- Herramientas
-
- DCOS
-
- Apache Mesos
- Ejemplos de uso
-
- Nomad
-
- Protocolo de consenso Raft
- Protocolo gossip SWIM
- Planificacioacuten
-
- Casos de uso y despliegue
-
- Aplicacioacuten Web
-
- DCOS
- Nomad
-
- Servicio de integracioacuten continua
-
- DevOps
- Integracioacuten Continua
- Jenkins con Nomad
- Jenkins con DCOS
-
- Escalando la infraestructura
-
- Disentildeo
- Implementacioacuten
-
- Resultados y conclusiones
-
- Comparacioacuten
- Conclusiones
- Objetivos conseguidos
- Liacuteneas de investigacioacuten
-
miento
Batch Tareas que incluyen listas de comandos en general de menor duracioacuteny que no requieren interaccioacuten con el usuario Se vale del algoritmo deSparrow desarrollado por la universidad de Berkeley15 para limitar losnodos clientes a evaluar
System Trabajos destinados a ejecutarse en todos los nodos incluso los que seunen al cluster posteriormente
Core Mantenimiento interno de Nomad
Una vez se ha realizado el proceso de planificacioacuten el nodo liacuteder lo registra enla cola de planes (plan queue) que se encarga de asignarles prioridad y manejarcondiciones de carrera es decir que no accedan a los recursos de los clientes sincontrol y evitar que eacutestos superen su capacidad
La maacutequina liacuteder del conjunto puede de este modo aceptar una asignacioacuteny ser ejecutada por los clientes o por el contrario rechazaacutersela al planificadorlo que implicariacutea realizar un plan parcial o totalmente nuevo
Finalmente el estado de las evaluaciones se actualizan y los clientes soninformados de las asignaciones ejecutaacutendose las tareas
15httppeopleeecsberkeleyedu~keopublicationssosp13-final17pdf
26
6 Casos de uso y despliegue
Con el objetivo de mostrar las posibles utilidades que este tipo de sistemaspueden tener en las infraestructuras TI actuales se han desplegado las dos he-rramientas en la nube Microsoft Azure usando su servicio cloud de instancias demaacutequinas virtuales Linux para simular un conjunto de ordenadores conectadosentre siacute por una red LAN Sobre ellas se ha implementado dos casos de usouna aplicacioacuten web con una arquitectura con cierta orientacioacuten a microserviciosy un sistema de integracioacuten continua
El coacutedigo y todos los ficheros de configuracioacuten se pueden encontrar en elrepositorio del proyecto en GitHub16
61 Aplicacioacuten Web
Se busca simular el proceso de adaptacioacuten de una solucioacuten web para su des-pliegue en un sistema distribuido con las herramientas anteriormente descritascon el objetivo de aumentar tanto su escalabilidad como disponibilidad medianteredundancia
Se ha partido de una aplicacioacuten ya existente17 un servicio de almacenamien-to y reproduccioacuten de canciones A grandes rasgos este servicio permite crearusuarios subir canciones con sus respectivas portadas tener playlists propias yescuchar las canciones a traveacutes de un navegador web
La solucioacuten estaacute dividida en 4 partes (figura 17)
Una vista web con la loacutegica
Un almacenamiento conectado en red (NAS por sus siglas en ingleacutes)
Una API REST para gestionar las peticiones al almacenamiento
Base de datos NoSQL basada en MongoDB
La nueva tendencia de los proyectos web es su implementacioacuten en contene-dores Docker ya que facilitan su portabilidad y ofrecen un procedimiento dedespliegue raacutepido sobre todo a la hora de desarrollar y realizar pruebas en en-tornos de produccioacuten simulados Por ello en este caso se va a hacer uso de los
16httpsgithubcomAntonioAlfrzCloud-Orchestrators17httpsgithubcomsonsoleslpCDPSfy
27
motores de orquestacioacuten de contenedores de ambas herramientas Marathon enDCOS y el controlador Docker en el caso de Nomad
Figura 17 Arquitectura aplicacioacuten web
A continuacioacuten vamos detallar el despliegue en ambas herramientas de es-ta solucioacuten y observar tanto queacute dificultades se encuentran como que ventajasofrecen El objetivo final es adaptar el proyecto modificaacutendolo lo menos posiblecon objeto de analizar la capacidad de estas herramientas para desplegar cual-quier aplicacioacuten sin que eso conlleve la modificacioacuten de la arquitectura de eacutestaes decir que no sea dependiente del entorno
611 DCOS
Se ha descrito DCOS como una herramienta que se despliega sobre un con-junto de ordenadores y que permite instalar gestionar el despliegue de sistemasdistribuidos
Microsoft Azure cuenta con una plantilla para desplegar en su servicio cloudun cluster de maacutequinas virtuales con DCOS ya instalado que cuenta con
Maacutequinas maestras (1 3 o 5 a seleccionar por el usuario) configuradascomo un conjunto de disponibilidad esto eso Azure da ciertas garantiacuteasde que al menos una maacutequina estaraacute en funcionamiento
Maacutequinas agentes Por motivos de seguridad se distinguen dos roles
bull Nodos privados solo accesibles desde la red interna y configuradoscomo un conjunto de escala un recurso de Azure para gestionar ydesplegar maacutequinas con configuraciones ideacutenticas para permitir unraacutepido escalado
bull Un equipo conectado accesible desde Internet a travntildees de un balan-ceador de carga puacuteblico y situado en una subred externa
28
Dos balanceadores de carga
bull La interfaz puacuteblica del cluster que se conecta con el cliente puacuteblicobull Acceso a los equipos maestros para el administrador que soacutelo permiteconexioacuten mediante SSH y credenciales
Almacenamiento para todas las maacutequinas
Configuraciones necesarias de red y seguridad
En la figura 18 se observa un diagrama de la infraestructura
Figura 18 Infraestructura en Azure
El primer obstaacuteculo es la persistencia de estado de la aplicacioacuten que seconsigue gracias a una base de datos no relacional basada en MongoDB asiacutecomo el almacenamiento de las canciones Para implementarla tenemos variasposibilidades
Montar un sistema externo de almacenamiento conectado en red en todoslos agentes donde se ejecuten las tareas de esta manera si una tarea pasade un nodo a otro por cualquier motivo puede tener acceso a los mismosficheros (opcioacuten del caso de uso original)
Implementar un sistema de ficheros distribuidos en los agentes
Usar los servicios de almacenamiento de las nubes puacuteblicas
Aprovechar el sistema de voluacutemenes persistentes de Apache Mesos Eacutestepermite reservar recursos de un agente de forma que al arrancar una tarease crea un volumen independiente del ciclo de vida de eacutesta con ello esosrecursos donde se ha almacenado la informacioacuten pueden volver a ofrecerseal mismo entorno de tal manera que otra tarea pueda acceder a ella
DCOS aprovecha este sistema de voluacutemenes persistentes y permite instalarbases de datos distribuidas como ArangoDB o Apache Cassandra sin embargoesto implicariacutea modificar todo el coacutedigo referente al modelo de la base de datos
29
Por motivos de eficiencia y latencia asiacute como de una mayor gobernabilidadde los datos la mejor opcioacuten es usar el recurso de voluacutemenes persistentes queofrece Apache Mesos ya que de esta manera se gestionariacutea la aplicacioacuten completamediante una uacutenica herramienta Sin embargo esto implica que la informacioacutense encuentra exclusivamente en el agente donde se haya ejecutado la tarea y porlo tanto se sigue requiriendo de software externo para distribuir la informacioacutenpara que se accesible para todos los agentes A la hora de realizar este proyectose encontraba en desarrollo Flocker una solucioacuten desarrollada por ClusterHQque permite compartir los voluacutemenes de Docker a traveacutes de un cluster quesi bien es compatible con el planificador de Mesos el proyecto se encontrabatodaviacutea en fases tempranas de desarrollo y los sistemas de almacenamiento quesoporta quedaban fuera del aacutembito de este trabajo
Por todo ello dado que las maacutequinas se han desplegado en la nube puacuteblicade Azure se decidioacute usar su servicio de almacenamiento de objetos para lascanciones y otra maacutequina para desplegar MongoDB y asiacute mantener el modelode datos original de la aplicacioacuten La diferencia del almacenamiento de obje-tos con respecto a nivel de fichero es que el primero no tiene jerarquiacutea paraorganizar los archivos eacutestos se guardan como objetos (con sus metadatos) enun mismo espacio soacutelo diferenciaacutendose por un identificador uacutenico esto implicaentre otras cosas que se puede acceder a un fichero dado uacutenicamente su IDindependientemente de la localizacioacuten fiacutesica de eacuteste facilitando pues la gestioacuteny el desarrollo
El coacutedigo del proyecto se ha modificado en los siguientes apartados
Las direcciones de la base de datos y los balanceadores de carga asiacute comosus puertos estaban originalmente fijos Se han configurado como variablesde entorno para facilitar el descubrimiento del servicio y hacer transpa-rente la aplicacioacuten al entorno de despliegue
La API REST se ha adaptado al almacenamiento en Azure en vez de enlocal
Estas modificaciones no suponen un cambio sustancial pero permiten separala persistencia de las tareas ejecutadas por DCOS lo que facilita en granmedida su ejecucioacuten al ser totalmente sin estado y ademaacutes implican tenerlos datos bajo un mayor control
Para la orquestacioacuten de contenedores se va a usar el entorno Marathondesarrollado tambieacuten por Mesosphere Eacuteste se puede usar a traveacutes de una interfazgraacutefica la interfaz de liacutenea de comandos (en lo que sigue CLI por sus siglas eningleacutes) de DCOS o con su API HTTP
Primero se han publicado la imaacutegenes de los contenedores que encapsulanla interfaz web y la api de la aplicacioacuten en el repositorio puacuteblico DockerHub
Los despliegues en este entorno se describen mediante ficheros JSON en losque se detalla entre otras opciones la imagen del contenedor los puertos a usar
30
los recursos que debe ocupar en un nodo o las instrucciones de monitorizacioacuten
Para el servicio de descubrimiento DCOS ofrece la posibilidad de asignardirecciones IP virtuales (VIP por sus siglas en ingleacutes) a tareas que se compartenen todos los nodos DCOS lleva integrado un balanceador de carga a nivel TCP(el componente denominado Minuteman) que balancea entre las direccionesvirtuales de las tareas y todas las instancias de eacutestas a lo largo del cluster Estoes necesario por dos motivos equilibrar la carga de los equipos con el fin deevitar un punto de uacutenico fallo mediante redundancia y evitar la contienda dedirecciones al ejecutar las tareas en puertos aleatorios
Este balanceador de carga estaacute basado en el trabajo de Michael Mitzenma-cher The Power of Two Choices in Randomized Load Balancing18 A grandesrasgos el algoritmo mantiene una media moacutevil exponencial de latencias paracada destino (backend) ademaacutes de las caiacutedas consecutivas Si un destino noresponde a una negociacioacuten en tres pasos (three way handshake) de forma con-secutiva en un periodo inferior a 5 ms se considera caiacutedo El algoritmo iterasobre los destinos disponibles en base a su histoacuterico de fallos y escoge dos deforma aleatoria de los cuales coge el de mejor meacutetrica
Las direcciones virtuales soacutelo se pueden resolver dentro del cluster porello para implementar la interfaz puacuteblica de la aplicacioacuten esto es el balancea-dor de carga de la interfaz web usaremos un paquete de DCOS denominadomarathon-lb un balanceador basado en HAProxy y adaptado por MesosphereEn este caso equilibra la carga de todas instancias de las tareas ejecutadas porel entorno Marathon por sus etiquetas y permite ademaacutes definir como puntode entrada muacuteltiples hosts virtuales definidos por sus nombres completos dedominio (FQDN por sus siglas en ingleacutes) en nuestro caso la interfaz puacuteblicadel balanceador de Azure para los agentes
Por motivos de seguridad todas las tareas se ejecutan en los agentes privadoses decir los que son exclusivamente accesibles desde la red interna Por su partemarathon-lb se ejecuta en el agente puacuteblico que cuenta con IP puacuteblica y lospuertos 80 (HTTP) y 8080 abiertos de forma que la aplicacioacuten sea accesibledesde Internet Esto es posible debido a que Apache Mesos permite reservarrecursos mediante roles asignados a nodos para un uso especiacutefico De esta formala arquitectura vista desde la aplicacioacuten quedariacutea como en la figura 19
18httpswwweecsharvardedu~michaelmpostscriptstpds2001pdf
31
Figura 19 Arquitectura de la aplicacioacuten web en DCOS
Ejecucioacuten
A la hora de desplegar la aplicacioacuten DCOS puede gestionarse medianteuna interfaz graacutefica o una interfaz de liacutenea de comandos La primera se accedea traveacutes de un navegador web en el puerto 80 (HTTP) y permite instalar losentornos disponibles observar el estado de los nodos y las tareas que se estaacutenejecutando y los ficheros de registros que eacutestas generan
La CLI permite el control desde un nodo o una maacutequina remota (suponiendoque los maestros tienen IP puacuteblica y el puerto 80 abierto) ya que DCOS tieneun sistema de autorizacioacuten que permite tener una interfaz puacuteblica con ciertasgarantiacuteas de seguridad
Por su parte cada entorno de trabajo puede ser controlado por la CLI peroademaacutes cuenta con sus propias interfaces Marathon expone una API HTTPen el puerto 8080 de la direccioacuten puacuteblica de los maestros del cluster asiacute comootra interfaz graacutefica Para desplegar un contenedor se podriacutea usar la CLI
$ dcos marathon app add lt f i l e j songt
O la API HTTP
$ cu r l minusX POST http lt ip_maestro gt8080v2apps minusd ltf i l e jsongt minusH Contentminustype app l i c a t i o n j son
32
612 Nomad
La arquitectura de Nomad es maacutes sencilla ya que solo requiere de un ficheroejecutable en todos los nodos para funcionar Si DCOS es la base de instala-cioacuten de entornos de terceros Nomad integra todas las funcionalidades baacutesicasesto es gestor de recursos planificador y ejecutor en los nodos cliente Estaherramienta cuenta con un menor tiempo de desarrollo y en el momento deescribir este documento cuenta exclusivamente con los siguientes controladoresen comparacioacuten con los entornos de DCOS
Motor Docker es decir funcioacuten de orquestacioacuten de contenedores
Ejecucioacuten de archivos binarios como comandos de Shell
Ejecucioacuten de aplicaciones Java
Virtualizacioacuten de maacutequinas mediante tecnologiacutea QEMU
Todos ellos necesitan que la tecnologiacutea subyacente esteacute instalada en las maacute-quinas clientes (Docker Java QEMU) Actualmente no permite el registro decontroladores por parte de terceros aunque estaacute planificado en un futuro ofreceruna interfaz para su desarrollo
Nomad no cuenta con el servicio de descubrimiento sin embargo puede inte-grarse con la herramienta Consul desarrollada por la misma empresa Por otrolado para el balanceo de carga usaremos un contenedor Docker con HAProxyuna herramienta de coacutedigo abierto que ofrece tanto servicios de proxy como debalanceador y cuyos ficheros de configuracioacuten completaremos con el proyectoConsul Template19
Consul
Consul sigue la misma arquitectura que Nomad es decir un nodo servidorque orquesta un conjunto de maacutequinas clientes y permite a los procesos que seejecutan en los equipos definirlos como servicios ofreciendo diversas caracteriacutes-ticas entorno a estos de los cuales vamos a usar dos
Descubrimiento de servicio Las maacutequinas clientes publican en el cataacutelogode servicios las tareas en ejecucioacuten y Consul les asigna nombres de dominioaccesibles por todos los miembros del cluster a traveacutes de la interfaz DNSincluida en esta herramientaConsul se integra con Nomad de forma que todas las tareas que se ejecu-ten en la segunda son automaacuteticamente publicados como servicios de laprimera de esta manera no hace falta conocer la direccioacuten de la maacutequinacliente donde se esteacute ejecutando el proceso ya que se puede acceder a eacutela traveacutes de su nombre de dominio de forma transparente Por ejemplo si
19[httpsgithubcomhashicorpconsul-template]
33
ejecutamos una tarea con ID web en el puerto 8080 se puede acceder aella en la direccioacuten webserviceconsul8080Para que las direcciones propias de Consul las resuelva su propio DNS y noel que esteacute asignado por defecto en la maacutequina usaremos la herramientadnsmasq20 que permite especificar la direccioacuten de un servidor DNS paraconsultas de direcciones especiacuteficas
Monitorizacioacuten Permite realizar comprobaciones del servicio y seguir su esta-do Aprovecharemos esta funcionalidad tanto para definir el propio procesode Nomad como servicio de Consul como las tareas desplegadas
HAProxy + Consul Template
HAProxy es una solucioacuten versaacutetil de coacutedigo abierto que ofrece solucionesde balanceo de carga y proxy Existen otras herramientas en el mercado comoNGINX o ldirectord sin embargo HAProxy suponiacutea una solucioacuten sencilla deconfigurar para mostrar el caso de uso
El uso de estas herramientas se debe a dos motivos para que no existacontienda con respecto a los puertos de los clientes usados por las tareas eacutestos sevan a asignar de forma dinaacutemica lo que en principio implicariacutea que la aplicacioacutendeberiacutea realizar consultas DNS de tipo SRV (que incluye puertos) a la interfazde Consul y balancear la carga entre tareas por redundancia y capacidad
Como la direccioacuten IP y puerto son variables cada vez que las tareas seactualicen o se reasignen es necesario volver a configurar HAProxy de formamanual Por ello HashiCorp ha desarrollado un programa denominado Con-sul Template que realiza peticiones sucesivas a la interfaz HTTP de Consul delas direcciones fiacutesicas de un servicio y reinicia automaacuteticamente el proceso deHAProxy Asiacute definiendo estas tareas como servicios Consul podremos tantomonitorizarlas como escalar las tareas dinaacutemicamente sin necesidad de cambiarel balanceador A partir del contenedor Docker oficial de HAProxy se ha desa-rrollado otro con la configuracioacuten baacutesica y con Consul Template para desplegarlocomo una tarea en Nomad
Despliegue
Se ha usado el mismo coacutedigo que en el apartado anterior con la persistenciaen el servicio de almacenamiento de Azure Desde la perspectiva del hardwarese implementaraacute la misma infraestructura que en el caso de DCOS (figura 18)estos es definiremos dos tipos de maacutequinas clientes un agente que se conectaraacutecon el balanceador de carga con nombre de dominio puacuteblico y donde se desple-garaacute el balanceador de carga de la vista web y agentes privados no accesiblesdesde fuera del cluster y donde se ejecutaraacuten el resto de tareas en la red inter-na La principal diferencia radica en las tareas que ejecutan HAproxy y ConsulTemplate que sustituye a las direcciones IP virtuales que ofrece DCOS
20httpwwwthekelleysorgukdnsmasqdochtml
34
Figura 20 Despliegue en Azure de Nomad+Consul
Cabe matizar que los balanceadores basados en HAProxy se implementanpor necesidad de la aplicacioacuten para el descubrimiento del servicio a diferenciade los de Azure que se implementan por motivos de seguridad y escalabilidaddel cluster en siacute
Configuracioacuten Nomad
Los ficheros de configuracioacuten de las maacutequinas maacutester y cliente son similaresy comparten la mayoriacutea de las opciones como por ejemplo el nombre del nodoo la interfaz de red donde escucha Nomad las peticiones Sus opciones son engeneral auto-explicativas sin embargo existen dos detalles que matizar
El proceso de Nomad escucha las peticiones tanto de los protocolos deconsenso como del usuario a traveacutes de una interfaz de red que se debeindicar en el fichero de configuracioacuten
En el caso de los clientes se deben indicar las direcciones de los servidoresdel cluster sin embargo se trata de un sistema dinaacutemico en el que losnodos pueden sufrir errores y cambiar de direccioacuten Por ello se ha definidoNomad como un servicio de Consul y asiacute poder definir la direccioacuten de losservidores como un nombre de dominio no por su direccioacuten fiacutesica que elservidor DNS de Consul se encargaraacute de resolver
Por defecto Nomad usa los siguientes puertos
API HTTP 4646 Peticiones HTTP y recepcioacuten de oacuterdenes mediante laliacutenea de comandos
RPC 4647 Protocolo de consenso entre los nodos del cluster
Serf 4648 Protocolo de gossip entre los servidores de los centros de datosgobernados por Nomad
35
Los dos uacuteltimos deben ser interfaces alcanzables por otros nodos sin embargo laAPI HTTP por motivos de seguridad deberiacutea ser local ya que en caso contrariocualquier persona con acceso a ella tiene el control sobre la herramienta Eacutestasolo deberiacutea estar accesible en un servidor o gestionarlo mediante una terminalSSH por ejemplo En este trabajo al ser una prueba de concepto se ha abiertoen todos los nodos
Trabajos de Nomad
Las tareas se detallan en ficheros con formato HashiCorp Configuration Lan-guage un derivado del formato JSON creado por la empresa que le da nombrecompatible con eacuteste y que permite comentarios
En estos ficheros se puede definir
La regioacuten y el centro de datos donde se ejecutaraacute (Nomad permite lagestioacuten de centros de datos geograacuteficamente distribuidos en regiones)
La poliacutetica de actualizacioacuten de la tarea
Grupo de tareas esto es que se ejecutaraacuten en el mismo nodo
El nuacutemero de grupos a ejecutarescalar asiacute como los liacutemite que debencumplir los nodos asignados
La poliacutetica de reinicio ante fallo o error
Tareas El controlador su configuracioacuten los paraacutemetros del servicio aso-ciado a registrar en Consul asiacute como los recursos que consume (puertosmemoria)
En nuestro caso usamos sobre todo el controlador Docker esto eso orques-tacioacuten de contenedores en los nodos clientes y tres de sus opciones
Imagen del contenedor Se han subido todas las imaacutegenes del proyecto a Doc-ker Hub donde por defecto se busca la imagen
Puertos Los puertos a usar por el contenedor que pueden ser estaacuteticos asigna-dos por el usuario o dinaacutemicos siendo Nomad el que se encarga de mapearun puerto libre del nodo cliente al expuesto por el contenedor
Servidores DNS Como usamos la interfaz DNS de Consul como descubri-miento de servicio se debe configurar el contenedor para que use cualquiernodo del cluster como servidor DNS
Configuracioacuten Consul
Al ser desarrolladas por la misma empresa los ficheros de configuracioacuten deConsul y Nomad comparten muchas opciones Consul tambieacuten acepta peticionesa traveacutes de una interfaz de red siendo los puertos usados por defecto
36
RPC 8300 8400 Maneja la peticiones del resto de nodos y usuarios
Serf 8301 8302 Protocolo gossip
HTTP API 8500
HTTPS API Desactivada por defecto
Interfaz DNS 8600
Se debe asignar a los protocolos internos del cluster esto es RPC y Serf unainterfaz alcanzable por los nodos y por el contrarioasignar a los dos uacuteltimos ala interfaz de loopback por motivos de seguridad
Cabe destacar que Consul tambieacuten cuenta con una interfaz graacutefica que per-mite ver el estado de los equipos y los servicios registrados y que se encuentra enel mismo puerto que la API HTTP en la direccioacuten httpIP_EQUIPO8500ui
Ejecucioacuten
Tanto Nomad como Consul requieren de la ejecucioacuten de un fichero en todoslos nodos integrantes del cluster Como prueba de concepto se ha decidido usardos servidores para ambos aunque cabe matizar que es un nuacutemero ineficienteya que la caiacuteda de uno de ellos supondriacutea la peacuterdida del cuoacuterum y por tantodel consenso del cluster
En primer lugar se arrancan los servidores que son los encargados de ejecu-tar el protocolo de consenso y gestionar el cluster y a continuacioacuten los clientesque no tienen praacutecticamente estado y dependen de los servidores
En el caso de Consul se debe indicar el directorio donde se guardan losficheros que describen los servicios asiacute como el archivo que especifica el resto delas opciones
1 Se inicia el primer servidor en uno de los equipos
$ consu l agent minuscon f i gminusd i r e t c consu l d s e r v i c e s minuscon f i gminus f i l e consu l_server j son
2 Los siguientes equipos deben unirse al anterior por lo que antildeadimos elargumento join con la direccioacuten del primer servidor Para el caso de otrosservidores
$ consu l agent minuscon f i gminusd i r e t c consu l d s e r v i c e s minuscon f i gminus f i l e consu l_server j son minus j o i n ltIP_servidor1gt
37
Una vez los servidores han alcanzado el consenso y elegido un liacuteder en losclientes
$ consu l agent minuscon f i gminusd i r e t c consu l d s e r v i c e s minuscon f i gminus f i l e c on su l_c l i en t j son minus j o i n ltIP_cualquierServ idorgt
El proceso para iniciar Nomad es igual y los comandos similares sin embargoya no es necesario indicar una direccioacuten IP fija en los equipos sino el nombre dedominio del servicio de Nomad registrado por Consul En el primer servidor
$ nomad agent minusc on f i g nomad_server j son
Y el resto de equipos (con su fichero de configuracioacuten correspondiente)$ nomad agent minusc on f i g nomad_server j son minus j o i n nomad s e r v i c e consu l
Por uacuteltimo para desplegar la aplicacioacuten web se han escrito tres ficherosque detallan las tareas de la interfaz web API y los balanceadores de cargaMediante la CLI
$ nomad run minusaddress=http lt ip_c lus te r gt4646 lt f i l e hclgt
O mediante la API HTTP de Nomad$ cu r l minusX POST minusd ltf i l e hclgthttp lt ip_c lus te r gt4646 jobltjob_namegt
Ansible
Como se puede comprobar con el aumento del nuacutemero de equipos pasa aser inviable manejar todos los nodos a traveacutes de terminal Ademaacutes como seha comentado con anterioridad Nomad requiere que en los nodos clientes es-teacuten instalados las herramientas que soporten las tareas por ejemplo el motorde Docker Por ello para facilitar tanto el arranque como la instalacioacuten de lasdependencias vamos a usar Ansible una herramienta de coacutedigo abierto desarro-llada en Python que permite gestionar configuraciones aprovisionar recursosdespliegue de aplicaciones de forma automaacutetica
A grandes rasgos esta herramienta funciona mediante ficheros en formatoYAML denominados play-books que describen un conjunto de pasos a ejecutaren una lista de equipos remotos Estos pasos son ejecutados por moacutedulos inde-pendientes a traveacutes de SSH es decir en cualquier ordenador con conexioacuten a los
38
hosts dado su contrasentildea o clave puacuteblica puede arrancar el script y realizariacutealos pasos de forma remota gestionando el cluster desde un solo equipo
Se han desarrollado guiones para lo siguiente
Descarga de los binarios de Nomad y Consul en todos los nodos copiade los ficheros de configuracioacuten baacutesicos y modificarlos de acuerdo a cadanodo (nombre del equipo direccioacuten IP)
Instalacioacuten de las dependencias
Arranque de Nomad y Consul
Ansible extiende su funcionalidad a traveacutes de moacutedulos independientes que per-miten por ejemplo instalar paquetes mediante herramientas de gestioacuten de pa-quetes (APT yum) aprovisionar automaacuteticamente maacutequinas virtuales de Ama-zon EC2
Algunas opciones de los ficheros de configuracioacuten de Nomad y Consul sondependientes del nodo particular por ejemplo la interfaz de red Para estetrabajo se ha realizado un moacutedulo para modificar los ficheros de configuracioacutende forma automaacutetica En el repositorio del proyecto se encuentra una carpetadonde se encuentran todos los ficheros necesarios para desplegar un clustertotalmente funcional solo requiere de una liacutenea de terminal con Ansible
$ ans ib l eminusplaybook minus i hos t s minusk ltssh_passgt minusu ltnode_usergt s i t e yml
39
62 Servicio de integracioacuten continua
Se ha implementado un sistema de integracioacuten continua que permite ejecu-tar tareas de compilacioacuten y pruebas de forma distribuida aumentando asiacute elrendimiento de los equipos En primer lugar se detallaraacute los motivos por los quepuede resultar beneficioso para las empresas una implementacioacuten de este tipo alo que seguiraacute los detalles del despliegue
621 DevOps
Metodologiacutea que defiende la comunicacioacuten y colaboracioacuten entre desarrolla-dores de software y los profesionales de operaciones a lo largo de todo el ciclo devida de una aplicacioacuten Estaacute muy relacionado con el desarrollo aacutegil de softwareesto es un enfoque para los proyectos que defiende el desarrollo iterativo e in-cremental donde los requisitos y soluciones evolucionan con el tiempo seguacuten lanecesidad del proyecto DevOps extiende esta filosofiacutea a todas los componentesde un servicio incluyendo sistemas y operaciones
Se trata de un concepto que cada organizacioacuten o empresa adapta a suspropias necesidades y procesos de negocio en este proyecto nos vamos a centraren la integracioacuten continua una praacutectica fundamental tanto del desarrollo aacutegilcomo de esta filosofiacutea
622 Integracioacuten Continua
Se define como una praacutectica de desarrollo software donde los miembros delequipo ponen en comuacuten su trabajo frecuentemente al menos una vez al diacutea21Cada integracioacuten se verifica con una compilacioacuten automaacutetica que incluye laejecucioacuten de pruebas para detectar errores de integracioacuten tan pronto como seaposible
Desde el punto de vista operativo esto supone automatizar la configuracioacutende equipos o el despliegue de maacutequinas virtuales donde compilar el proyecto yejecutar las pruebas y posteriormente eliminarlas Este flujo de trabajo se vebeneficiado en entornos distribuidos ya que el objetivo del desarrollador es com-probar el resultado de las pruebas raacutepidamente sin preocuparse del despliegueo los propios equipos
Para esta prueba de concepto vamos a usar Jenkins un servidor de integra-cioacuten continua escrito en Java que nos permite definir trabajos que contendraacutenla descripcioacuten tanto del entorno como su ejecucioacuten
Este sigue una estructura maestro-esclavo muy similar al de los gestores declusters usados en este proyecto el maestro contiene toda la loacutegica del servicio
21httpmartinfowlercomarticlescontinuousIntegrationhtml
40
trabajos autenticacioacuten y los esclavos son los encargados de la ejecucioacuten ensiacute Jenkins tiene varias viacuteas para aprovisionar los uacuteltimos
Mediante SSH
Interfaz graacutefica
Desarrollar un script propio
Ejecucioacuten de un fichero java
La ventaja de usar planificadores es que el despliegue de esclavos es dinaacutemicoes decir no tener una maacutequina especiacuteficamente configurada para ello DCOS yNomad se encargaraacuten de configurar estos despliegues en sus maacutequinas y poste-riormente eliminarlos Para ello se ha usado la uacuteltima opcioacuten definiendo tareasque descarguen el fichero java Con todo ello se consigue un entorno de inte-gracioacuten continua eficiente que ademaacutes permite la ejecucioacuten de otros servicios deforma independiente
Jenkins permite la creacioacuten de plugins que extienden sus funcionalidadesTanto Nomad22 como Apache Mesos cuentan con uno que permite su integra-cioacuten
Para esta prueba se va a usar el mismo proyecto que para el caso de usode orquestacioacuten de contenedores la aplicacioacuten web al que se le ha antildeadido untest para comprobar que se conecta correctamente a la base de datos medianteMocha un framework de Nodejs Por otro lado se antildeade el plugin de git ya queel coacutedigo se obtiene de GitHub el repositorio remoto de control de versiones delproyecto
El proceso general de ejecucioacuten seriacutea como sigue
1 Se ejecuta el maestro de Jenkins como tarea Docker partiendo de la imagenoficial
2 Al arrancar un trabajo se manda una tarea a los planificadores que laasignaraacuten a un nodo cliente Esta tarea consiste en la descarga del ficherode configuracioacuten Java y arrancarlo configurando el equipo como un clientede Jenkins temporalmente
3 Jenkins ejecuta el trabajo en el nuevo cliente en este caso iniciar la apli-cacioacuten web iniciar las pruebas y generar un informe
4 Se elimina el cliente
A continuacioacuten se detallan los matices de cada herramienta a la hora de imple-mentar este servicio
22Desarrollado por Ivo Verberk httpwwwivoverberknl
41
623 Jenkins con Nomad
El plugin permite la ejecucioacuten del fichero Java mediante dos controladorescontenedores Docker y Java En este proyecto nos hemos decantado por el pri-mero ya que nos ahorra instalar la maacutequina virtual de java en todos los nodoscliente Por ello se ha construido un contenedor base con Java para la ejecucioacutendel fichero de configuracioacuten y Nodejs para lanzar la aplicacioacuten web
El plugin se configura con la direccioacuten IP del cluster y el contenedor queejecuta el esclavo Jenkins Por su parte el trabajo en Jenkins se define conel repositorio en GitHub donde se aloja el coacutedigo del proyecto a probar y loscomandos a ejecutar en este caso npm update y npm test
624 Jenkins con DCOS
En el caso de DCOS su sistema de paquetes incluye Jenkins por lo queal instalarlo ya se tiene la configuracioacuten de Mesos totalmente funcional Sinembargo para ejecutar la aplicacioacuten en particular y las pruebas se requiere deNodejs en los equipos esclavos por ello debemos antildeadir un plugin de Jenkinsque permite instalar este entorno antes de ejecutar el trabajo Una vez hechoesto soacutelo queda definir la tarea igual que en el caso anterior
Cabe destacar que Mesosphere tambieacuten ha desarrollado un plugin que per-mite hacer despliegues en Marathon de tal manera que permitiriacutea con cadacommit del coacutedigo compilar la imagen del contenedor Docker y desplegarlaautomaacuteticamente aunque en este proyecto no se ha hecho pruebas de esta fun-cionalidad
42
7 Escalando la infraestructura
Uno de los factores clave que se busca a la hora de implementar sistemasdistribuidos es el poder escalar la infraestructura de forma maacutes sencilla estoes detectar que las maacutequinas estaacuten alcanzando el liacutemite de su capacidad yaumentar eacutesta ya sea mejorando sus caracteriacutesticas teacutecnicas o antildeadiendo maacutesnodos al cluster
El coacutedigo y todos los ficheros de configuracioacuten de esta seccioacuten tambieacuten sepueden encontrar en el repositorio del proyecto en GitHub23
71 Disentildeo
Microsoft Azure permite organizar los servicios cloud de forma loacutegica a traveacutesde grupos de recursos y asiacute poder crear o eliminar eacutestos en conjunto parauna aplicacioacuten determinada (por ejemplo una aplicacioacuten web suele requerir demaacutequinas virtuales bases de datos almacenamiento) Ademaacutes dispone dela opcioacuten de crear plantillas en formato JSON que permite al desarrolladordefinir los recursos y su interrelacioacuten para desplegar de forma automaacutetica unainfraestructura TI en la nube
Azure tambieacuten ofrece la posibilidad de monitorizar el estado de las maacutequinasvirtuales a traveacutes de extensiones lo que permite configurar el escalado automaacute-tico al alcanzar cierto liacutemite definido por el operador Eacutesta es a priori la formaen que deberiacutea implementarse hablando en teacuterminos de eficiencia sin embargoesta aproximacioacuten es totalmente dependiente de la plataforma es decir no sepuede extrapolar a otro proveedor o sobre recursos propios sin realizar un nue-vo disentildeo En este proyecto las tareas que son ejecutadas por estos equipos notienen estado ya que todo lo relativo a la persistencia lo hemos asignado fueradel cluster esto permite escalar la plataforma a traveacutes de otra aproximaciones
Las plantillas aceptan una serie de variables a indicar por el usuario entreotras los conjuntos de escala para definir los nodos aceptan una variable quedefine el nuacutemero de maacutequinas que los componen Por otro lado Azure ofreceuna API REST y kits de desarrollo software (SDK por sus siglas en ingleacutes) quepermiten su despliegue de forma programaacutetica Aprovechando estas facilidadesen este proyecto se va a aproximar la escalabilidad con el sucesivo desplieguede la infraestructura de forma automaacutetica se monitorizan los equipos y si sedetecta una maacutequina excesivamente cargada se aumenta el nuacutemero de equiposen la plantilla y se vuelve a desplegar
23httpsgithubcomAntonioAlfrzCloud-Orchestrators
43
En este proyecto se han disentildeado las plantillas para desplegar la arquitec-tura necesaria tanto de Nomad como de DCOS En el caso de la primera eldespliegue es maacutes descriptivo ya que incluye maacutequinas virtuales grupos de se-guridad redes En el caso de DCOS Azure cuenta con un servicio especiacuteficopara clusters gobernados por DCOS denominado Azure Container Service queincluye los componentes necesarios y la instalacioacuten ya realizada
72 Implementacioacuten
En primer lugar para monitorizar el estado de los equipos se va a usar laherramienta Nagios un sistema que permite controlar el estado del hardwarey los servicios de un equipo Se trata de una herramienta muy completa de laque se va a usar su capacidad para ejecutar comandos (plugins) en los nodospara detectar picos de carga generar alertas y ejecutar programas para estoseventos
Se ha desplegado una maacutequina virtual con esta herramienta en ambos siste-mas y se ha instalado una extensioacuten de Nagios (Nagios Remote Plugin Executor)en todos los nodos que permite ejecutar comprobaciones remotamente en con-creto para esta prueba de concepto medir el nivel de saturacioacuten de la unidadcentral de procesamiento (CPU por sus siglas del ingleacutes) Cuando sucede uncambio de estado de una maacutequina esto es cuando este paraacutemetro supera el liacutemi-te definido por el operador Nagios permite actuar en consecuencia ejecutandoprogramas por ello se ha desarrollado un script que ejecuta lo siguiente
Un programa desarrollado en Python con el SDK de Azure que modificalas plantillas y despliega los recursos
Un guioacuten de Ansible para instalar todos los componentes necesarios en lasnuevas maacutequinas y arrancar de nuevo el cluster y las aplicaciones
44
8 Resultados y conclusiones
En este uacuteltimo apartado se da una visioacuten global del proyecto asiacute como a lasconclusiones maacutes importantes a las que se ha llegado y posibles temas futurosde desarrollo
81 Comparacioacuten
Ambas herramientas ofrecen las funcionalidades para gestionar los recursoseficientemente ofreciendo a los desarrolladores una plataforma donde desplegarsus aplicaciones de forma distribuida independientemente de los equipos fiacutesicosy el hardware que las soporten
DCOS es una herramienta que en un comienzo fue privativa pero cuyos res-ponsables la empresa Mesosphere decidieron publicar una versioacuten de coacutedigoEacutesta nos permite gestionar un cluster de una forma sencilla y usable ademaacutes decomplementarlo con otras herramientas como el balanceador de carga integradoo la autenticacioacuten de usuarios ademaacutes estaacute basada en Apache Mesos un pro-yecto de relativa madurez y con el soporte de la Apache Software FoundationDe forma resumida DCOS ofrece muchas posibilidades y servicios a cambiode una arquitectura e instalacioacuten maacutes compleja
Por su parte HashiCorp con menor tiempo de desarrollo ha conseguidouna herramienta muy sencilla de desplegar que ademaacutes cumple con todas lasfuncionalidades baacutesicas ejecutando un simple binario en cada nodo se puededesplegar un gestor de clusters totalmente funcional Sin embargo no cuentacon todas las posibilidades de Mesos (Nomad cuenta con menos controladoresque entornos posibles de Mesos) ni con los antildeadidos de DCOS lo que implicael uso de otras herramientas para complementar el servicio (Consul HAProxy)
De entre las dificultades encontradas al usar estas herramientas y desplegaraplicaciones sobre ellas se puede destacar la depuracioacuten en ocasiones se desco-noce si un error viene de la propia herramienta de la aplicacioacuten desplegada o delequipo fiacutesico si no se cuenta con un sistema de procesamiento de registro unose puede encontrar con muacuteltiples terminales abiertas inspeccionando numerososficheros de registro buscando posibles errores Ademaacutes no dejan de ser solucio-nes que para usar eficientemente se debe conocer parte de su funcionamientoy sintaxis a la hora de describir la tareas lo que supone un esfuerzo antildeadido yaque cada una tiene sus particularidades y liacutemites
45
82 Conclusiones
En una sociedad cada vez maacutes digital las empresas deben adaptarse a unmercado cuya demanda de contenido no deja de crecer Las nuevas arquitecturascomo microservicios asiacute como la gran cantidad de datos generada implica queuna mejor gestioacuten de los recursos y la rapidez para desplegar o escalar solucionesdando valor al cliente lo maacutes raacutepido posible es uno de los objetivos de todas lasempresas de base tecnoloacutegica
Las ventajas que ofrecen los planificadores con aplicaciones distribuidas sonnumerosas sin ir maacutes lejos empresas tan punteras como Google llevan maacutesde 10 antildeos orquestando contenedores24 Por un lado permiten aumentar elrendimiento de los equipos propios y por otro implementar un servicio comoplataforma para despliegues distribuidos sobre cualquier conjunto hardware deesta forma se provee un servicio similar al de la nube puacuteblica pero con laprincipal diferencia de que se elimina la independencia con el proveedor (vendorlock-in) esto es las aplicaciones no tienen limitaciones impuestas por eacuteste talescomo lenguaje de programacioacuten o herramientas y permite despliegues hiacutebridosentre recursos propios y la nube
83 Objetivos conseguidos
Implementacioacuten de los planificadores propuestos en la nube Se ha en-tendido y detallado el funcionamiento de estas herramientas y se hanimplementado en el servicio de infraestructura de Microsoft Azure
Despliegue de aplicaciones y servicios distribuidos Servicios que se usanactualmente en la industria del desarrollo software asiacute como una aplica-cioacuten web con una arquitectura moderna han sido desplegados de formadistribuida en los equipos cumpliendo con la funcionalidad esperada ade-maacutes de consiguiendo una alta disponibilidad
Aproximacioacuten de arquitectura escalable Se ha hecho una aproximacioacutende infraestructura escalable de forma que sea parcialmente extrapolable aotros proveedores
24httpwwwnextplatformcom20160322decade-container-control-google
46
84 Liacuteneas de investigacioacuten
Siguiendo con la materia de este proyecto se presentan posibles liacuteneas deinvestigacioacuten
Analizar el despliegue con estas herramientas de aplicaciones de Big Datay comparar la eficiencia con respecto a soluciones especializadas
Analizar el rendimiento de los algoritmos de planificacioacuten antes pruebasde estreacutes y situaciones de alta contienda
Comparar el uso de estas herramientas con las praacutecticas actuales de laindustria o implementacioacuten en un sistema de produccioacuten real
47
Referencias
[1] LA Barroso y U Houmllzle laquoThe Datacenter as a Computer An Introduc-tion to the Design of Warehouse-Scale Machinesraquo En Morgan amp ClaypoolPublishers ()
[2] Systems Research Group ndash NetOS (University of Cambridge) The evolu-tion of cluster scheduler architectures 2016 url httpswwwclcamacukresearchsrgnetoscamsasblog2016-03-09-scheduler-architectureshtml
[3] A Das I Gupta y A Motivala SWIM Scalable Weakly-consistent Infection-style Process Group Membership Protocol Inf teacutec Dept of ComputerScience Cornell University url https www cs cornell edu ~asdasresearchdsn02-swimpdf
[4] D Dubhashi y A Das Mastering Mesos PACKT Publishing mayo de2016
[5] The Apache Software Foundation Apache Mesos documentation urlhttpsmesosapacheorg
[6] David Greenberg Building Applications on Mesos OrsquoReilly Media 2016[7] Armand Grillet Comparison of Container Schedulers Inf teacutec Technische
Universitaumlt Berlin[8] HashiCorp Consul documentation url httpswwwconsulio[9] HashiCorp Nomad documentation url httpsdcosio[10] Dan C Marinescu Cloud computing theory and practice Morgan Kauf-
mann 2013[11] Mesosphere DCOS documentation url httpswwwnomadproject
io[12] Microsoft Azure documentation url httpsazuremicrosoftcom
es-esdocumentation[13] D Ongaro y J Ousterhout In Search of an Understandable Consensus
Algorithm Inf teacutec Stanford University url httpsraftgithubioraftpdf
[14] Fei Teng laquoRessource allocation and schelduling models for cloud compu-tingraquo Tesis de mtriacutea Ecole Centrale Paris 2011
[15] A Williams y col Automation and Orchestration with Docker and Contai-ners A Comprehensive Overview of the Docker and Container Ecosystem3 The New Stack 2016
48
- Resumen
- Summary
- Iacutendice de figuras
- Introduccioacuten y objetivos
-
- Contexto
- Objetivos
- Estructura del documento
-
- Cloud Computing
- Nuevas cargas de trabajo
- Gestioacuten de recursos Planificadores
-
- Sistemas distribuidos
-
- Clasificacioacuten
-
- Herramientas
-
- DCOS
-
- Apache Mesos
- Ejemplos de uso
-
- Nomad
-
- Protocolo de consenso Raft
- Protocolo gossip SWIM
- Planificacioacuten
-
- Casos de uso y despliegue
-
- Aplicacioacuten Web
-
- DCOS
- Nomad
-
- Servicio de integracioacuten continua
-
- DevOps
- Integracioacuten Continua
- Jenkins con Nomad
- Jenkins con DCOS
-
- Escalando la infraestructura
-
- Disentildeo
- Implementacioacuten
-
- Resultados y conclusiones
-
- Comparacioacuten
- Conclusiones
- Objetivos conseguidos
- Liacuteneas de investigacioacuten
-
6 Casos de uso y despliegue
Con el objetivo de mostrar las posibles utilidades que este tipo de sistemaspueden tener en las infraestructuras TI actuales se han desplegado las dos he-rramientas en la nube Microsoft Azure usando su servicio cloud de instancias demaacutequinas virtuales Linux para simular un conjunto de ordenadores conectadosentre siacute por una red LAN Sobre ellas se ha implementado dos casos de usouna aplicacioacuten web con una arquitectura con cierta orientacioacuten a microserviciosy un sistema de integracioacuten continua
El coacutedigo y todos los ficheros de configuracioacuten se pueden encontrar en elrepositorio del proyecto en GitHub16
61 Aplicacioacuten Web
Se busca simular el proceso de adaptacioacuten de una solucioacuten web para su des-pliegue en un sistema distribuido con las herramientas anteriormente descritascon el objetivo de aumentar tanto su escalabilidad como disponibilidad medianteredundancia
Se ha partido de una aplicacioacuten ya existente17 un servicio de almacenamien-to y reproduccioacuten de canciones A grandes rasgos este servicio permite crearusuarios subir canciones con sus respectivas portadas tener playlists propias yescuchar las canciones a traveacutes de un navegador web
La solucioacuten estaacute dividida en 4 partes (figura 17)
Una vista web con la loacutegica
Un almacenamiento conectado en red (NAS por sus siglas en ingleacutes)
Una API REST para gestionar las peticiones al almacenamiento
Base de datos NoSQL basada en MongoDB
La nueva tendencia de los proyectos web es su implementacioacuten en contene-dores Docker ya que facilitan su portabilidad y ofrecen un procedimiento dedespliegue raacutepido sobre todo a la hora de desarrollar y realizar pruebas en en-tornos de produccioacuten simulados Por ello en este caso se va a hacer uso de los
16httpsgithubcomAntonioAlfrzCloud-Orchestrators17httpsgithubcomsonsoleslpCDPSfy
27
motores de orquestacioacuten de contenedores de ambas herramientas Marathon enDCOS y el controlador Docker en el caso de Nomad
Figura 17 Arquitectura aplicacioacuten web
A continuacioacuten vamos detallar el despliegue en ambas herramientas de es-ta solucioacuten y observar tanto queacute dificultades se encuentran como que ventajasofrecen El objetivo final es adaptar el proyecto modificaacutendolo lo menos posiblecon objeto de analizar la capacidad de estas herramientas para desplegar cual-quier aplicacioacuten sin que eso conlleve la modificacioacuten de la arquitectura de eacutestaes decir que no sea dependiente del entorno
611 DCOS
Se ha descrito DCOS como una herramienta que se despliega sobre un con-junto de ordenadores y que permite instalar gestionar el despliegue de sistemasdistribuidos
Microsoft Azure cuenta con una plantilla para desplegar en su servicio cloudun cluster de maacutequinas virtuales con DCOS ya instalado que cuenta con
Maacutequinas maestras (1 3 o 5 a seleccionar por el usuario) configuradascomo un conjunto de disponibilidad esto eso Azure da ciertas garantiacuteasde que al menos una maacutequina estaraacute en funcionamiento
Maacutequinas agentes Por motivos de seguridad se distinguen dos roles
bull Nodos privados solo accesibles desde la red interna y configuradoscomo un conjunto de escala un recurso de Azure para gestionar ydesplegar maacutequinas con configuraciones ideacutenticas para permitir unraacutepido escalado
bull Un equipo conectado accesible desde Internet a travntildees de un balan-ceador de carga puacuteblico y situado en una subred externa
28
Dos balanceadores de carga
bull La interfaz puacuteblica del cluster que se conecta con el cliente puacuteblicobull Acceso a los equipos maestros para el administrador que soacutelo permiteconexioacuten mediante SSH y credenciales
Almacenamiento para todas las maacutequinas
Configuraciones necesarias de red y seguridad
En la figura 18 se observa un diagrama de la infraestructura
Figura 18 Infraestructura en Azure
El primer obstaacuteculo es la persistencia de estado de la aplicacioacuten que seconsigue gracias a una base de datos no relacional basada en MongoDB asiacutecomo el almacenamiento de las canciones Para implementarla tenemos variasposibilidades
Montar un sistema externo de almacenamiento conectado en red en todoslos agentes donde se ejecuten las tareas de esta manera si una tarea pasade un nodo a otro por cualquier motivo puede tener acceso a los mismosficheros (opcioacuten del caso de uso original)
Implementar un sistema de ficheros distribuidos en los agentes
Usar los servicios de almacenamiento de las nubes puacuteblicas
Aprovechar el sistema de voluacutemenes persistentes de Apache Mesos Eacutestepermite reservar recursos de un agente de forma que al arrancar una tarease crea un volumen independiente del ciclo de vida de eacutesta con ello esosrecursos donde se ha almacenado la informacioacuten pueden volver a ofrecerseal mismo entorno de tal manera que otra tarea pueda acceder a ella
DCOS aprovecha este sistema de voluacutemenes persistentes y permite instalarbases de datos distribuidas como ArangoDB o Apache Cassandra sin embargoesto implicariacutea modificar todo el coacutedigo referente al modelo de la base de datos
29
Por motivos de eficiencia y latencia asiacute como de una mayor gobernabilidadde los datos la mejor opcioacuten es usar el recurso de voluacutemenes persistentes queofrece Apache Mesos ya que de esta manera se gestionariacutea la aplicacioacuten completamediante una uacutenica herramienta Sin embargo esto implica que la informacioacutense encuentra exclusivamente en el agente donde se haya ejecutado la tarea y porlo tanto se sigue requiriendo de software externo para distribuir la informacioacutenpara que se accesible para todos los agentes A la hora de realizar este proyectose encontraba en desarrollo Flocker una solucioacuten desarrollada por ClusterHQque permite compartir los voluacutemenes de Docker a traveacutes de un cluster quesi bien es compatible con el planificador de Mesos el proyecto se encontrabatodaviacutea en fases tempranas de desarrollo y los sistemas de almacenamiento quesoporta quedaban fuera del aacutembito de este trabajo
Por todo ello dado que las maacutequinas se han desplegado en la nube puacuteblicade Azure se decidioacute usar su servicio de almacenamiento de objetos para lascanciones y otra maacutequina para desplegar MongoDB y asiacute mantener el modelode datos original de la aplicacioacuten La diferencia del almacenamiento de obje-tos con respecto a nivel de fichero es que el primero no tiene jerarquiacutea paraorganizar los archivos eacutestos se guardan como objetos (con sus metadatos) enun mismo espacio soacutelo diferenciaacutendose por un identificador uacutenico esto implicaentre otras cosas que se puede acceder a un fichero dado uacutenicamente su IDindependientemente de la localizacioacuten fiacutesica de eacuteste facilitando pues la gestioacuteny el desarrollo
El coacutedigo del proyecto se ha modificado en los siguientes apartados
Las direcciones de la base de datos y los balanceadores de carga asiacute comosus puertos estaban originalmente fijos Se han configurado como variablesde entorno para facilitar el descubrimiento del servicio y hacer transpa-rente la aplicacioacuten al entorno de despliegue
La API REST se ha adaptado al almacenamiento en Azure en vez de enlocal
Estas modificaciones no suponen un cambio sustancial pero permiten separala persistencia de las tareas ejecutadas por DCOS lo que facilita en granmedida su ejecucioacuten al ser totalmente sin estado y ademaacutes implican tenerlos datos bajo un mayor control
Para la orquestacioacuten de contenedores se va a usar el entorno Marathondesarrollado tambieacuten por Mesosphere Eacuteste se puede usar a traveacutes de una interfazgraacutefica la interfaz de liacutenea de comandos (en lo que sigue CLI por sus siglas eningleacutes) de DCOS o con su API HTTP
Primero se han publicado la imaacutegenes de los contenedores que encapsulanla interfaz web y la api de la aplicacioacuten en el repositorio puacuteblico DockerHub
Los despliegues en este entorno se describen mediante ficheros JSON en losque se detalla entre otras opciones la imagen del contenedor los puertos a usar
30
los recursos que debe ocupar en un nodo o las instrucciones de monitorizacioacuten
Para el servicio de descubrimiento DCOS ofrece la posibilidad de asignardirecciones IP virtuales (VIP por sus siglas en ingleacutes) a tareas que se compartenen todos los nodos DCOS lleva integrado un balanceador de carga a nivel TCP(el componente denominado Minuteman) que balancea entre las direccionesvirtuales de las tareas y todas las instancias de eacutestas a lo largo del cluster Estoes necesario por dos motivos equilibrar la carga de los equipos con el fin deevitar un punto de uacutenico fallo mediante redundancia y evitar la contienda dedirecciones al ejecutar las tareas en puertos aleatorios
Este balanceador de carga estaacute basado en el trabajo de Michael Mitzenma-cher The Power of Two Choices in Randomized Load Balancing18 A grandesrasgos el algoritmo mantiene una media moacutevil exponencial de latencias paracada destino (backend) ademaacutes de las caiacutedas consecutivas Si un destino noresponde a una negociacioacuten en tres pasos (three way handshake) de forma con-secutiva en un periodo inferior a 5 ms se considera caiacutedo El algoritmo iterasobre los destinos disponibles en base a su histoacuterico de fallos y escoge dos deforma aleatoria de los cuales coge el de mejor meacutetrica
Las direcciones virtuales soacutelo se pueden resolver dentro del cluster porello para implementar la interfaz puacuteblica de la aplicacioacuten esto es el balancea-dor de carga de la interfaz web usaremos un paquete de DCOS denominadomarathon-lb un balanceador basado en HAProxy y adaptado por MesosphereEn este caso equilibra la carga de todas instancias de las tareas ejecutadas porel entorno Marathon por sus etiquetas y permite ademaacutes definir como puntode entrada muacuteltiples hosts virtuales definidos por sus nombres completos dedominio (FQDN por sus siglas en ingleacutes) en nuestro caso la interfaz puacuteblicadel balanceador de Azure para los agentes
Por motivos de seguridad todas las tareas se ejecutan en los agentes privadoses decir los que son exclusivamente accesibles desde la red interna Por su partemarathon-lb se ejecuta en el agente puacuteblico que cuenta con IP puacuteblica y lospuertos 80 (HTTP) y 8080 abiertos de forma que la aplicacioacuten sea accesibledesde Internet Esto es posible debido a que Apache Mesos permite reservarrecursos mediante roles asignados a nodos para un uso especiacutefico De esta formala arquitectura vista desde la aplicacioacuten quedariacutea como en la figura 19
18httpswwweecsharvardedu~michaelmpostscriptstpds2001pdf
31
Figura 19 Arquitectura de la aplicacioacuten web en DCOS
Ejecucioacuten
A la hora de desplegar la aplicacioacuten DCOS puede gestionarse medianteuna interfaz graacutefica o una interfaz de liacutenea de comandos La primera se accedea traveacutes de un navegador web en el puerto 80 (HTTP) y permite instalar losentornos disponibles observar el estado de los nodos y las tareas que se estaacutenejecutando y los ficheros de registros que eacutestas generan
La CLI permite el control desde un nodo o una maacutequina remota (suponiendoque los maestros tienen IP puacuteblica y el puerto 80 abierto) ya que DCOS tieneun sistema de autorizacioacuten que permite tener una interfaz puacuteblica con ciertasgarantiacuteas de seguridad
Por su parte cada entorno de trabajo puede ser controlado por la CLI peroademaacutes cuenta con sus propias interfaces Marathon expone una API HTTPen el puerto 8080 de la direccioacuten puacuteblica de los maestros del cluster asiacute comootra interfaz graacutefica Para desplegar un contenedor se podriacutea usar la CLI
$ dcos marathon app add lt f i l e j songt
O la API HTTP
$ cu r l minusX POST http lt ip_maestro gt8080v2apps minusd ltf i l e jsongt minusH Contentminustype app l i c a t i o n j son
32
612 Nomad
La arquitectura de Nomad es maacutes sencilla ya que solo requiere de un ficheroejecutable en todos los nodos para funcionar Si DCOS es la base de instala-cioacuten de entornos de terceros Nomad integra todas las funcionalidades baacutesicasesto es gestor de recursos planificador y ejecutor en los nodos cliente Estaherramienta cuenta con un menor tiempo de desarrollo y en el momento deescribir este documento cuenta exclusivamente con los siguientes controladoresen comparacioacuten con los entornos de DCOS
Motor Docker es decir funcioacuten de orquestacioacuten de contenedores
Ejecucioacuten de archivos binarios como comandos de Shell
Ejecucioacuten de aplicaciones Java
Virtualizacioacuten de maacutequinas mediante tecnologiacutea QEMU
Todos ellos necesitan que la tecnologiacutea subyacente esteacute instalada en las maacute-quinas clientes (Docker Java QEMU) Actualmente no permite el registro decontroladores por parte de terceros aunque estaacute planificado en un futuro ofreceruna interfaz para su desarrollo
Nomad no cuenta con el servicio de descubrimiento sin embargo puede inte-grarse con la herramienta Consul desarrollada por la misma empresa Por otrolado para el balanceo de carga usaremos un contenedor Docker con HAProxyuna herramienta de coacutedigo abierto que ofrece tanto servicios de proxy como debalanceador y cuyos ficheros de configuracioacuten completaremos con el proyectoConsul Template19
Consul
Consul sigue la misma arquitectura que Nomad es decir un nodo servidorque orquesta un conjunto de maacutequinas clientes y permite a los procesos que seejecutan en los equipos definirlos como servicios ofreciendo diversas caracteriacutes-ticas entorno a estos de los cuales vamos a usar dos
Descubrimiento de servicio Las maacutequinas clientes publican en el cataacutelogode servicios las tareas en ejecucioacuten y Consul les asigna nombres de dominioaccesibles por todos los miembros del cluster a traveacutes de la interfaz DNSincluida en esta herramientaConsul se integra con Nomad de forma que todas las tareas que se ejecu-ten en la segunda son automaacuteticamente publicados como servicios de laprimera de esta manera no hace falta conocer la direccioacuten de la maacutequinacliente donde se esteacute ejecutando el proceso ya que se puede acceder a eacutela traveacutes de su nombre de dominio de forma transparente Por ejemplo si
19[httpsgithubcomhashicorpconsul-template]
33
ejecutamos una tarea con ID web en el puerto 8080 se puede acceder aella en la direccioacuten webserviceconsul8080Para que las direcciones propias de Consul las resuelva su propio DNS y noel que esteacute asignado por defecto en la maacutequina usaremos la herramientadnsmasq20 que permite especificar la direccioacuten de un servidor DNS paraconsultas de direcciones especiacuteficas
Monitorizacioacuten Permite realizar comprobaciones del servicio y seguir su esta-do Aprovecharemos esta funcionalidad tanto para definir el propio procesode Nomad como servicio de Consul como las tareas desplegadas
HAProxy + Consul Template
HAProxy es una solucioacuten versaacutetil de coacutedigo abierto que ofrece solucionesde balanceo de carga y proxy Existen otras herramientas en el mercado comoNGINX o ldirectord sin embargo HAProxy suponiacutea una solucioacuten sencilla deconfigurar para mostrar el caso de uso
El uso de estas herramientas se debe a dos motivos para que no existacontienda con respecto a los puertos de los clientes usados por las tareas eacutestos sevan a asignar de forma dinaacutemica lo que en principio implicariacutea que la aplicacioacutendeberiacutea realizar consultas DNS de tipo SRV (que incluye puertos) a la interfazde Consul y balancear la carga entre tareas por redundancia y capacidad
Como la direccioacuten IP y puerto son variables cada vez que las tareas seactualicen o se reasignen es necesario volver a configurar HAProxy de formamanual Por ello HashiCorp ha desarrollado un programa denominado Con-sul Template que realiza peticiones sucesivas a la interfaz HTTP de Consul delas direcciones fiacutesicas de un servicio y reinicia automaacuteticamente el proceso deHAProxy Asiacute definiendo estas tareas como servicios Consul podremos tantomonitorizarlas como escalar las tareas dinaacutemicamente sin necesidad de cambiarel balanceador A partir del contenedor Docker oficial de HAProxy se ha desa-rrollado otro con la configuracioacuten baacutesica y con Consul Template para desplegarlocomo una tarea en Nomad
Despliegue
Se ha usado el mismo coacutedigo que en el apartado anterior con la persistenciaen el servicio de almacenamiento de Azure Desde la perspectiva del hardwarese implementaraacute la misma infraestructura que en el caso de DCOS (figura 18)estos es definiremos dos tipos de maacutequinas clientes un agente que se conectaraacutecon el balanceador de carga con nombre de dominio puacuteblico y donde se desple-garaacute el balanceador de carga de la vista web y agentes privados no accesiblesdesde fuera del cluster y donde se ejecutaraacuten el resto de tareas en la red inter-na La principal diferencia radica en las tareas que ejecutan HAproxy y ConsulTemplate que sustituye a las direcciones IP virtuales que ofrece DCOS
20httpwwwthekelleysorgukdnsmasqdochtml
34
Figura 20 Despliegue en Azure de Nomad+Consul
Cabe matizar que los balanceadores basados en HAProxy se implementanpor necesidad de la aplicacioacuten para el descubrimiento del servicio a diferenciade los de Azure que se implementan por motivos de seguridad y escalabilidaddel cluster en siacute
Configuracioacuten Nomad
Los ficheros de configuracioacuten de las maacutequinas maacutester y cliente son similaresy comparten la mayoriacutea de las opciones como por ejemplo el nombre del nodoo la interfaz de red donde escucha Nomad las peticiones Sus opciones son engeneral auto-explicativas sin embargo existen dos detalles que matizar
El proceso de Nomad escucha las peticiones tanto de los protocolos deconsenso como del usuario a traveacutes de una interfaz de red que se debeindicar en el fichero de configuracioacuten
En el caso de los clientes se deben indicar las direcciones de los servidoresdel cluster sin embargo se trata de un sistema dinaacutemico en el que losnodos pueden sufrir errores y cambiar de direccioacuten Por ello se ha definidoNomad como un servicio de Consul y asiacute poder definir la direccioacuten de losservidores como un nombre de dominio no por su direccioacuten fiacutesica que elservidor DNS de Consul se encargaraacute de resolver
Por defecto Nomad usa los siguientes puertos
API HTTP 4646 Peticiones HTTP y recepcioacuten de oacuterdenes mediante laliacutenea de comandos
RPC 4647 Protocolo de consenso entre los nodos del cluster
Serf 4648 Protocolo de gossip entre los servidores de los centros de datosgobernados por Nomad
35
Los dos uacuteltimos deben ser interfaces alcanzables por otros nodos sin embargo laAPI HTTP por motivos de seguridad deberiacutea ser local ya que en caso contrariocualquier persona con acceso a ella tiene el control sobre la herramienta Eacutestasolo deberiacutea estar accesible en un servidor o gestionarlo mediante una terminalSSH por ejemplo En este trabajo al ser una prueba de concepto se ha abiertoen todos los nodos
Trabajos de Nomad
Las tareas se detallan en ficheros con formato HashiCorp Configuration Lan-guage un derivado del formato JSON creado por la empresa que le da nombrecompatible con eacuteste y que permite comentarios
En estos ficheros se puede definir
La regioacuten y el centro de datos donde se ejecutaraacute (Nomad permite lagestioacuten de centros de datos geograacuteficamente distribuidos en regiones)
La poliacutetica de actualizacioacuten de la tarea
Grupo de tareas esto es que se ejecutaraacuten en el mismo nodo
El nuacutemero de grupos a ejecutarescalar asiacute como los liacutemite que debencumplir los nodos asignados
La poliacutetica de reinicio ante fallo o error
Tareas El controlador su configuracioacuten los paraacutemetros del servicio aso-ciado a registrar en Consul asiacute como los recursos que consume (puertosmemoria)
En nuestro caso usamos sobre todo el controlador Docker esto eso orques-tacioacuten de contenedores en los nodos clientes y tres de sus opciones
Imagen del contenedor Se han subido todas las imaacutegenes del proyecto a Doc-ker Hub donde por defecto se busca la imagen
Puertos Los puertos a usar por el contenedor que pueden ser estaacuteticos asigna-dos por el usuario o dinaacutemicos siendo Nomad el que se encarga de mapearun puerto libre del nodo cliente al expuesto por el contenedor
Servidores DNS Como usamos la interfaz DNS de Consul como descubri-miento de servicio se debe configurar el contenedor para que use cualquiernodo del cluster como servidor DNS
Configuracioacuten Consul
Al ser desarrolladas por la misma empresa los ficheros de configuracioacuten deConsul y Nomad comparten muchas opciones Consul tambieacuten acepta peticionesa traveacutes de una interfaz de red siendo los puertos usados por defecto
36
RPC 8300 8400 Maneja la peticiones del resto de nodos y usuarios
Serf 8301 8302 Protocolo gossip
HTTP API 8500
HTTPS API Desactivada por defecto
Interfaz DNS 8600
Se debe asignar a los protocolos internos del cluster esto es RPC y Serf unainterfaz alcanzable por los nodos y por el contrarioasignar a los dos uacuteltimos ala interfaz de loopback por motivos de seguridad
Cabe destacar que Consul tambieacuten cuenta con una interfaz graacutefica que per-mite ver el estado de los equipos y los servicios registrados y que se encuentra enel mismo puerto que la API HTTP en la direccioacuten httpIP_EQUIPO8500ui
Ejecucioacuten
Tanto Nomad como Consul requieren de la ejecucioacuten de un fichero en todoslos nodos integrantes del cluster Como prueba de concepto se ha decidido usardos servidores para ambos aunque cabe matizar que es un nuacutemero ineficienteya que la caiacuteda de uno de ellos supondriacutea la peacuterdida del cuoacuterum y por tantodel consenso del cluster
En primer lugar se arrancan los servidores que son los encargados de ejecu-tar el protocolo de consenso y gestionar el cluster y a continuacioacuten los clientesque no tienen praacutecticamente estado y dependen de los servidores
En el caso de Consul se debe indicar el directorio donde se guardan losficheros que describen los servicios asiacute como el archivo que especifica el resto delas opciones
1 Se inicia el primer servidor en uno de los equipos
$ consu l agent minuscon f i gminusd i r e t c consu l d s e r v i c e s minuscon f i gminus f i l e consu l_server j son
2 Los siguientes equipos deben unirse al anterior por lo que antildeadimos elargumento join con la direccioacuten del primer servidor Para el caso de otrosservidores
$ consu l agent minuscon f i gminusd i r e t c consu l d s e r v i c e s minuscon f i gminus f i l e consu l_server j son minus j o i n ltIP_servidor1gt
37
Una vez los servidores han alcanzado el consenso y elegido un liacuteder en losclientes
$ consu l agent minuscon f i gminusd i r e t c consu l d s e r v i c e s minuscon f i gminus f i l e c on su l_c l i en t j son minus j o i n ltIP_cualquierServ idorgt
El proceso para iniciar Nomad es igual y los comandos similares sin embargoya no es necesario indicar una direccioacuten IP fija en los equipos sino el nombre dedominio del servicio de Nomad registrado por Consul En el primer servidor
$ nomad agent minusc on f i g nomad_server j son
Y el resto de equipos (con su fichero de configuracioacuten correspondiente)$ nomad agent minusc on f i g nomad_server j son minus j o i n nomad s e r v i c e consu l
Por uacuteltimo para desplegar la aplicacioacuten web se han escrito tres ficherosque detallan las tareas de la interfaz web API y los balanceadores de cargaMediante la CLI
$ nomad run minusaddress=http lt ip_c lus te r gt4646 lt f i l e hclgt
O mediante la API HTTP de Nomad$ cu r l minusX POST minusd ltf i l e hclgthttp lt ip_c lus te r gt4646 jobltjob_namegt
Ansible
Como se puede comprobar con el aumento del nuacutemero de equipos pasa aser inviable manejar todos los nodos a traveacutes de terminal Ademaacutes como seha comentado con anterioridad Nomad requiere que en los nodos clientes es-teacuten instalados las herramientas que soporten las tareas por ejemplo el motorde Docker Por ello para facilitar tanto el arranque como la instalacioacuten de lasdependencias vamos a usar Ansible una herramienta de coacutedigo abierto desarro-llada en Python que permite gestionar configuraciones aprovisionar recursosdespliegue de aplicaciones de forma automaacutetica
A grandes rasgos esta herramienta funciona mediante ficheros en formatoYAML denominados play-books que describen un conjunto de pasos a ejecutaren una lista de equipos remotos Estos pasos son ejecutados por moacutedulos inde-pendientes a traveacutes de SSH es decir en cualquier ordenador con conexioacuten a los
38
hosts dado su contrasentildea o clave puacuteblica puede arrancar el script y realizariacutealos pasos de forma remota gestionando el cluster desde un solo equipo
Se han desarrollado guiones para lo siguiente
Descarga de los binarios de Nomad y Consul en todos los nodos copiade los ficheros de configuracioacuten baacutesicos y modificarlos de acuerdo a cadanodo (nombre del equipo direccioacuten IP)
Instalacioacuten de las dependencias
Arranque de Nomad y Consul
Ansible extiende su funcionalidad a traveacutes de moacutedulos independientes que per-miten por ejemplo instalar paquetes mediante herramientas de gestioacuten de pa-quetes (APT yum) aprovisionar automaacuteticamente maacutequinas virtuales de Ama-zon EC2
Algunas opciones de los ficheros de configuracioacuten de Nomad y Consul sondependientes del nodo particular por ejemplo la interfaz de red Para estetrabajo se ha realizado un moacutedulo para modificar los ficheros de configuracioacutende forma automaacutetica En el repositorio del proyecto se encuentra una carpetadonde se encuentran todos los ficheros necesarios para desplegar un clustertotalmente funcional solo requiere de una liacutenea de terminal con Ansible
$ ans ib l eminusplaybook minus i hos t s minusk ltssh_passgt minusu ltnode_usergt s i t e yml
39
62 Servicio de integracioacuten continua
Se ha implementado un sistema de integracioacuten continua que permite ejecu-tar tareas de compilacioacuten y pruebas de forma distribuida aumentando asiacute elrendimiento de los equipos En primer lugar se detallaraacute los motivos por los quepuede resultar beneficioso para las empresas una implementacioacuten de este tipo alo que seguiraacute los detalles del despliegue
621 DevOps
Metodologiacutea que defiende la comunicacioacuten y colaboracioacuten entre desarrolla-dores de software y los profesionales de operaciones a lo largo de todo el ciclo devida de una aplicacioacuten Estaacute muy relacionado con el desarrollo aacutegil de softwareesto es un enfoque para los proyectos que defiende el desarrollo iterativo e in-cremental donde los requisitos y soluciones evolucionan con el tiempo seguacuten lanecesidad del proyecto DevOps extiende esta filosofiacutea a todas los componentesde un servicio incluyendo sistemas y operaciones
Se trata de un concepto que cada organizacioacuten o empresa adapta a suspropias necesidades y procesos de negocio en este proyecto nos vamos a centraren la integracioacuten continua una praacutectica fundamental tanto del desarrollo aacutegilcomo de esta filosofiacutea
622 Integracioacuten Continua
Se define como una praacutectica de desarrollo software donde los miembros delequipo ponen en comuacuten su trabajo frecuentemente al menos una vez al diacutea21Cada integracioacuten se verifica con una compilacioacuten automaacutetica que incluye laejecucioacuten de pruebas para detectar errores de integracioacuten tan pronto como seaposible
Desde el punto de vista operativo esto supone automatizar la configuracioacutende equipos o el despliegue de maacutequinas virtuales donde compilar el proyecto yejecutar las pruebas y posteriormente eliminarlas Este flujo de trabajo se vebeneficiado en entornos distribuidos ya que el objetivo del desarrollador es com-probar el resultado de las pruebas raacutepidamente sin preocuparse del despliegueo los propios equipos
Para esta prueba de concepto vamos a usar Jenkins un servidor de integra-cioacuten continua escrito en Java que nos permite definir trabajos que contendraacutenla descripcioacuten tanto del entorno como su ejecucioacuten
Este sigue una estructura maestro-esclavo muy similar al de los gestores declusters usados en este proyecto el maestro contiene toda la loacutegica del servicio
21httpmartinfowlercomarticlescontinuousIntegrationhtml
40
trabajos autenticacioacuten y los esclavos son los encargados de la ejecucioacuten ensiacute Jenkins tiene varias viacuteas para aprovisionar los uacuteltimos
Mediante SSH
Interfaz graacutefica
Desarrollar un script propio
Ejecucioacuten de un fichero java
La ventaja de usar planificadores es que el despliegue de esclavos es dinaacutemicoes decir no tener una maacutequina especiacuteficamente configurada para ello DCOS yNomad se encargaraacuten de configurar estos despliegues en sus maacutequinas y poste-riormente eliminarlos Para ello se ha usado la uacuteltima opcioacuten definiendo tareasque descarguen el fichero java Con todo ello se consigue un entorno de inte-gracioacuten continua eficiente que ademaacutes permite la ejecucioacuten de otros servicios deforma independiente
Jenkins permite la creacioacuten de plugins que extienden sus funcionalidadesTanto Nomad22 como Apache Mesos cuentan con uno que permite su integra-cioacuten
Para esta prueba se va a usar el mismo proyecto que para el caso de usode orquestacioacuten de contenedores la aplicacioacuten web al que se le ha antildeadido untest para comprobar que se conecta correctamente a la base de datos medianteMocha un framework de Nodejs Por otro lado se antildeade el plugin de git ya queel coacutedigo se obtiene de GitHub el repositorio remoto de control de versiones delproyecto
El proceso general de ejecucioacuten seriacutea como sigue
1 Se ejecuta el maestro de Jenkins como tarea Docker partiendo de la imagenoficial
2 Al arrancar un trabajo se manda una tarea a los planificadores que laasignaraacuten a un nodo cliente Esta tarea consiste en la descarga del ficherode configuracioacuten Java y arrancarlo configurando el equipo como un clientede Jenkins temporalmente
3 Jenkins ejecuta el trabajo en el nuevo cliente en este caso iniciar la apli-cacioacuten web iniciar las pruebas y generar un informe
4 Se elimina el cliente
A continuacioacuten se detallan los matices de cada herramienta a la hora de imple-mentar este servicio
22Desarrollado por Ivo Verberk httpwwwivoverberknl
41
623 Jenkins con Nomad
El plugin permite la ejecucioacuten del fichero Java mediante dos controladorescontenedores Docker y Java En este proyecto nos hemos decantado por el pri-mero ya que nos ahorra instalar la maacutequina virtual de java en todos los nodoscliente Por ello se ha construido un contenedor base con Java para la ejecucioacutendel fichero de configuracioacuten y Nodejs para lanzar la aplicacioacuten web
El plugin se configura con la direccioacuten IP del cluster y el contenedor queejecuta el esclavo Jenkins Por su parte el trabajo en Jenkins se define conel repositorio en GitHub donde se aloja el coacutedigo del proyecto a probar y loscomandos a ejecutar en este caso npm update y npm test
624 Jenkins con DCOS
En el caso de DCOS su sistema de paquetes incluye Jenkins por lo queal instalarlo ya se tiene la configuracioacuten de Mesos totalmente funcional Sinembargo para ejecutar la aplicacioacuten en particular y las pruebas se requiere deNodejs en los equipos esclavos por ello debemos antildeadir un plugin de Jenkinsque permite instalar este entorno antes de ejecutar el trabajo Una vez hechoesto soacutelo queda definir la tarea igual que en el caso anterior
Cabe destacar que Mesosphere tambieacuten ha desarrollado un plugin que per-mite hacer despliegues en Marathon de tal manera que permitiriacutea con cadacommit del coacutedigo compilar la imagen del contenedor Docker y desplegarlaautomaacuteticamente aunque en este proyecto no se ha hecho pruebas de esta fun-cionalidad
42
7 Escalando la infraestructura
Uno de los factores clave que se busca a la hora de implementar sistemasdistribuidos es el poder escalar la infraestructura de forma maacutes sencilla estoes detectar que las maacutequinas estaacuten alcanzando el liacutemite de su capacidad yaumentar eacutesta ya sea mejorando sus caracteriacutesticas teacutecnicas o antildeadiendo maacutesnodos al cluster
El coacutedigo y todos los ficheros de configuracioacuten de esta seccioacuten tambieacuten sepueden encontrar en el repositorio del proyecto en GitHub23
71 Disentildeo
Microsoft Azure permite organizar los servicios cloud de forma loacutegica a traveacutesde grupos de recursos y asiacute poder crear o eliminar eacutestos en conjunto parauna aplicacioacuten determinada (por ejemplo una aplicacioacuten web suele requerir demaacutequinas virtuales bases de datos almacenamiento) Ademaacutes dispone dela opcioacuten de crear plantillas en formato JSON que permite al desarrolladordefinir los recursos y su interrelacioacuten para desplegar de forma automaacutetica unainfraestructura TI en la nube
Azure tambieacuten ofrece la posibilidad de monitorizar el estado de las maacutequinasvirtuales a traveacutes de extensiones lo que permite configurar el escalado automaacute-tico al alcanzar cierto liacutemite definido por el operador Eacutesta es a priori la formaen que deberiacutea implementarse hablando en teacuterminos de eficiencia sin embargoesta aproximacioacuten es totalmente dependiente de la plataforma es decir no sepuede extrapolar a otro proveedor o sobre recursos propios sin realizar un nue-vo disentildeo En este proyecto las tareas que son ejecutadas por estos equipos notienen estado ya que todo lo relativo a la persistencia lo hemos asignado fueradel cluster esto permite escalar la plataforma a traveacutes de otra aproximaciones
Las plantillas aceptan una serie de variables a indicar por el usuario entreotras los conjuntos de escala para definir los nodos aceptan una variable quedefine el nuacutemero de maacutequinas que los componen Por otro lado Azure ofreceuna API REST y kits de desarrollo software (SDK por sus siglas en ingleacutes) quepermiten su despliegue de forma programaacutetica Aprovechando estas facilidadesen este proyecto se va a aproximar la escalabilidad con el sucesivo desplieguede la infraestructura de forma automaacutetica se monitorizan los equipos y si sedetecta una maacutequina excesivamente cargada se aumenta el nuacutemero de equiposen la plantilla y se vuelve a desplegar
23httpsgithubcomAntonioAlfrzCloud-Orchestrators
43
En este proyecto se han disentildeado las plantillas para desplegar la arquitec-tura necesaria tanto de Nomad como de DCOS En el caso de la primera eldespliegue es maacutes descriptivo ya que incluye maacutequinas virtuales grupos de se-guridad redes En el caso de DCOS Azure cuenta con un servicio especiacuteficopara clusters gobernados por DCOS denominado Azure Container Service queincluye los componentes necesarios y la instalacioacuten ya realizada
72 Implementacioacuten
En primer lugar para monitorizar el estado de los equipos se va a usar laherramienta Nagios un sistema que permite controlar el estado del hardwarey los servicios de un equipo Se trata de una herramienta muy completa de laque se va a usar su capacidad para ejecutar comandos (plugins) en los nodospara detectar picos de carga generar alertas y ejecutar programas para estoseventos
Se ha desplegado una maacutequina virtual con esta herramienta en ambos siste-mas y se ha instalado una extensioacuten de Nagios (Nagios Remote Plugin Executor)en todos los nodos que permite ejecutar comprobaciones remotamente en con-creto para esta prueba de concepto medir el nivel de saturacioacuten de la unidadcentral de procesamiento (CPU por sus siglas del ingleacutes) Cuando sucede uncambio de estado de una maacutequina esto es cuando este paraacutemetro supera el liacutemi-te definido por el operador Nagios permite actuar en consecuencia ejecutandoprogramas por ello se ha desarrollado un script que ejecuta lo siguiente
Un programa desarrollado en Python con el SDK de Azure que modificalas plantillas y despliega los recursos
Un guioacuten de Ansible para instalar todos los componentes necesarios en lasnuevas maacutequinas y arrancar de nuevo el cluster y las aplicaciones
44
8 Resultados y conclusiones
En este uacuteltimo apartado se da una visioacuten global del proyecto asiacute como a lasconclusiones maacutes importantes a las que se ha llegado y posibles temas futurosde desarrollo
81 Comparacioacuten
Ambas herramientas ofrecen las funcionalidades para gestionar los recursoseficientemente ofreciendo a los desarrolladores una plataforma donde desplegarsus aplicaciones de forma distribuida independientemente de los equipos fiacutesicosy el hardware que las soporten
DCOS es una herramienta que en un comienzo fue privativa pero cuyos res-ponsables la empresa Mesosphere decidieron publicar una versioacuten de coacutedigoEacutesta nos permite gestionar un cluster de una forma sencilla y usable ademaacutes decomplementarlo con otras herramientas como el balanceador de carga integradoo la autenticacioacuten de usuarios ademaacutes estaacute basada en Apache Mesos un pro-yecto de relativa madurez y con el soporte de la Apache Software FoundationDe forma resumida DCOS ofrece muchas posibilidades y servicios a cambiode una arquitectura e instalacioacuten maacutes compleja
Por su parte HashiCorp con menor tiempo de desarrollo ha conseguidouna herramienta muy sencilla de desplegar que ademaacutes cumple con todas lasfuncionalidades baacutesicas ejecutando un simple binario en cada nodo se puededesplegar un gestor de clusters totalmente funcional Sin embargo no cuentacon todas las posibilidades de Mesos (Nomad cuenta con menos controladoresque entornos posibles de Mesos) ni con los antildeadidos de DCOS lo que implicael uso de otras herramientas para complementar el servicio (Consul HAProxy)
De entre las dificultades encontradas al usar estas herramientas y desplegaraplicaciones sobre ellas se puede destacar la depuracioacuten en ocasiones se desco-noce si un error viene de la propia herramienta de la aplicacioacuten desplegada o delequipo fiacutesico si no se cuenta con un sistema de procesamiento de registro unose puede encontrar con muacuteltiples terminales abiertas inspeccionando numerososficheros de registro buscando posibles errores Ademaacutes no dejan de ser solucio-nes que para usar eficientemente se debe conocer parte de su funcionamientoy sintaxis a la hora de describir la tareas lo que supone un esfuerzo antildeadido yaque cada una tiene sus particularidades y liacutemites
45
82 Conclusiones
En una sociedad cada vez maacutes digital las empresas deben adaptarse a unmercado cuya demanda de contenido no deja de crecer Las nuevas arquitecturascomo microservicios asiacute como la gran cantidad de datos generada implica queuna mejor gestioacuten de los recursos y la rapidez para desplegar o escalar solucionesdando valor al cliente lo maacutes raacutepido posible es uno de los objetivos de todas lasempresas de base tecnoloacutegica
Las ventajas que ofrecen los planificadores con aplicaciones distribuidas sonnumerosas sin ir maacutes lejos empresas tan punteras como Google llevan maacutesde 10 antildeos orquestando contenedores24 Por un lado permiten aumentar elrendimiento de los equipos propios y por otro implementar un servicio comoplataforma para despliegues distribuidos sobre cualquier conjunto hardware deesta forma se provee un servicio similar al de la nube puacuteblica pero con laprincipal diferencia de que se elimina la independencia con el proveedor (vendorlock-in) esto es las aplicaciones no tienen limitaciones impuestas por eacuteste talescomo lenguaje de programacioacuten o herramientas y permite despliegues hiacutebridosentre recursos propios y la nube
83 Objetivos conseguidos
Implementacioacuten de los planificadores propuestos en la nube Se ha en-tendido y detallado el funcionamiento de estas herramientas y se hanimplementado en el servicio de infraestructura de Microsoft Azure
Despliegue de aplicaciones y servicios distribuidos Servicios que se usanactualmente en la industria del desarrollo software asiacute como una aplica-cioacuten web con una arquitectura moderna han sido desplegados de formadistribuida en los equipos cumpliendo con la funcionalidad esperada ade-maacutes de consiguiendo una alta disponibilidad
Aproximacioacuten de arquitectura escalable Se ha hecho una aproximacioacutende infraestructura escalable de forma que sea parcialmente extrapolable aotros proveedores
24httpwwwnextplatformcom20160322decade-container-control-google
46
84 Liacuteneas de investigacioacuten
Siguiendo con la materia de este proyecto se presentan posibles liacuteneas deinvestigacioacuten
Analizar el despliegue con estas herramientas de aplicaciones de Big Datay comparar la eficiencia con respecto a soluciones especializadas
Analizar el rendimiento de los algoritmos de planificacioacuten antes pruebasde estreacutes y situaciones de alta contienda
Comparar el uso de estas herramientas con las praacutecticas actuales de laindustria o implementacioacuten en un sistema de produccioacuten real
47
Referencias
[1] LA Barroso y U Houmllzle laquoThe Datacenter as a Computer An Introduc-tion to the Design of Warehouse-Scale Machinesraquo En Morgan amp ClaypoolPublishers ()
[2] Systems Research Group ndash NetOS (University of Cambridge) The evolu-tion of cluster scheduler architectures 2016 url httpswwwclcamacukresearchsrgnetoscamsasblog2016-03-09-scheduler-architectureshtml
[3] A Das I Gupta y A Motivala SWIM Scalable Weakly-consistent Infection-style Process Group Membership Protocol Inf teacutec Dept of ComputerScience Cornell University url https www cs cornell edu ~asdasresearchdsn02-swimpdf
[4] D Dubhashi y A Das Mastering Mesos PACKT Publishing mayo de2016
[5] The Apache Software Foundation Apache Mesos documentation urlhttpsmesosapacheorg
[6] David Greenberg Building Applications on Mesos OrsquoReilly Media 2016[7] Armand Grillet Comparison of Container Schedulers Inf teacutec Technische
Universitaumlt Berlin[8] HashiCorp Consul documentation url httpswwwconsulio[9] HashiCorp Nomad documentation url httpsdcosio[10] Dan C Marinescu Cloud computing theory and practice Morgan Kauf-
mann 2013[11] Mesosphere DCOS documentation url httpswwwnomadproject
io[12] Microsoft Azure documentation url httpsazuremicrosoftcom
es-esdocumentation[13] D Ongaro y J Ousterhout In Search of an Understandable Consensus
Algorithm Inf teacutec Stanford University url httpsraftgithubioraftpdf
[14] Fei Teng laquoRessource allocation and schelduling models for cloud compu-tingraquo Tesis de mtriacutea Ecole Centrale Paris 2011
[15] A Williams y col Automation and Orchestration with Docker and Contai-ners A Comprehensive Overview of the Docker and Container Ecosystem3 The New Stack 2016
48
- Resumen
- Summary
- Iacutendice de figuras
- Introduccioacuten y objetivos
-
- Contexto
- Objetivos
- Estructura del documento
-
- Cloud Computing
- Nuevas cargas de trabajo
- Gestioacuten de recursos Planificadores
-
- Sistemas distribuidos
-
- Clasificacioacuten
-
- Herramientas
-
- DCOS
-
- Apache Mesos
- Ejemplos de uso
-
- Nomad
-
- Protocolo de consenso Raft
- Protocolo gossip SWIM
- Planificacioacuten
-
- Casos de uso y despliegue
-
- Aplicacioacuten Web
-
- DCOS
- Nomad
-
- Servicio de integracioacuten continua
-
- DevOps
- Integracioacuten Continua
- Jenkins con Nomad
- Jenkins con DCOS
-
- Escalando la infraestructura
-
- Disentildeo
- Implementacioacuten
-
- Resultados y conclusiones
-
- Comparacioacuten
- Conclusiones
- Objetivos conseguidos
- Liacuteneas de investigacioacuten
-
motores de orquestacioacuten de contenedores de ambas herramientas Marathon enDCOS y el controlador Docker en el caso de Nomad
Figura 17 Arquitectura aplicacioacuten web
A continuacioacuten vamos detallar el despliegue en ambas herramientas de es-ta solucioacuten y observar tanto queacute dificultades se encuentran como que ventajasofrecen El objetivo final es adaptar el proyecto modificaacutendolo lo menos posiblecon objeto de analizar la capacidad de estas herramientas para desplegar cual-quier aplicacioacuten sin que eso conlleve la modificacioacuten de la arquitectura de eacutestaes decir que no sea dependiente del entorno
611 DCOS
Se ha descrito DCOS como una herramienta que se despliega sobre un con-junto de ordenadores y que permite instalar gestionar el despliegue de sistemasdistribuidos
Microsoft Azure cuenta con una plantilla para desplegar en su servicio cloudun cluster de maacutequinas virtuales con DCOS ya instalado que cuenta con
Maacutequinas maestras (1 3 o 5 a seleccionar por el usuario) configuradascomo un conjunto de disponibilidad esto eso Azure da ciertas garantiacuteasde que al menos una maacutequina estaraacute en funcionamiento
Maacutequinas agentes Por motivos de seguridad se distinguen dos roles
bull Nodos privados solo accesibles desde la red interna y configuradoscomo un conjunto de escala un recurso de Azure para gestionar ydesplegar maacutequinas con configuraciones ideacutenticas para permitir unraacutepido escalado
bull Un equipo conectado accesible desde Internet a travntildees de un balan-ceador de carga puacuteblico y situado en una subred externa
28
Dos balanceadores de carga
bull La interfaz puacuteblica del cluster que se conecta con el cliente puacuteblicobull Acceso a los equipos maestros para el administrador que soacutelo permiteconexioacuten mediante SSH y credenciales
Almacenamiento para todas las maacutequinas
Configuraciones necesarias de red y seguridad
En la figura 18 se observa un diagrama de la infraestructura
Figura 18 Infraestructura en Azure
El primer obstaacuteculo es la persistencia de estado de la aplicacioacuten que seconsigue gracias a una base de datos no relacional basada en MongoDB asiacutecomo el almacenamiento de las canciones Para implementarla tenemos variasposibilidades
Montar un sistema externo de almacenamiento conectado en red en todoslos agentes donde se ejecuten las tareas de esta manera si una tarea pasade un nodo a otro por cualquier motivo puede tener acceso a los mismosficheros (opcioacuten del caso de uso original)
Implementar un sistema de ficheros distribuidos en los agentes
Usar los servicios de almacenamiento de las nubes puacuteblicas
Aprovechar el sistema de voluacutemenes persistentes de Apache Mesos Eacutestepermite reservar recursos de un agente de forma que al arrancar una tarease crea un volumen independiente del ciclo de vida de eacutesta con ello esosrecursos donde se ha almacenado la informacioacuten pueden volver a ofrecerseal mismo entorno de tal manera que otra tarea pueda acceder a ella
DCOS aprovecha este sistema de voluacutemenes persistentes y permite instalarbases de datos distribuidas como ArangoDB o Apache Cassandra sin embargoesto implicariacutea modificar todo el coacutedigo referente al modelo de la base de datos
29
Por motivos de eficiencia y latencia asiacute como de una mayor gobernabilidadde los datos la mejor opcioacuten es usar el recurso de voluacutemenes persistentes queofrece Apache Mesos ya que de esta manera se gestionariacutea la aplicacioacuten completamediante una uacutenica herramienta Sin embargo esto implica que la informacioacutense encuentra exclusivamente en el agente donde se haya ejecutado la tarea y porlo tanto se sigue requiriendo de software externo para distribuir la informacioacutenpara que se accesible para todos los agentes A la hora de realizar este proyectose encontraba en desarrollo Flocker una solucioacuten desarrollada por ClusterHQque permite compartir los voluacutemenes de Docker a traveacutes de un cluster quesi bien es compatible con el planificador de Mesos el proyecto se encontrabatodaviacutea en fases tempranas de desarrollo y los sistemas de almacenamiento quesoporta quedaban fuera del aacutembito de este trabajo
Por todo ello dado que las maacutequinas se han desplegado en la nube puacuteblicade Azure se decidioacute usar su servicio de almacenamiento de objetos para lascanciones y otra maacutequina para desplegar MongoDB y asiacute mantener el modelode datos original de la aplicacioacuten La diferencia del almacenamiento de obje-tos con respecto a nivel de fichero es que el primero no tiene jerarquiacutea paraorganizar los archivos eacutestos se guardan como objetos (con sus metadatos) enun mismo espacio soacutelo diferenciaacutendose por un identificador uacutenico esto implicaentre otras cosas que se puede acceder a un fichero dado uacutenicamente su IDindependientemente de la localizacioacuten fiacutesica de eacuteste facilitando pues la gestioacuteny el desarrollo
El coacutedigo del proyecto se ha modificado en los siguientes apartados
Las direcciones de la base de datos y los balanceadores de carga asiacute comosus puertos estaban originalmente fijos Se han configurado como variablesde entorno para facilitar el descubrimiento del servicio y hacer transpa-rente la aplicacioacuten al entorno de despliegue
La API REST se ha adaptado al almacenamiento en Azure en vez de enlocal
Estas modificaciones no suponen un cambio sustancial pero permiten separala persistencia de las tareas ejecutadas por DCOS lo que facilita en granmedida su ejecucioacuten al ser totalmente sin estado y ademaacutes implican tenerlos datos bajo un mayor control
Para la orquestacioacuten de contenedores se va a usar el entorno Marathondesarrollado tambieacuten por Mesosphere Eacuteste se puede usar a traveacutes de una interfazgraacutefica la interfaz de liacutenea de comandos (en lo que sigue CLI por sus siglas eningleacutes) de DCOS o con su API HTTP
Primero se han publicado la imaacutegenes de los contenedores que encapsulanla interfaz web y la api de la aplicacioacuten en el repositorio puacuteblico DockerHub
Los despliegues en este entorno se describen mediante ficheros JSON en losque se detalla entre otras opciones la imagen del contenedor los puertos a usar
30
los recursos que debe ocupar en un nodo o las instrucciones de monitorizacioacuten
Para el servicio de descubrimiento DCOS ofrece la posibilidad de asignardirecciones IP virtuales (VIP por sus siglas en ingleacutes) a tareas que se compartenen todos los nodos DCOS lleva integrado un balanceador de carga a nivel TCP(el componente denominado Minuteman) que balancea entre las direccionesvirtuales de las tareas y todas las instancias de eacutestas a lo largo del cluster Estoes necesario por dos motivos equilibrar la carga de los equipos con el fin deevitar un punto de uacutenico fallo mediante redundancia y evitar la contienda dedirecciones al ejecutar las tareas en puertos aleatorios
Este balanceador de carga estaacute basado en el trabajo de Michael Mitzenma-cher The Power of Two Choices in Randomized Load Balancing18 A grandesrasgos el algoritmo mantiene una media moacutevil exponencial de latencias paracada destino (backend) ademaacutes de las caiacutedas consecutivas Si un destino noresponde a una negociacioacuten en tres pasos (three way handshake) de forma con-secutiva en un periodo inferior a 5 ms se considera caiacutedo El algoritmo iterasobre los destinos disponibles en base a su histoacuterico de fallos y escoge dos deforma aleatoria de los cuales coge el de mejor meacutetrica
Las direcciones virtuales soacutelo se pueden resolver dentro del cluster porello para implementar la interfaz puacuteblica de la aplicacioacuten esto es el balancea-dor de carga de la interfaz web usaremos un paquete de DCOS denominadomarathon-lb un balanceador basado en HAProxy y adaptado por MesosphereEn este caso equilibra la carga de todas instancias de las tareas ejecutadas porel entorno Marathon por sus etiquetas y permite ademaacutes definir como puntode entrada muacuteltiples hosts virtuales definidos por sus nombres completos dedominio (FQDN por sus siglas en ingleacutes) en nuestro caso la interfaz puacuteblicadel balanceador de Azure para los agentes
Por motivos de seguridad todas las tareas se ejecutan en los agentes privadoses decir los que son exclusivamente accesibles desde la red interna Por su partemarathon-lb se ejecuta en el agente puacuteblico que cuenta con IP puacuteblica y lospuertos 80 (HTTP) y 8080 abiertos de forma que la aplicacioacuten sea accesibledesde Internet Esto es posible debido a que Apache Mesos permite reservarrecursos mediante roles asignados a nodos para un uso especiacutefico De esta formala arquitectura vista desde la aplicacioacuten quedariacutea como en la figura 19
18httpswwweecsharvardedu~michaelmpostscriptstpds2001pdf
31
Figura 19 Arquitectura de la aplicacioacuten web en DCOS
Ejecucioacuten
A la hora de desplegar la aplicacioacuten DCOS puede gestionarse medianteuna interfaz graacutefica o una interfaz de liacutenea de comandos La primera se accedea traveacutes de un navegador web en el puerto 80 (HTTP) y permite instalar losentornos disponibles observar el estado de los nodos y las tareas que se estaacutenejecutando y los ficheros de registros que eacutestas generan
La CLI permite el control desde un nodo o una maacutequina remota (suponiendoque los maestros tienen IP puacuteblica y el puerto 80 abierto) ya que DCOS tieneun sistema de autorizacioacuten que permite tener una interfaz puacuteblica con ciertasgarantiacuteas de seguridad
Por su parte cada entorno de trabajo puede ser controlado por la CLI peroademaacutes cuenta con sus propias interfaces Marathon expone una API HTTPen el puerto 8080 de la direccioacuten puacuteblica de los maestros del cluster asiacute comootra interfaz graacutefica Para desplegar un contenedor se podriacutea usar la CLI
$ dcos marathon app add lt f i l e j songt
O la API HTTP
$ cu r l minusX POST http lt ip_maestro gt8080v2apps minusd ltf i l e jsongt minusH Contentminustype app l i c a t i o n j son
32
612 Nomad
La arquitectura de Nomad es maacutes sencilla ya que solo requiere de un ficheroejecutable en todos los nodos para funcionar Si DCOS es la base de instala-cioacuten de entornos de terceros Nomad integra todas las funcionalidades baacutesicasesto es gestor de recursos planificador y ejecutor en los nodos cliente Estaherramienta cuenta con un menor tiempo de desarrollo y en el momento deescribir este documento cuenta exclusivamente con los siguientes controladoresen comparacioacuten con los entornos de DCOS
Motor Docker es decir funcioacuten de orquestacioacuten de contenedores
Ejecucioacuten de archivos binarios como comandos de Shell
Ejecucioacuten de aplicaciones Java
Virtualizacioacuten de maacutequinas mediante tecnologiacutea QEMU
Todos ellos necesitan que la tecnologiacutea subyacente esteacute instalada en las maacute-quinas clientes (Docker Java QEMU) Actualmente no permite el registro decontroladores por parte de terceros aunque estaacute planificado en un futuro ofreceruna interfaz para su desarrollo
Nomad no cuenta con el servicio de descubrimiento sin embargo puede inte-grarse con la herramienta Consul desarrollada por la misma empresa Por otrolado para el balanceo de carga usaremos un contenedor Docker con HAProxyuna herramienta de coacutedigo abierto que ofrece tanto servicios de proxy como debalanceador y cuyos ficheros de configuracioacuten completaremos con el proyectoConsul Template19
Consul
Consul sigue la misma arquitectura que Nomad es decir un nodo servidorque orquesta un conjunto de maacutequinas clientes y permite a los procesos que seejecutan en los equipos definirlos como servicios ofreciendo diversas caracteriacutes-ticas entorno a estos de los cuales vamos a usar dos
Descubrimiento de servicio Las maacutequinas clientes publican en el cataacutelogode servicios las tareas en ejecucioacuten y Consul les asigna nombres de dominioaccesibles por todos los miembros del cluster a traveacutes de la interfaz DNSincluida en esta herramientaConsul se integra con Nomad de forma que todas las tareas que se ejecu-ten en la segunda son automaacuteticamente publicados como servicios de laprimera de esta manera no hace falta conocer la direccioacuten de la maacutequinacliente donde se esteacute ejecutando el proceso ya que se puede acceder a eacutela traveacutes de su nombre de dominio de forma transparente Por ejemplo si
19[httpsgithubcomhashicorpconsul-template]
33
ejecutamos una tarea con ID web en el puerto 8080 se puede acceder aella en la direccioacuten webserviceconsul8080Para que las direcciones propias de Consul las resuelva su propio DNS y noel que esteacute asignado por defecto en la maacutequina usaremos la herramientadnsmasq20 que permite especificar la direccioacuten de un servidor DNS paraconsultas de direcciones especiacuteficas
Monitorizacioacuten Permite realizar comprobaciones del servicio y seguir su esta-do Aprovecharemos esta funcionalidad tanto para definir el propio procesode Nomad como servicio de Consul como las tareas desplegadas
HAProxy + Consul Template
HAProxy es una solucioacuten versaacutetil de coacutedigo abierto que ofrece solucionesde balanceo de carga y proxy Existen otras herramientas en el mercado comoNGINX o ldirectord sin embargo HAProxy suponiacutea una solucioacuten sencilla deconfigurar para mostrar el caso de uso
El uso de estas herramientas se debe a dos motivos para que no existacontienda con respecto a los puertos de los clientes usados por las tareas eacutestos sevan a asignar de forma dinaacutemica lo que en principio implicariacutea que la aplicacioacutendeberiacutea realizar consultas DNS de tipo SRV (que incluye puertos) a la interfazde Consul y balancear la carga entre tareas por redundancia y capacidad
Como la direccioacuten IP y puerto son variables cada vez que las tareas seactualicen o se reasignen es necesario volver a configurar HAProxy de formamanual Por ello HashiCorp ha desarrollado un programa denominado Con-sul Template que realiza peticiones sucesivas a la interfaz HTTP de Consul delas direcciones fiacutesicas de un servicio y reinicia automaacuteticamente el proceso deHAProxy Asiacute definiendo estas tareas como servicios Consul podremos tantomonitorizarlas como escalar las tareas dinaacutemicamente sin necesidad de cambiarel balanceador A partir del contenedor Docker oficial de HAProxy se ha desa-rrollado otro con la configuracioacuten baacutesica y con Consul Template para desplegarlocomo una tarea en Nomad
Despliegue
Se ha usado el mismo coacutedigo que en el apartado anterior con la persistenciaen el servicio de almacenamiento de Azure Desde la perspectiva del hardwarese implementaraacute la misma infraestructura que en el caso de DCOS (figura 18)estos es definiremos dos tipos de maacutequinas clientes un agente que se conectaraacutecon el balanceador de carga con nombre de dominio puacuteblico y donde se desple-garaacute el balanceador de carga de la vista web y agentes privados no accesiblesdesde fuera del cluster y donde se ejecutaraacuten el resto de tareas en la red inter-na La principal diferencia radica en las tareas que ejecutan HAproxy y ConsulTemplate que sustituye a las direcciones IP virtuales que ofrece DCOS
20httpwwwthekelleysorgukdnsmasqdochtml
34
Figura 20 Despliegue en Azure de Nomad+Consul
Cabe matizar que los balanceadores basados en HAProxy se implementanpor necesidad de la aplicacioacuten para el descubrimiento del servicio a diferenciade los de Azure que se implementan por motivos de seguridad y escalabilidaddel cluster en siacute
Configuracioacuten Nomad
Los ficheros de configuracioacuten de las maacutequinas maacutester y cliente son similaresy comparten la mayoriacutea de las opciones como por ejemplo el nombre del nodoo la interfaz de red donde escucha Nomad las peticiones Sus opciones son engeneral auto-explicativas sin embargo existen dos detalles que matizar
El proceso de Nomad escucha las peticiones tanto de los protocolos deconsenso como del usuario a traveacutes de una interfaz de red que se debeindicar en el fichero de configuracioacuten
En el caso de los clientes se deben indicar las direcciones de los servidoresdel cluster sin embargo se trata de un sistema dinaacutemico en el que losnodos pueden sufrir errores y cambiar de direccioacuten Por ello se ha definidoNomad como un servicio de Consul y asiacute poder definir la direccioacuten de losservidores como un nombre de dominio no por su direccioacuten fiacutesica que elservidor DNS de Consul se encargaraacute de resolver
Por defecto Nomad usa los siguientes puertos
API HTTP 4646 Peticiones HTTP y recepcioacuten de oacuterdenes mediante laliacutenea de comandos
RPC 4647 Protocolo de consenso entre los nodos del cluster
Serf 4648 Protocolo de gossip entre los servidores de los centros de datosgobernados por Nomad
35
Los dos uacuteltimos deben ser interfaces alcanzables por otros nodos sin embargo laAPI HTTP por motivos de seguridad deberiacutea ser local ya que en caso contrariocualquier persona con acceso a ella tiene el control sobre la herramienta Eacutestasolo deberiacutea estar accesible en un servidor o gestionarlo mediante una terminalSSH por ejemplo En este trabajo al ser una prueba de concepto se ha abiertoen todos los nodos
Trabajos de Nomad
Las tareas se detallan en ficheros con formato HashiCorp Configuration Lan-guage un derivado del formato JSON creado por la empresa que le da nombrecompatible con eacuteste y que permite comentarios
En estos ficheros se puede definir
La regioacuten y el centro de datos donde se ejecutaraacute (Nomad permite lagestioacuten de centros de datos geograacuteficamente distribuidos en regiones)
La poliacutetica de actualizacioacuten de la tarea
Grupo de tareas esto es que se ejecutaraacuten en el mismo nodo
El nuacutemero de grupos a ejecutarescalar asiacute como los liacutemite que debencumplir los nodos asignados
La poliacutetica de reinicio ante fallo o error
Tareas El controlador su configuracioacuten los paraacutemetros del servicio aso-ciado a registrar en Consul asiacute como los recursos que consume (puertosmemoria)
En nuestro caso usamos sobre todo el controlador Docker esto eso orques-tacioacuten de contenedores en los nodos clientes y tres de sus opciones
Imagen del contenedor Se han subido todas las imaacutegenes del proyecto a Doc-ker Hub donde por defecto se busca la imagen
Puertos Los puertos a usar por el contenedor que pueden ser estaacuteticos asigna-dos por el usuario o dinaacutemicos siendo Nomad el que se encarga de mapearun puerto libre del nodo cliente al expuesto por el contenedor
Servidores DNS Como usamos la interfaz DNS de Consul como descubri-miento de servicio se debe configurar el contenedor para que use cualquiernodo del cluster como servidor DNS
Configuracioacuten Consul
Al ser desarrolladas por la misma empresa los ficheros de configuracioacuten deConsul y Nomad comparten muchas opciones Consul tambieacuten acepta peticionesa traveacutes de una interfaz de red siendo los puertos usados por defecto
36
RPC 8300 8400 Maneja la peticiones del resto de nodos y usuarios
Serf 8301 8302 Protocolo gossip
HTTP API 8500
HTTPS API Desactivada por defecto
Interfaz DNS 8600
Se debe asignar a los protocolos internos del cluster esto es RPC y Serf unainterfaz alcanzable por los nodos y por el contrarioasignar a los dos uacuteltimos ala interfaz de loopback por motivos de seguridad
Cabe destacar que Consul tambieacuten cuenta con una interfaz graacutefica que per-mite ver el estado de los equipos y los servicios registrados y que se encuentra enel mismo puerto que la API HTTP en la direccioacuten httpIP_EQUIPO8500ui
Ejecucioacuten
Tanto Nomad como Consul requieren de la ejecucioacuten de un fichero en todoslos nodos integrantes del cluster Como prueba de concepto se ha decidido usardos servidores para ambos aunque cabe matizar que es un nuacutemero ineficienteya que la caiacuteda de uno de ellos supondriacutea la peacuterdida del cuoacuterum y por tantodel consenso del cluster
En primer lugar se arrancan los servidores que son los encargados de ejecu-tar el protocolo de consenso y gestionar el cluster y a continuacioacuten los clientesque no tienen praacutecticamente estado y dependen de los servidores
En el caso de Consul se debe indicar el directorio donde se guardan losficheros que describen los servicios asiacute como el archivo que especifica el resto delas opciones
1 Se inicia el primer servidor en uno de los equipos
$ consu l agent minuscon f i gminusd i r e t c consu l d s e r v i c e s minuscon f i gminus f i l e consu l_server j son
2 Los siguientes equipos deben unirse al anterior por lo que antildeadimos elargumento join con la direccioacuten del primer servidor Para el caso de otrosservidores
$ consu l agent minuscon f i gminusd i r e t c consu l d s e r v i c e s minuscon f i gminus f i l e consu l_server j son minus j o i n ltIP_servidor1gt
37
Una vez los servidores han alcanzado el consenso y elegido un liacuteder en losclientes
$ consu l agent minuscon f i gminusd i r e t c consu l d s e r v i c e s minuscon f i gminus f i l e c on su l_c l i en t j son minus j o i n ltIP_cualquierServ idorgt
El proceso para iniciar Nomad es igual y los comandos similares sin embargoya no es necesario indicar una direccioacuten IP fija en los equipos sino el nombre dedominio del servicio de Nomad registrado por Consul En el primer servidor
$ nomad agent minusc on f i g nomad_server j son
Y el resto de equipos (con su fichero de configuracioacuten correspondiente)$ nomad agent minusc on f i g nomad_server j son minus j o i n nomad s e r v i c e consu l
Por uacuteltimo para desplegar la aplicacioacuten web se han escrito tres ficherosque detallan las tareas de la interfaz web API y los balanceadores de cargaMediante la CLI
$ nomad run minusaddress=http lt ip_c lus te r gt4646 lt f i l e hclgt
O mediante la API HTTP de Nomad$ cu r l minusX POST minusd ltf i l e hclgthttp lt ip_c lus te r gt4646 jobltjob_namegt
Ansible
Como se puede comprobar con el aumento del nuacutemero de equipos pasa aser inviable manejar todos los nodos a traveacutes de terminal Ademaacutes como seha comentado con anterioridad Nomad requiere que en los nodos clientes es-teacuten instalados las herramientas que soporten las tareas por ejemplo el motorde Docker Por ello para facilitar tanto el arranque como la instalacioacuten de lasdependencias vamos a usar Ansible una herramienta de coacutedigo abierto desarro-llada en Python que permite gestionar configuraciones aprovisionar recursosdespliegue de aplicaciones de forma automaacutetica
A grandes rasgos esta herramienta funciona mediante ficheros en formatoYAML denominados play-books que describen un conjunto de pasos a ejecutaren una lista de equipos remotos Estos pasos son ejecutados por moacutedulos inde-pendientes a traveacutes de SSH es decir en cualquier ordenador con conexioacuten a los
38
hosts dado su contrasentildea o clave puacuteblica puede arrancar el script y realizariacutealos pasos de forma remota gestionando el cluster desde un solo equipo
Se han desarrollado guiones para lo siguiente
Descarga de los binarios de Nomad y Consul en todos los nodos copiade los ficheros de configuracioacuten baacutesicos y modificarlos de acuerdo a cadanodo (nombre del equipo direccioacuten IP)
Instalacioacuten de las dependencias
Arranque de Nomad y Consul
Ansible extiende su funcionalidad a traveacutes de moacutedulos independientes que per-miten por ejemplo instalar paquetes mediante herramientas de gestioacuten de pa-quetes (APT yum) aprovisionar automaacuteticamente maacutequinas virtuales de Ama-zon EC2
Algunas opciones de los ficheros de configuracioacuten de Nomad y Consul sondependientes del nodo particular por ejemplo la interfaz de red Para estetrabajo se ha realizado un moacutedulo para modificar los ficheros de configuracioacutende forma automaacutetica En el repositorio del proyecto se encuentra una carpetadonde se encuentran todos los ficheros necesarios para desplegar un clustertotalmente funcional solo requiere de una liacutenea de terminal con Ansible
$ ans ib l eminusplaybook minus i hos t s minusk ltssh_passgt minusu ltnode_usergt s i t e yml
39
62 Servicio de integracioacuten continua
Se ha implementado un sistema de integracioacuten continua que permite ejecu-tar tareas de compilacioacuten y pruebas de forma distribuida aumentando asiacute elrendimiento de los equipos En primer lugar se detallaraacute los motivos por los quepuede resultar beneficioso para las empresas una implementacioacuten de este tipo alo que seguiraacute los detalles del despliegue
621 DevOps
Metodologiacutea que defiende la comunicacioacuten y colaboracioacuten entre desarrolla-dores de software y los profesionales de operaciones a lo largo de todo el ciclo devida de una aplicacioacuten Estaacute muy relacionado con el desarrollo aacutegil de softwareesto es un enfoque para los proyectos que defiende el desarrollo iterativo e in-cremental donde los requisitos y soluciones evolucionan con el tiempo seguacuten lanecesidad del proyecto DevOps extiende esta filosofiacutea a todas los componentesde un servicio incluyendo sistemas y operaciones
Se trata de un concepto que cada organizacioacuten o empresa adapta a suspropias necesidades y procesos de negocio en este proyecto nos vamos a centraren la integracioacuten continua una praacutectica fundamental tanto del desarrollo aacutegilcomo de esta filosofiacutea
622 Integracioacuten Continua
Se define como una praacutectica de desarrollo software donde los miembros delequipo ponen en comuacuten su trabajo frecuentemente al menos una vez al diacutea21Cada integracioacuten se verifica con una compilacioacuten automaacutetica que incluye laejecucioacuten de pruebas para detectar errores de integracioacuten tan pronto como seaposible
Desde el punto de vista operativo esto supone automatizar la configuracioacutende equipos o el despliegue de maacutequinas virtuales donde compilar el proyecto yejecutar las pruebas y posteriormente eliminarlas Este flujo de trabajo se vebeneficiado en entornos distribuidos ya que el objetivo del desarrollador es com-probar el resultado de las pruebas raacutepidamente sin preocuparse del despliegueo los propios equipos
Para esta prueba de concepto vamos a usar Jenkins un servidor de integra-cioacuten continua escrito en Java que nos permite definir trabajos que contendraacutenla descripcioacuten tanto del entorno como su ejecucioacuten
Este sigue una estructura maestro-esclavo muy similar al de los gestores declusters usados en este proyecto el maestro contiene toda la loacutegica del servicio
21httpmartinfowlercomarticlescontinuousIntegrationhtml
40
trabajos autenticacioacuten y los esclavos son los encargados de la ejecucioacuten ensiacute Jenkins tiene varias viacuteas para aprovisionar los uacuteltimos
Mediante SSH
Interfaz graacutefica
Desarrollar un script propio
Ejecucioacuten de un fichero java
La ventaja de usar planificadores es que el despliegue de esclavos es dinaacutemicoes decir no tener una maacutequina especiacuteficamente configurada para ello DCOS yNomad se encargaraacuten de configurar estos despliegues en sus maacutequinas y poste-riormente eliminarlos Para ello se ha usado la uacuteltima opcioacuten definiendo tareasque descarguen el fichero java Con todo ello se consigue un entorno de inte-gracioacuten continua eficiente que ademaacutes permite la ejecucioacuten de otros servicios deforma independiente
Jenkins permite la creacioacuten de plugins que extienden sus funcionalidadesTanto Nomad22 como Apache Mesos cuentan con uno que permite su integra-cioacuten
Para esta prueba se va a usar el mismo proyecto que para el caso de usode orquestacioacuten de contenedores la aplicacioacuten web al que se le ha antildeadido untest para comprobar que se conecta correctamente a la base de datos medianteMocha un framework de Nodejs Por otro lado se antildeade el plugin de git ya queel coacutedigo se obtiene de GitHub el repositorio remoto de control de versiones delproyecto
El proceso general de ejecucioacuten seriacutea como sigue
1 Se ejecuta el maestro de Jenkins como tarea Docker partiendo de la imagenoficial
2 Al arrancar un trabajo se manda una tarea a los planificadores que laasignaraacuten a un nodo cliente Esta tarea consiste en la descarga del ficherode configuracioacuten Java y arrancarlo configurando el equipo como un clientede Jenkins temporalmente
3 Jenkins ejecuta el trabajo en el nuevo cliente en este caso iniciar la apli-cacioacuten web iniciar las pruebas y generar un informe
4 Se elimina el cliente
A continuacioacuten se detallan los matices de cada herramienta a la hora de imple-mentar este servicio
22Desarrollado por Ivo Verberk httpwwwivoverberknl
41
623 Jenkins con Nomad
El plugin permite la ejecucioacuten del fichero Java mediante dos controladorescontenedores Docker y Java En este proyecto nos hemos decantado por el pri-mero ya que nos ahorra instalar la maacutequina virtual de java en todos los nodoscliente Por ello se ha construido un contenedor base con Java para la ejecucioacutendel fichero de configuracioacuten y Nodejs para lanzar la aplicacioacuten web
El plugin se configura con la direccioacuten IP del cluster y el contenedor queejecuta el esclavo Jenkins Por su parte el trabajo en Jenkins se define conel repositorio en GitHub donde se aloja el coacutedigo del proyecto a probar y loscomandos a ejecutar en este caso npm update y npm test
624 Jenkins con DCOS
En el caso de DCOS su sistema de paquetes incluye Jenkins por lo queal instalarlo ya se tiene la configuracioacuten de Mesos totalmente funcional Sinembargo para ejecutar la aplicacioacuten en particular y las pruebas se requiere deNodejs en los equipos esclavos por ello debemos antildeadir un plugin de Jenkinsque permite instalar este entorno antes de ejecutar el trabajo Una vez hechoesto soacutelo queda definir la tarea igual que en el caso anterior
Cabe destacar que Mesosphere tambieacuten ha desarrollado un plugin que per-mite hacer despliegues en Marathon de tal manera que permitiriacutea con cadacommit del coacutedigo compilar la imagen del contenedor Docker y desplegarlaautomaacuteticamente aunque en este proyecto no se ha hecho pruebas de esta fun-cionalidad
42
7 Escalando la infraestructura
Uno de los factores clave que se busca a la hora de implementar sistemasdistribuidos es el poder escalar la infraestructura de forma maacutes sencilla estoes detectar que las maacutequinas estaacuten alcanzando el liacutemite de su capacidad yaumentar eacutesta ya sea mejorando sus caracteriacutesticas teacutecnicas o antildeadiendo maacutesnodos al cluster
El coacutedigo y todos los ficheros de configuracioacuten de esta seccioacuten tambieacuten sepueden encontrar en el repositorio del proyecto en GitHub23
71 Disentildeo
Microsoft Azure permite organizar los servicios cloud de forma loacutegica a traveacutesde grupos de recursos y asiacute poder crear o eliminar eacutestos en conjunto parauna aplicacioacuten determinada (por ejemplo una aplicacioacuten web suele requerir demaacutequinas virtuales bases de datos almacenamiento) Ademaacutes dispone dela opcioacuten de crear plantillas en formato JSON que permite al desarrolladordefinir los recursos y su interrelacioacuten para desplegar de forma automaacutetica unainfraestructura TI en la nube
Azure tambieacuten ofrece la posibilidad de monitorizar el estado de las maacutequinasvirtuales a traveacutes de extensiones lo que permite configurar el escalado automaacute-tico al alcanzar cierto liacutemite definido por el operador Eacutesta es a priori la formaen que deberiacutea implementarse hablando en teacuterminos de eficiencia sin embargoesta aproximacioacuten es totalmente dependiente de la plataforma es decir no sepuede extrapolar a otro proveedor o sobre recursos propios sin realizar un nue-vo disentildeo En este proyecto las tareas que son ejecutadas por estos equipos notienen estado ya que todo lo relativo a la persistencia lo hemos asignado fueradel cluster esto permite escalar la plataforma a traveacutes de otra aproximaciones
Las plantillas aceptan una serie de variables a indicar por el usuario entreotras los conjuntos de escala para definir los nodos aceptan una variable quedefine el nuacutemero de maacutequinas que los componen Por otro lado Azure ofreceuna API REST y kits de desarrollo software (SDK por sus siglas en ingleacutes) quepermiten su despliegue de forma programaacutetica Aprovechando estas facilidadesen este proyecto se va a aproximar la escalabilidad con el sucesivo desplieguede la infraestructura de forma automaacutetica se monitorizan los equipos y si sedetecta una maacutequina excesivamente cargada se aumenta el nuacutemero de equiposen la plantilla y se vuelve a desplegar
23httpsgithubcomAntonioAlfrzCloud-Orchestrators
43
En este proyecto se han disentildeado las plantillas para desplegar la arquitec-tura necesaria tanto de Nomad como de DCOS En el caso de la primera eldespliegue es maacutes descriptivo ya que incluye maacutequinas virtuales grupos de se-guridad redes En el caso de DCOS Azure cuenta con un servicio especiacuteficopara clusters gobernados por DCOS denominado Azure Container Service queincluye los componentes necesarios y la instalacioacuten ya realizada
72 Implementacioacuten
En primer lugar para monitorizar el estado de los equipos se va a usar laherramienta Nagios un sistema que permite controlar el estado del hardwarey los servicios de un equipo Se trata de una herramienta muy completa de laque se va a usar su capacidad para ejecutar comandos (plugins) en los nodospara detectar picos de carga generar alertas y ejecutar programas para estoseventos
Se ha desplegado una maacutequina virtual con esta herramienta en ambos siste-mas y se ha instalado una extensioacuten de Nagios (Nagios Remote Plugin Executor)en todos los nodos que permite ejecutar comprobaciones remotamente en con-creto para esta prueba de concepto medir el nivel de saturacioacuten de la unidadcentral de procesamiento (CPU por sus siglas del ingleacutes) Cuando sucede uncambio de estado de una maacutequina esto es cuando este paraacutemetro supera el liacutemi-te definido por el operador Nagios permite actuar en consecuencia ejecutandoprogramas por ello se ha desarrollado un script que ejecuta lo siguiente
Un programa desarrollado en Python con el SDK de Azure que modificalas plantillas y despliega los recursos
Un guioacuten de Ansible para instalar todos los componentes necesarios en lasnuevas maacutequinas y arrancar de nuevo el cluster y las aplicaciones
44
8 Resultados y conclusiones
En este uacuteltimo apartado se da una visioacuten global del proyecto asiacute como a lasconclusiones maacutes importantes a las que se ha llegado y posibles temas futurosde desarrollo
81 Comparacioacuten
Ambas herramientas ofrecen las funcionalidades para gestionar los recursoseficientemente ofreciendo a los desarrolladores una plataforma donde desplegarsus aplicaciones de forma distribuida independientemente de los equipos fiacutesicosy el hardware que las soporten
DCOS es una herramienta que en un comienzo fue privativa pero cuyos res-ponsables la empresa Mesosphere decidieron publicar una versioacuten de coacutedigoEacutesta nos permite gestionar un cluster de una forma sencilla y usable ademaacutes decomplementarlo con otras herramientas como el balanceador de carga integradoo la autenticacioacuten de usuarios ademaacutes estaacute basada en Apache Mesos un pro-yecto de relativa madurez y con el soporte de la Apache Software FoundationDe forma resumida DCOS ofrece muchas posibilidades y servicios a cambiode una arquitectura e instalacioacuten maacutes compleja
Por su parte HashiCorp con menor tiempo de desarrollo ha conseguidouna herramienta muy sencilla de desplegar que ademaacutes cumple con todas lasfuncionalidades baacutesicas ejecutando un simple binario en cada nodo se puededesplegar un gestor de clusters totalmente funcional Sin embargo no cuentacon todas las posibilidades de Mesos (Nomad cuenta con menos controladoresque entornos posibles de Mesos) ni con los antildeadidos de DCOS lo que implicael uso de otras herramientas para complementar el servicio (Consul HAProxy)
De entre las dificultades encontradas al usar estas herramientas y desplegaraplicaciones sobre ellas se puede destacar la depuracioacuten en ocasiones se desco-noce si un error viene de la propia herramienta de la aplicacioacuten desplegada o delequipo fiacutesico si no se cuenta con un sistema de procesamiento de registro unose puede encontrar con muacuteltiples terminales abiertas inspeccionando numerososficheros de registro buscando posibles errores Ademaacutes no dejan de ser solucio-nes que para usar eficientemente se debe conocer parte de su funcionamientoy sintaxis a la hora de describir la tareas lo que supone un esfuerzo antildeadido yaque cada una tiene sus particularidades y liacutemites
45
82 Conclusiones
En una sociedad cada vez maacutes digital las empresas deben adaptarse a unmercado cuya demanda de contenido no deja de crecer Las nuevas arquitecturascomo microservicios asiacute como la gran cantidad de datos generada implica queuna mejor gestioacuten de los recursos y la rapidez para desplegar o escalar solucionesdando valor al cliente lo maacutes raacutepido posible es uno de los objetivos de todas lasempresas de base tecnoloacutegica
Las ventajas que ofrecen los planificadores con aplicaciones distribuidas sonnumerosas sin ir maacutes lejos empresas tan punteras como Google llevan maacutesde 10 antildeos orquestando contenedores24 Por un lado permiten aumentar elrendimiento de los equipos propios y por otro implementar un servicio comoplataforma para despliegues distribuidos sobre cualquier conjunto hardware deesta forma se provee un servicio similar al de la nube puacuteblica pero con laprincipal diferencia de que se elimina la independencia con el proveedor (vendorlock-in) esto es las aplicaciones no tienen limitaciones impuestas por eacuteste talescomo lenguaje de programacioacuten o herramientas y permite despliegues hiacutebridosentre recursos propios y la nube
83 Objetivos conseguidos
Implementacioacuten de los planificadores propuestos en la nube Se ha en-tendido y detallado el funcionamiento de estas herramientas y se hanimplementado en el servicio de infraestructura de Microsoft Azure
Despliegue de aplicaciones y servicios distribuidos Servicios que se usanactualmente en la industria del desarrollo software asiacute como una aplica-cioacuten web con una arquitectura moderna han sido desplegados de formadistribuida en los equipos cumpliendo con la funcionalidad esperada ade-maacutes de consiguiendo una alta disponibilidad
Aproximacioacuten de arquitectura escalable Se ha hecho una aproximacioacutende infraestructura escalable de forma que sea parcialmente extrapolable aotros proveedores
24httpwwwnextplatformcom20160322decade-container-control-google
46
84 Liacuteneas de investigacioacuten
Siguiendo con la materia de este proyecto se presentan posibles liacuteneas deinvestigacioacuten
Analizar el despliegue con estas herramientas de aplicaciones de Big Datay comparar la eficiencia con respecto a soluciones especializadas
Analizar el rendimiento de los algoritmos de planificacioacuten antes pruebasde estreacutes y situaciones de alta contienda
Comparar el uso de estas herramientas con las praacutecticas actuales de laindustria o implementacioacuten en un sistema de produccioacuten real
47
Referencias
[1] LA Barroso y U Houmllzle laquoThe Datacenter as a Computer An Introduc-tion to the Design of Warehouse-Scale Machinesraquo En Morgan amp ClaypoolPublishers ()
[2] Systems Research Group ndash NetOS (University of Cambridge) The evolu-tion of cluster scheduler architectures 2016 url httpswwwclcamacukresearchsrgnetoscamsasblog2016-03-09-scheduler-architectureshtml
[3] A Das I Gupta y A Motivala SWIM Scalable Weakly-consistent Infection-style Process Group Membership Protocol Inf teacutec Dept of ComputerScience Cornell University url https www cs cornell edu ~asdasresearchdsn02-swimpdf
[4] D Dubhashi y A Das Mastering Mesos PACKT Publishing mayo de2016
[5] The Apache Software Foundation Apache Mesos documentation urlhttpsmesosapacheorg
[6] David Greenberg Building Applications on Mesos OrsquoReilly Media 2016[7] Armand Grillet Comparison of Container Schedulers Inf teacutec Technische
Universitaumlt Berlin[8] HashiCorp Consul documentation url httpswwwconsulio[9] HashiCorp Nomad documentation url httpsdcosio[10] Dan C Marinescu Cloud computing theory and practice Morgan Kauf-
mann 2013[11] Mesosphere DCOS documentation url httpswwwnomadproject
io[12] Microsoft Azure documentation url httpsazuremicrosoftcom
es-esdocumentation[13] D Ongaro y J Ousterhout In Search of an Understandable Consensus
Algorithm Inf teacutec Stanford University url httpsraftgithubioraftpdf
[14] Fei Teng laquoRessource allocation and schelduling models for cloud compu-tingraquo Tesis de mtriacutea Ecole Centrale Paris 2011
[15] A Williams y col Automation and Orchestration with Docker and Contai-ners A Comprehensive Overview of the Docker and Container Ecosystem3 The New Stack 2016
48
- Resumen
- Summary
- Iacutendice de figuras
- Introduccioacuten y objetivos
-
- Contexto
- Objetivos
- Estructura del documento
-
- Cloud Computing
- Nuevas cargas de trabajo
- Gestioacuten de recursos Planificadores
-
- Sistemas distribuidos
-
- Clasificacioacuten
-
- Herramientas
-
- DCOS
-
- Apache Mesos
- Ejemplos de uso
-
- Nomad
-
- Protocolo de consenso Raft
- Protocolo gossip SWIM
- Planificacioacuten
-
- Casos de uso y despliegue
-
- Aplicacioacuten Web
-
- DCOS
- Nomad
-
- Servicio de integracioacuten continua
-
- DevOps
- Integracioacuten Continua
- Jenkins con Nomad
- Jenkins con DCOS
-
- Escalando la infraestructura
-
- Disentildeo
- Implementacioacuten
-
- Resultados y conclusiones
-
- Comparacioacuten
- Conclusiones
- Objetivos conseguidos
- Liacuteneas de investigacioacuten
-
Dos balanceadores de carga
bull La interfaz puacuteblica del cluster que se conecta con el cliente puacuteblicobull Acceso a los equipos maestros para el administrador que soacutelo permiteconexioacuten mediante SSH y credenciales
Almacenamiento para todas las maacutequinas
Configuraciones necesarias de red y seguridad
En la figura 18 se observa un diagrama de la infraestructura
Figura 18 Infraestructura en Azure
El primer obstaacuteculo es la persistencia de estado de la aplicacioacuten que seconsigue gracias a una base de datos no relacional basada en MongoDB asiacutecomo el almacenamiento de las canciones Para implementarla tenemos variasposibilidades
Montar un sistema externo de almacenamiento conectado en red en todoslos agentes donde se ejecuten las tareas de esta manera si una tarea pasade un nodo a otro por cualquier motivo puede tener acceso a los mismosficheros (opcioacuten del caso de uso original)
Implementar un sistema de ficheros distribuidos en los agentes
Usar los servicios de almacenamiento de las nubes puacuteblicas
Aprovechar el sistema de voluacutemenes persistentes de Apache Mesos Eacutestepermite reservar recursos de un agente de forma que al arrancar una tarease crea un volumen independiente del ciclo de vida de eacutesta con ello esosrecursos donde se ha almacenado la informacioacuten pueden volver a ofrecerseal mismo entorno de tal manera que otra tarea pueda acceder a ella
DCOS aprovecha este sistema de voluacutemenes persistentes y permite instalarbases de datos distribuidas como ArangoDB o Apache Cassandra sin embargoesto implicariacutea modificar todo el coacutedigo referente al modelo de la base de datos
29
Por motivos de eficiencia y latencia asiacute como de una mayor gobernabilidadde los datos la mejor opcioacuten es usar el recurso de voluacutemenes persistentes queofrece Apache Mesos ya que de esta manera se gestionariacutea la aplicacioacuten completamediante una uacutenica herramienta Sin embargo esto implica que la informacioacutense encuentra exclusivamente en el agente donde se haya ejecutado la tarea y porlo tanto se sigue requiriendo de software externo para distribuir la informacioacutenpara que se accesible para todos los agentes A la hora de realizar este proyectose encontraba en desarrollo Flocker una solucioacuten desarrollada por ClusterHQque permite compartir los voluacutemenes de Docker a traveacutes de un cluster quesi bien es compatible con el planificador de Mesos el proyecto se encontrabatodaviacutea en fases tempranas de desarrollo y los sistemas de almacenamiento quesoporta quedaban fuera del aacutembito de este trabajo
Por todo ello dado que las maacutequinas se han desplegado en la nube puacuteblicade Azure se decidioacute usar su servicio de almacenamiento de objetos para lascanciones y otra maacutequina para desplegar MongoDB y asiacute mantener el modelode datos original de la aplicacioacuten La diferencia del almacenamiento de obje-tos con respecto a nivel de fichero es que el primero no tiene jerarquiacutea paraorganizar los archivos eacutestos se guardan como objetos (con sus metadatos) enun mismo espacio soacutelo diferenciaacutendose por un identificador uacutenico esto implicaentre otras cosas que se puede acceder a un fichero dado uacutenicamente su IDindependientemente de la localizacioacuten fiacutesica de eacuteste facilitando pues la gestioacuteny el desarrollo
El coacutedigo del proyecto se ha modificado en los siguientes apartados
Las direcciones de la base de datos y los balanceadores de carga asiacute comosus puertos estaban originalmente fijos Se han configurado como variablesde entorno para facilitar el descubrimiento del servicio y hacer transpa-rente la aplicacioacuten al entorno de despliegue
La API REST se ha adaptado al almacenamiento en Azure en vez de enlocal
Estas modificaciones no suponen un cambio sustancial pero permiten separala persistencia de las tareas ejecutadas por DCOS lo que facilita en granmedida su ejecucioacuten al ser totalmente sin estado y ademaacutes implican tenerlos datos bajo un mayor control
Para la orquestacioacuten de contenedores se va a usar el entorno Marathondesarrollado tambieacuten por Mesosphere Eacuteste se puede usar a traveacutes de una interfazgraacutefica la interfaz de liacutenea de comandos (en lo que sigue CLI por sus siglas eningleacutes) de DCOS o con su API HTTP
Primero se han publicado la imaacutegenes de los contenedores que encapsulanla interfaz web y la api de la aplicacioacuten en el repositorio puacuteblico DockerHub
Los despliegues en este entorno se describen mediante ficheros JSON en losque se detalla entre otras opciones la imagen del contenedor los puertos a usar
30
los recursos que debe ocupar en un nodo o las instrucciones de monitorizacioacuten
Para el servicio de descubrimiento DCOS ofrece la posibilidad de asignardirecciones IP virtuales (VIP por sus siglas en ingleacutes) a tareas que se compartenen todos los nodos DCOS lleva integrado un balanceador de carga a nivel TCP(el componente denominado Minuteman) que balancea entre las direccionesvirtuales de las tareas y todas las instancias de eacutestas a lo largo del cluster Estoes necesario por dos motivos equilibrar la carga de los equipos con el fin deevitar un punto de uacutenico fallo mediante redundancia y evitar la contienda dedirecciones al ejecutar las tareas en puertos aleatorios
Este balanceador de carga estaacute basado en el trabajo de Michael Mitzenma-cher The Power of Two Choices in Randomized Load Balancing18 A grandesrasgos el algoritmo mantiene una media moacutevil exponencial de latencias paracada destino (backend) ademaacutes de las caiacutedas consecutivas Si un destino noresponde a una negociacioacuten en tres pasos (three way handshake) de forma con-secutiva en un periodo inferior a 5 ms se considera caiacutedo El algoritmo iterasobre los destinos disponibles en base a su histoacuterico de fallos y escoge dos deforma aleatoria de los cuales coge el de mejor meacutetrica
Las direcciones virtuales soacutelo se pueden resolver dentro del cluster porello para implementar la interfaz puacuteblica de la aplicacioacuten esto es el balancea-dor de carga de la interfaz web usaremos un paquete de DCOS denominadomarathon-lb un balanceador basado en HAProxy y adaptado por MesosphereEn este caso equilibra la carga de todas instancias de las tareas ejecutadas porel entorno Marathon por sus etiquetas y permite ademaacutes definir como puntode entrada muacuteltiples hosts virtuales definidos por sus nombres completos dedominio (FQDN por sus siglas en ingleacutes) en nuestro caso la interfaz puacuteblicadel balanceador de Azure para los agentes
Por motivos de seguridad todas las tareas se ejecutan en los agentes privadoses decir los que son exclusivamente accesibles desde la red interna Por su partemarathon-lb se ejecuta en el agente puacuteblico que cuenta con IP puacuteblica y lospuertos 80 (HTTP) y 8080 abiertos de forma que la aplicacioacuten sea accesibledesde Internet Esto es posible debido a que Apache Mesos permite reservarrecursos mediante roles asignados a nodos para un uso especiacutefico De esta formala arquitectura vista desde la aplicacioacuten quedariacutea como en la figura 19
18httpswwweecsharvardedu~michaelmpostscriptstpds2001pdf
31
Figura 19 Arquitectura de la aplicacioacuten web en DCOS
Ejecucioacuten
A la hora de desplegar la aplicacioacuten DCOS puede gestionarse medianteuna interfaz graacutefica o una interfaz de liacutenea de comandos La primera se accedea traveacutes de un navegador web en el puerto 80 (HTTP) y permite instalar losentornos disponibles observar el estado de los nodos y las tareas que se estaacutenejecutando y los ficheros de registros que eacutestas generan
La CLI permite el control desde un nodo o una maacutequina remota (suponiendoque los maestros tienen IP puacuteblica y el puerto 80 abierto) ya que DCOS tieneun sistema de autorizacioacuten que permite tener una interfaz puacuteblica con ciertasgarantiacuteas de seguridad
Por su parte cada entorno de trabajo puede ser controlado por la CLI peroademaacutes cuenta con sus propias interfaces Marathon expone una API HTTPen el puerto 8080 de la direccioacuten puacuteblica de los maestros del cluster asiacute comootra interfaz graacutefica Para desplegar un contenedor se podriacutea usar la CLI
$ dcos marathon app add lt f i l e j songt
O la API HTTP
$ cu r l minusX POST http lt ip_maestro gt8080v2apps minusd ltf i l e jsongt minusH Contentminustype app l i c a t i o n j son
32
612 Nomad
La arquitectura de Nomad es maacutes sencilla ya que solo requiere de un ficheroejecutable en todos los nodos para funcionar Si DCOS es la base de instala-cioacuten de entornos de terceros Nomad integra todas las funcionalidades baacutesicasesto es gestor de recursos planificador y ejecutor en los nodos cliente Estaherramienta cuenta con un menor tiempo de desarrollo y en el momento deescribir este documento cuenta exclusivamente con los siguientes controladoresen comparacioacuten con los entornos de DCOS
Motor Docker es decir funcioacuten de orquestacioacuten de contenedores
Ejecucioacuten de archivos binarios como comandos de Shell
Ejecucioacuten de aplicaciones Java
Virtualizacioacuten de maacutequinas mediante tecnologiacutea QEMU
Todos ellos necesitan que la tecnologiacutea subyacente esteacute instalada en las maacute-quinas clientes (Docker Java QEMU) Actualmente no permite el registro decontroladores por parte de terceros aunque estaacute planificado en un futuro ofreceruna interfaz para su desarrollo
Nomad no cuenta con el servicio de descubrimiento sin embargo puede inte-grarse con la herramienta Consul desarrollada por la misma empresa Por otrolado para el balanceo de carga usaremos un contenedor Docker con HAProxyuna herramienta de coacutedigo abierto que ofrece tanto servicios de proxy como debalanceador y cuyos ficheros de configuracioacuten completaremos con el proyectoConsul Template19
Consul
Consul sigue la misma arquitectura que Nomad es decir un nodo servidorque orquesta un conjunto de maacutequinas clientes y permite a los procesos que seejecutan en los equipos definirlos como servicios ofreciendo diversas caracteriacutes-ticas entorno a estos de los cuales vamos a usar dos
Descubrimiento de servicio Las maacutequinas clientes publican en el cataacutelogode servicios las tareas en ejecucioacuten y Consul les asigna nombres de dominioaccesibles por todos los miembros del cluster a traveacutes de la interfaz DNSincluida en esta herramientaConsul se integra con Nomad de forma que todas las tareas que se ejecu-ten en la segunda son automaacuteticamente publicados como servicios de laprimera de esta manera no hace falta conocer la direccioacuten de la maacutequinacliente donde se esteacute ejecutando el proceso ya que se puede acceder a eacutela traveacutes de su nombre de dominio de forma transparente Por ejemplo si
19[httpsgithubcomhashicorpconsul-template]
33
ejecutamos una tarea con ID web en el puerto 8080 se puede acceder aella en la direccioacuten webserviceconsul8080Para que las direcciones propias de Consul las resuelva su propio DNS y noel que esteacute asignado por defecto en la maacutequina usaremos la herramientadnsmasq20 que permite especificar la direccioacuten de un servidor DNS paraconsultas de direcciones especiacuteficas
Monitorizacioacuten Permite realizar comprobaciones del servicio y seguir su esta-do Aprovecharemos esta funcionalidad tanto para definir el propio procesode Nomad como servicio de Consul como las tareas desplegadas
HAProxy + Consul Template
HAProxy es una solucioacuten versaacutetil de coacutedigo abierto que ofrece solucionesde balanceo de carga y proxy Existen otras herramientas en el mercado comoNGINX o ldirectord sin embargo HAProxy suponiacutea una solucioacuten sencilla deconfigurar para mostrar el caso de uso
El uso de estas herramientas se debe a dos motivos para que no existacontienda con respecto a los puertos de los clientes usados por las tareas eacutestos sevan a asignar de forma dinaacutemica lo que en principio implicariacutea que la aplicacioacutendeberiacutea realizar consultas DNS de tipo SRV (que incluye puertos) a la interfazde Consul y balancear la carga entre tareas por redundancia y capacidad
Como la direccioacuten IP y puerto son variables cada vez que las tareas seactualicen o se reasignen es necesario volver a configurar HAProxy de formamanual Por ello HashiCorp ha desarrollado un programa denominado Con-sul Template que realiza peticiones sucesivas a la interfaz HTTP de Consul delas direcciones fiacutesicas de un servicio y reinicia automaacuteticamente el proceso deHAProxy Asiacute definiendo estas tareas como servicios Consul podremos tantomonitorizarlas como escalar las tareas dinaacutemicamente sin necesidad de cambiarel balanceador A partir del contenedor Docker oficial de HAProxy se ha desa-rrollado otro con la configuracioacuten baacutesica y con Consul Template para desplegarlocomo una tarea en Nomad
Despliegue
Se ha usado el mismo coacutedigo que en el apartado anterior con la persistenciaen el servicio de almacenamiento de Azure Desde la perspectiva del hardwarese implementaraacute la misma infraestructura que en el caso de DCOS (figura 18)estos es definiremos dos tipos de maacutequinas clientes un agente que se conectaraacutecon el balanceador de carga con nombre de dominio puacuteblico y donde se desple-garaacute el balanceador de carga de la vista web y agentes privados no accesiblesdesde fuera del cluster y donde se ejecutaraacuten el resto de tareas en la red inter-na La principal diferencia radica en las tareas que ejecutan HAproxy y ConsulTemplate que sustituye a las direcciones IP virtuales que ofrece DCOS
20httpwwwthekelleysorgukdnsmasqdochtml
34
Figura 20 Despliegue en Azure de Nomad+Consul
Cabe matizar que los balanceadores basados en HAProxy se implementanpor necesidad de la aplicacioacuten para el descubrimiento del servicio a diferenciade los de Azure que se implementan por motivos de seguridad y escalabilidaddel cluster en siacute
Configuracioacuten Nomad
Los ficheros de configuracioacuten de las maacutequinas maacutester y cliente son similaresy comparten la mayoriacutea de las opciones como por ejemplo el nombre del nodoo la interfaz de red donde escucha Nomad las peticiones Sus opciones son engeneral auto-explicativas sin embargo existen dos detalles que matizar
El proceso de Nomad escucha las peticiones tanto de los protocolos deconsenso como del usuario a traveacutes de una interfaz de red que se debeindicar en el fichero de configuracioacuten
En el caso de los clientes se deben indicar las direcciones de los servidoresdel cluster sin embargo se trata de un sistema dinaacutemico en el que losnodos pueden sufrir errores y cambiar de direccioacuten Por ello se ha definidoNomad como un servicio de Consul y asiacute poder definir la direccioacuten de losservidores como un nombre de dominio no por su direccioacuten fiacutesica que elservidor DNS de Consul se encargaraacute de resolver
Por defecto Nomad usa los siguientes puertos
API HTTP 4646 Peticiones HTTP y recepcioacuten de oacuterdenes mediante laliacutenea de comandos
RPC 4647 Protocolo de consenso entre los nodos del cluster
Serf 4648 Protocolo de gossip entre los servidores de los centros de datosgobernados por Nomad
35
Los dos uacuteltimos deben ser interfaces alcanzables por otros nodos sin embargo laAPI HTTP por motivos de seguridad deberiacutea ser local ya que en caso contrariocualquier persona con acceso a ella tiene el control sobre la herramienta Eacutestasolo deberiacutea estar accesible en un servidor o gestionarlo mediante una terminalSSH por ejemplo En este trabajo al ser una prueba de concepto se ha abiertoen todos los nodos
Trabajos de Nomad
Las tareas se detallan en ficheros con formato HashiCorp Configuration Lan-guage un derivado del formato JSON creado por la empresa que le da nombrecompatible con eacuteste y que permite comentarios
En estos ficheros se puede definir
La regioacuten y el centro de datos donde se ejecutaraacute (Nomad permite lagestioacuten de centros de datos geograacuteficamente distribuidos en regiones)
La poliacutetica de actualizacioacuten de la tarea
Grupo de tareas esto es que se ejecutaraacuten en el mismo nodo
El nuacutemero de grupos a ejecutarescalar asiacute como los liacutemite que debencumplir los nodos asignados
La poliacutetica de reinicio ante fallo o error
Tareas El controlador su configuracioacuten los paraacutemetros del servicio aso-ciado a registrar en Consul asiacute como los recursos que consume (puertosmemoria)
En nuestro caso usamos sobre todo el controlador Docker esto eso orques-tacioacuten de contenedores en los nodos clientes y tres de sus opciones
Imagen del contenedor Se han subido todas las imaacutegenes del proyecto a Doc-ker Hub donde por defecto se busca la imagen
Puertos Los puertos a usar por el contenedor que pueden ser estaacuteticos asigna-dos por el usuario o dinaacutemicos siendo Nomad el que se encarga de mapearun puerto libre del nodo cliente al expuesto por el contenedor
Servidores DNS Como usamos la interfaz DNS de Consul como descubri-miento de servicio se debe configurar el contenedor para que use cualquiernodo del cluster como servidor DNS
Configuracioacuten Consul
Al ser desarrolladas por la misma empresa los ficheros de configuracioacuten deConsul y Nomad comparten muchas opciones Consul tambieacuten acepta peticionesa traveacutes de una interfaz de red siendo los puertos usados por defecto
36
RPC 8300 8400 Maneja la peticiones del resto de nodos y usuarios
Serf 8301 8302 Protocolo gossip
HTTP API 8500
HTTPS API Desactivada por defecto
Interfaz DNS 8600
Se debe asignar a los protocolos internos del cluster esto es RPC y Serf unainterfaz alcanzable por los nodos y por el contrarioasignar a los dos uacuteltimos ala interfaz de loopback por motivos de seguridad
Cabe destacar que Consul tambieacuten cuenta con una interfaz graacutefica que per-mite ver el estado de los equipos y los servicios registrados y que se encuentra enel mismo puerto que la API HTTP en la direccioacuten httpIP_EQUIPO8500ui
Ejecucioacuten
Tanto Nomad como Consul requieren de la ejecucioacuten de un fichero en todoslos nodos integrantes del cluster Como prueba de concepto se ha decidido usardos servidores para ambos aunque cabe matizar que es un nuacutemero ineficienteya que la caiacuteda de uno de ellos supondriacutea la peacuterdida del cuoacuterum y por tantodel consenso del cluster
En primer lugar se arrancan los servidores que son los encargados de ejecu-tar el protocolo de consenso y gestionar el cluster y a continuacioacuten los clientesque no tienen praacutecticamente estado y dependen de los servidores
En el caso de Consul se debe indicar el directorio donde se guardan losficheros que describen los servicios asiacute como el archivo que especifica el resto delas opciones
1 Se inicia el primer servidor en uno de los equipos
$ consu l agent minuscon f i gminusd i r e t c consu l d s e r v i c e s minuscon f i gminus f i l e consu l_server j son
2 Los siguientes equipos deben unirse al anterior por lo que antildeadimos elargumento join con la direccioacuten del primer servidor Para el caso de otrosservidores
$ consu l agent minuscon f i gminusd i r e t c consu l d s e r v i c e s minuscon f i gminus f i l e consu l_server j son minus j o i n ltIP_servidor1gt
37
Una vez los servidores han alcanzado el consenso y elegido un liacuteder en losclientes
$ consu l agent minuscon f i gminusd i r e t c consu l d s e r v i c e s minuscon f i gminus f i l e c on su l_c l i en t j son minus j o i n ltIP_cualquierServ idorgt
El proceso para iniciar Nomad es igual y los comandos similares sin embargoya no es necesario indicar una direccioacuten IP fija en los equipos sino el nombre dedominio del servicio de Nomad registrado por Consul En el primer servidor
$ nomad agent minusc on f i g nomad_server j son
Y el resto de equipos (con su fichero de configuracioacuten correspondiente)$ nomad agent minusc on f i g nomad_server j son minus j o i n nomad s e r v i c e consu l
Por uacuteltimo para desplegar la aplicacioacuten web se han escrito tres ficherosque detallan las tareas de la interfaz web API y los balanceadores de cargaMediante la CLI
$ nomad run minusaddress=http lt ip_c lus te r gt4646 lt f i l e hclgt
O mediante la API HTTP de Nomad$ cu r l minusX POST minusd ltf i l e hclgthttp lt ip_c lus te r gt4646 jobltjob_namegt
Ansible
Como se puede comprobar con el aumento del nuacutemero de equipos pasa aser inviable manejar todos los nodos a traveacutes de terminal Ademaacutes como seha comentado con anterioridad Nomad requiere que en los nodos clientes es-teacuten instalados las herramientas que soporten las tareas por ejemplo el motorde Docker Por ello para facilitar tanto el arranque como la instalacioacuten de lasdependencias vamos a usar Ansible una herramienta de coacutedigo abierto desarro-llada en Python que permite gestionar configuraciones aprovisionar recursosdespliegue de aplicaciones de forma automaacutetica
A grandes rasgos esta herramienta funciona mediante ficheros en formatoYAML denominados play-books que describen un conjunto de pasos a ejecutaren una lista de equipos remotos Estos pasos son ejecutados por moacutedulos inde-pendientes a traveacutes de SSH es decir en cualquier ordenador con conexioacuten a los
38
hosts dado su contrasentildea o clave puacuteblica puede arrancar el script y realizariacutealos pasos de forma remota gestionando el cluster desde un solo equipo
Se han desarrollado guiones para lo siguiente
Descarga de los binarios de Nomad y Consul en todos los nodos copiade los ficheros de configuracioacuten baacutesicos y modificarlos de acuerdo a cadanodo (nombre del equipo direccioacuten IP)
Instalacioacuten de las dependencias
Arranque de Nomad y Consul
Ansible extiende su funcionalidad a traveacutes de moacutedulos independientes que per-miten por ejemplo instalar paquetes mediante herramientas de gestioacuten de pa-quetes (APT yum) aprovisionar automaacuteticamente maacutequinas virtuales de Ama-zon EC2
Algunas opciones de los ficheros de configuracioacuten de Nomad y Consul sondependientes del nodo particular por ejemplo la interfaz de red Para estetrabajo se ha realizado un moacutedulo para modificar los ficheros de configuracioacutende forma automaacutetica En el repositorio del proyecto se encuentra una carpetadonde se encuentran todos los ficheros necesarios para desplegar un clustertotalmente funcional solo requiere de una liacutenea de terminal con Ansible
$ ans ib l eminusplaybook minus i hos t s minusk ltssh_passgt minusu ltnode_usergt s i t e yml
39
62 Servicio de integracioacuten continua
Se ha implementado un sistema de integracioacuten continua que permite ejecu-tar tareas de compilacioacuten y pruebas de forma distribuida aumentando asiacute elrendimiento de los equipos En primer lugar se detallaraacute los motivos por los quepuede resultar beneficioso para las empresas una implementacioacuten de este tipo alo que seguiraacute los detalles del despliegue
621 DevOps
Metodologiacutea que defiende la comunicacioacuten y colaboracioacuten entre desarrolla-dores de software y los profesionales de operaciones a lo largo de todo el ciclo devida de una aplicacioacuten Estaacute muy relacionado con el desarrollo aacutegil de softwareesto es un enfoque para los proyectos que defiende el desarrollo iterativo e in-cremental donde los requisitos y soluciones evolucionan con el tiempo seguacuten lanecesidad del proyecto DevOps extiende esta filosofiacutea a todas los componentesde un servicio incluyendo sistemas y operaciones
Se trata de un concepto que cada organizacioacuten o empresa adapta a suspropias necesidades y procesos de negocio en este proyecto nos vamos a centraren la integracioacuten continua una praacutectica fundamental tanto del desarrollo aacutegilcomo de esta filosofiacutea
622 Integracioacuten Continua
Se define como una praacutectica de desarrollo software donde los miembros delequipo ponen en comuacuten su trabajo frecuentemente al menos una vez al diacutea21Cada integracioacuten se verifica con una compilacioacuten automaacutetica que incluye laejecucioacuten de pruebas para detectar errores de integracioacuten tan pronto como seaposible
Desde el punto de vista operativo esto supone automatizar la configuracioacutende equipos o el despliegue de maacutequinas virtuales donde compilar el proyecto yejecutar las pruebas y posteriormente eliminarlas Este flujo de trabajo se vebeneficiado en entornos distribuidos ya que el objetivo del desarrollador es com-probar el resultado de las pruebas raacutepidamente sin preocuparse del despliegueo los propios equipos
Para esta prueba de concepto vamos a usar Jenkins un servidor de integra-cioacuten continua escrito en Java que nos permite definir trabajos que contendraacutenla descripcioacuten tanto del entorno como su ejecucioacuten
Este sigue una estructura maestro-esclavo muy similar al de los gestores declusters usados en este proyecto el maestro contiene toda la loacutegica del servicio
21httpmartinfowlercomarticlescontinuousIntegrationhtml
40
trabajos autenticacioacuten y los esclavos son los encargados de la ejecucioacuten ensiacute Jenkins tiene varias viacuteas para aprovisionar los uacuteltimos
Mediante SSH
Interfaz graacutefica
Desarrollar un script propio
Ejecucioacuten de un fichero java
La ventaja de usar planificadores es que el despliegue de esclavos es dinaacutemicoes decir no tener una maacutequina especiacuteficamente configurada para ello DCOS yNomad se encargaraacuten de configurar estos despliegues en sus maacutequinas y poste-riormente eliminarlos Para ello se ha usado la uacuteltima opcioacuten definiendo tareasque descarguen el fichero java Con todo ello se consigue un entorno de inte-gracioacuten continua eficiente que ademaacutes permite la ejecucioacuten de otros servicios deforma independiente
Jenkins permite la creacioacuten de plugins que extienden sus funcionalidadesTanto Nomad22 como Apache Mesos cuentan con uno que permite su integra-cioacuten
Para esta prueba se va a usar el mismo proyecto que para el caso de usode orquestacioacuten de contenedores la aplicacioacuten web al que se le ha antildeadido untest para comprobar que se conecta correctamente a la base de datos medianteMocha un framework de Nodejs Por otro lado se antildeade el plugin de git ya queel coacutedigo se obtiene de GitHub el repositorio remoto de control de versiones delproyecto
El proceso general de ejecucioacuten seriacutea como sigue
1 Se ejecuta el maestro de Jenkins como tarea Docker partiendo de la imagenoficial
2 Al arrancar un trabajo se manda una tarea a los planificadores que laasignaraacuten a un nodo cliente Esta tarea consiste en la descarga del ficherode configuracioacuten Java y arrancarlo configurando el equipo como un clientede Jenkins temporalmente
3 Jenkins ejecuta el trabajo en el nuevo cliente en este caso iniciar la apli-cacioacuten web iniciar las pruebas y generar un informe
4 Se elimina el cliente
A continuacioacuten se detallan los matices de cada herramienta a la hora de imple-mentar este servicio
22Desarrollado por Ivo Verberk httpwwwivoverberknl
41
623 Jenkins con Nomad
El plugin permite la ejecucioacuten del fichero Java mediante dos controladorescontenedores Docker y Java En este proyecto nos hemos decantado por el pri-mero ya que nos ahorra instalar la maacutequina virtual de java en todos los nodoscliente Por ello se ha construido un contenedor base con Java para la ejecucioacutendel fichero de configuracioacuten y Nodejs para lanzar la aplicacioacuten web
El plugin se configura con la direccioacuten IP del cluster y el contenedor queejecuta el esclavo Jenkins Por su parte el trabajo en Jenkins se define conel repositorio en GitHub donde se aloja el coacutedigo del proyecto a probar y loscomandos a ejecutar en este caso npm update y npm test
624 Jenkins con DCOS
En el caso de DCOS su sistema de paquetes incluye Jenkins por lo queal instalarlo ya se tiene la configuracioacuten de Mesos totalmente funcional Sinembargo para ejecutar la aplicacioacuten en particular y las pruebas se requiere deNodejs en los equipos esclavos por ello debemos antildeadir un plugin de Jenkinsque permite instalar este entorno antes de ejecutar el trabajo Una vez hechoesto soacutelo queda definir la tarea igual que en el caso anterior
Cabe destacar que Mesosphere tambieacuten ha desarrollado un plugin que per-mite hacer despliegues en Marathon de tal manera que permitiriacutea con cadacommit del coacutedigo compilar la imagen del contenedor Docker y desplegarlaautomaacuteticamente aunque en este proyecto no se ha hecho pruebas de esta fun-cionalidad
42
7 Escalando la infraestructura
Uno de los factores clave que se busca a la hora de implementar sistemasdistribuidos es el poder escalar la infraestructura de forma maacutes sencilla estoes detectar que las maacutequinas estaacuten alcanzando el liacutemite de su capacidad yaumentar eacutesta ya sea mejorando sus caracteriacutesticas teacutecnicas o antildeadiendo maacutesnodos al cluster
El coacutedigo y todos los ficheros de configuracioacuten de esta seccioacuten tambieacuten sepueden encontrar en el repositorio del proyecto en GitHub23
71 Disentildeo
Microsoft Azure permite organizar los servicios cloud de forma loacutegica a traveacutesde grupos de recursos y asiacute poder crear o eliminar eacutestos en conjunto parauna aplicacioacuten determinada (por ejemplo una aplicacioacuten web suele requerir demaacutequinas virtuales bases de datos almacenamiento) Ademaacutes dispone dela opcioacuten de crear plantillas en formato JSON que permite al desarrolladordefinir los recursos y su interrelacioacuten para desplegar de forma automaacutetica unainfraestructura TI en la nube
Azure tambieacuten ofrece la posibilidad de monitorizar el estado de las maacutequinasvirtuales a traveacutes de extensiones lo que permite configurar el escalado automaacute-tico al alcanzar cierto liacutemite definido por el operador Eacutesta es a priori la formaen que deberiacutea implementarse hablando en teacuterminos de eficiencia sin embargoesta aproximacioacuten es totalmente dependiente de la plataforma es decir no sepuede extrapolar a otro proveedor o sobre recursos propios sin realizar un nue-vo disentildeo En este proyecto las tareas que son ejecutadas por estos equipos notienen estado ya que todo lo relativo a la persistencia lo hemos asignado fueradel cluster esto permite escalar la plataforma a traveacutes de otra aproximaciones
Las plantillas aceptan una serie de variables a indicar por el usuario entreotras los conjuntos de escala para definir los nodos aceptan una variable quedefine el nuacutemero de maacutequinas que los componen Por otro lado Azure ofreceuna API REST y kits de desarrollo software (SDK por sus siglas en ingleacutes) quepermiten su despliegue de forma programaacutetica Aprovechando estas facilidadesen este proyecto se va a aproximar la escalabilidad con el sucesivo desplieguede la infraestructura de forma automaacutetica se monitorizan los equipos y si sedetecta una maacutequina excesivamente cargada se aumenta el nuacutemero de equiposen la plantilla y se vuelve a desplegar
23httpsgithubcomAntonioAlfrzCloud-Orchestrators
43
En este proyecto se han disentildeado las plantillas para desplegar la arquitec-tura necesaria tanto de Nomad como de DCOS En el caso de la primera eldespliegue es maacutes descriptivo ya que incluye maacutequinas virtuales grupos de se-guridad redes En el caso de DCOS Azure cuenta con un servicio especiacuteficopara clusters gobernados por DCOS denominado Azure Container Service queincluye los componentes necesarios y la instalacioacuten ya realizada
72 Implementacioacuten
En primer lugar para monitorizar el estado de los equipos se va a usar laherramienta Nagios un sistema que permite controlar el estado del hardwarey los servicios de un equipo Se trata de una herramienta muy completa de laque se va a usar su capacidad para ejecutar comandos (plugins) en los nodospara detectar picos de carga generar alertas y ejecutar programas para estoseventos
Se ha desplegado una maacutequina virtual con esta herramienta en ambos siste-mas y se ha instalado una extensioacuten de Nagios (Nagios Remote Plugin Executor)en todos los nodos que permite ejecutar comprobaciones remotamente en con-creto para esta prueba de concepto medir el nivel de saturacioacuten de la unidadcentral de procesamiento (CPU por sus siglas del ingleacutes) Cuando sucede uncambio de estado de una maacutequina esto es cuando este paraacutemetro supera el liacutemi-te definido por el operador Nagios permite actuar en consecuencia ejecutandoprogramas por ello se ha desarrollado un script que ejecuta lo siguiente
Un programa desarrollado en Python con el SDK de Azure que modificalas plantillas y despliega los recursos
Un guioacuten de Ansible para instalar todos los componentes necesarios en lasnuevas maacutequinas y arrancar de nuevo el cluster y las aplicaciones
44
8 Resultados y conclusiones
En este uacuteltimo apartado se da una visioacuten global del proyecto asiacute como a lasconclusiones maacutes importantes a las que se ha llegado y posibles temas futurosde desarrollo
81 Comparacioacuten
Ambas herramientas ofrecen las funcionalidades para gestionar los recursoseficientemente ofreciendo a los desarrolladores una plataforma donde desplegarsus aplicaciones de forma distribuida independientemente de los equipos fiacutesicosy el hardware que las soporten
DCOS es una herramienta que en un comienzo fue privativa pero cuyos res-ponsables la empresa Mesosphere decidieron publicar una versioacuten de coacutedigoEacutesta nos permite gestionar un cluster de una forma sencilla y usable ademaacutes decomplementarlo con otras herramientas como el balanceador de carga integradoo la autenticacioacuten de usuarios ademaacutes estaacute basada en Apache Mesos un pro-yecto de relativa madurez y con el soporte de la Apache Software FoundationDe forma resumida DCOS ofrece muchas posibilidades y servicios a cambiode una arquitectura e instalacioacuten maacutes compleja
Por su parte HashiCorp con menor tiempo de desarrollo ha conseguidouna herramienta muy sencilla de desplegar que ademaacutes cumple con todas lasfuncionalidades baacutesicas ejecutando un simple binario en cada nodo se puededesplegar un gestor de clusters totalmente funcional Sin embargo no cuentacon todas las posibilidades de Mesos (Nomad cuenta con menos controladoresque entornos posibles de Mesos) ni con los antildeadidos de DCOS lo que implicael uso de otras herramientas para complementar el servicio (Consul HAProxy)
De entre las dificultades encontradas al usar estas herramientas y desplegaraplicaciones sobre ellas se puede destacar la depuracioacuten en ocasiones se desco-noce si un error viene de la propia herramienta de la aplicacioacuten desplegada o delequipo fiacutesico si no se cuenta con un sistema de procesamiento de registro unose puede encontrar con muacuteltiples terminales abiertas inspeccionando numerososficheros de registro buscando posibles errores Ademaacutes no dejan de ser solucio-nes que para usar eficientemente se debe conocer parte de su funcionamientoy sintaxis a la hora de describir la tareas lo que supone un esfuerzo antildeadido yaque cada una tiene sus particularidades y liacutemites
45
82 Conclusiones
En una sociedad cada vez maacutes digital las empresas deben adaptarse a unmercado cuya demanda de contenido no deja de crecer Las nuevas arquitecturascomo microservicios asiacute como la gran cantidad de datos generada implica queuna mejor gestioacuten de los recursos y la rapidez para desplegar o escalar solucionesdando valor al cliente lo maacutes raacutepido posible es uno de los objetivos de todas lasempresas de base tecnoloacutegica
Las ventajas que ofrecen los planificadores con aplicaciones distribuidas sonnumerosas sin ir maacutes lejos empresas tan punteras como Google llevan maacutesde 10 antildeos orquestando contenedores24 Por un lado permiten aumentar elrendimiento de los equipos propios y por otro implementar un servicio comoplataforma para despliegues distribuidos sobre cualquier conjunto hardware deesta forma se provee un servicio similar al de la nube puacuteblica pero con laprincipal diferencia de que se elimina la independencia con el proveedor (vendorlock-in) esto es las aplicaciones no tienen limitaciones impuestas por eacuteste talescomo lenguaje de programacioacuten o herramientas y permite despliegues hiacutebridosentre recursos propios y la nube
83 Objetivos conseguidos
Implementacioacuten de los planificadores propuestos en la nube Se ha en-tendido y detallado el funcionamiento de estas herramientas y se hanimplementado en el servicio de infraestructura de Microsoft Azure
Despliegue de aplicaciones y servicios distribuidos Servicios que se usanactualmente en la industria del desarrollo software asiacute como una aplica-cioacuten web con una arquitectura moderna han sido desplegados de formadistribuida en los equipos cumpliendo con la funcionalidad esperada ade-maacutes de consiguiendo una alta disponibilidad
Aproximacioacuten de arquitectura escalable Se ha hecho una aproximacioacutende infraestructura escalable de forma que sea parcialmente extrapolable aotros proveedores
24httpwwwnextplatformcom20160322decade-container-control-google
46
84 Liacuteneas de investigacioacuten
Siguiendo con la materia de este proyecto se presentan posibles liacuteneas deinvestigacioacuten
Analizar el despliegue con estas herramientas de aplicaciones de Big Datay comparar la eficiencia con respecto a soluciones especializadas
Analizar el rendimiento de los algoritmos de planificacioacuten antes pruebasde estreacutes y situaciones de alta contienda
Comparar el uso de estas herramientas con las praacutecticas actuales de laindustria o implementacioacuten en un sistema de produccioacuten real
47
Referencias
[1] LA Barroso y U Houmllzle laquoThe Datacenter as a Computer An Introduc-tion to the Design of Warehouse-Scale Machinesraquo En Morgan amp ClaypoolPublishers ()
[2] Systems Research Group ndash NetOS (University of Cambridge) The evolu-tion of cluster scheduler architectures 2016 url httpswwwclcamacukresearchsrgnetoscamsasblog2016-03-09-scheduler-architectureshtml
[3] A Das I Gupta y A Motivala SWIM Scalable Weakly-consistent Infection-style Process Group Membership Protocol Inf teacutec Dept of ComputerScience Cornell University url https www cs cornell edu ~asdasresearchdsn02-swimpdf
[4] D Dubhashi y A Das Mastering Mesos PACKT Publishing mayo de2016
[5] The Apache Software Foundation Apache Mesos documentation urlhttpsmesosapacheorg
[6] David Greenberg Building Applications on Mesos OrsquoReilly Media 2016[7] Armand Grillet Comparison of Container Schedulers Inf teacutec Technische
Universitaumlt Berlin[8] HashiCorp Consul documentation url httpswwwconsulio[9] HashiCorp Nomad documentation url httpsdcosio[10] Dan C Marinescu Cloud computing theory and practice Morgan Kauf-
mann 2013[11] Mesosphere DCOS documentation url httpswwwnomadproject
io[12] Microsoft Azure documentation url httpsazuremicrosoftcom
es-esdocumentation[13] D Ongaro y J Ousterhout In Search of an Understandable Consensus
Algorithm Inf teacutec Stanford University url httpsraftgithubioraftpdf
[14] Fei Teng laquoRessource allocation and schelduling models for cloud compu-tingraquo Tesis de mtriacutea Ecole Centrale Paris 2011
[15] A Williams y col Automation and Orchestration with Docker and Contai-ners A Comprehensive Overview of the Docker and Container Ecosystem3 The New Stack 2016
48
- Resumen
- Summary
- Iacutendice de figuras
- Introduccioacuten y objetivos
-
- Contexto
- Objetivos
- Estructura del documento
-
- Cloud Computing
- Nuevas cargas de trabajo
- Gestioacuten de recursos Planificadores
-
- Sistemas distribuidos
-
- Clasificacioacuten
-
- Herramientas
-
- DCOS
-
- Apache Mesos
- Ejemplos de uso
-
- Nomad
-
- Protocolo de consenso Raft
- Protocolo gossip SWIM
- Planificacioacuten
-
- Casos de uso y despliegue
-
- Aplicacioacuten Web
-
- DCOS
- Nomad
-
- Servicio de integracioacuten continua
-
- DevOps
- Integracioacuten Continua
- Jenkins con Nomad
- Jenkins con DCOS
-
- Escalando la infraestructura
-
- Disentildeo
- Implementacioacuten
-
- Resultados y conclusiones
-
- Comparacioacuten
- Conclusiones
- Objetivos conseguidos
- Liacuteneas de investigacioacuten
-
Por motivos de eficiencia y latencia asiacute como de una mayor gobernabilidadde los datos la mejor opcioacuten es usar el recurso de voluacutemenes persistentes queofrece Apache Mesos ya que de esta manera se gestionariacutea la aplicacioacuten completamediante una uacutenica herramienta Sin embargo esto implica que la informacioacutense encuentra exclusivamente en el agente donde se haya ejecutado la tarea y porlo tanto se sigue requiriendo de software externo para distribuir la informacioacutenpara que se accesible para todos los agentes A la hora de realizar este proyectose encontraba en desarrollo Flocker una solucioacuten desarrollada por ClusterHQque permite compartir los voluacutemenes de Docker a traveacutes de un cluster quesi bien es compatible con el planificador de Mesos el proyecto se encontrabatodaviacutea en fases tempranas de desarrollo y los sistemas de almacenamiento quesoporta quedaban fuera del aacutembito de este trabajo
Por todo ello dado que las maacutequinas se han desplegado en la nube puacuteblicade Azure se decidioacute usar su servicio de almacenamiento de objetos para lascanciones y otra maacutequina para desplegar MongoDB y asiacute mantener el modelode datos original de la aplicacioacuten La diferencia del almacenamiento de obje-tos con respecto a nivel de fichero es que el primero no tiene jerarquiacutea paraorganizar los archivos eacutestos se guardan como objetos (con sus metadatos) enun mismo espacio soacutelo diferenciaacutendose por un identificador uacutenico esto implicaentre otras cosas que se puede acceder a un fichero dado uacutenicamente su IDindependientemente de la localizacioacuten fiacutesica de eacuteste facilitando pues la gestioacuteny el desarrollo
El coacutedigo del proyecto se ha modificado en los siguientes apartados
Las direcciones de la base de datos y los balanceadores de carga asiacute comosus puertos estaban originalmente fijos Se han configurado como variablesde entorno para facilitar el descubrimiento del servicio y hacer transpa-rente la aplicacioacuten al entorno de despliegue
La API REST se ha adaptado al almacenamiento en Azure en vez de enlocal
Estas modificaciones no suponen un cambio sustancial pero permiten separala persistencia de las tareas ejecutadas por DCOS lo que facilita en granmedida su ejecucioacuten al ser totalmente sin estado y ademaacutes implican tenerlos datos bajo un mayor control
Para la orquestacioacuten de contenedores se va a usar el entorno Marathondesarrollado tambieacuten por Mesosphere Eacuteste se puede usar a traveacutes de una interfazgraacutefica la interfaz de liacutenea de comandos (en lo que sigue CLI por sus siglas eningleacutes) de DCOS o con su API HTTP
Primero se han publicado la imaacutegenes de los contenedores que encapsulanla interfaz web y la api de la aplicacioacuten en el repositorio puacuteblico DockerHub
Los despliegues en este entorno se describen mediante ficheros JSON en losque se detalla entre otras opciones la imagen del contenedor los puertos a usar
30
los recursos que debe ocupar en un nodo o las instrucciones de monitorizacioacuten
Para el servicio de descubrimiento DCOS ofrece la posibilidad de asignardirecciones IP virtuales (VIP por sus siglas en ingleacutes) a tareas que se compartenen todos los nodos DCOS lleva integrado un balanceador de carga a nivel TCP(el componente denominado Minuteman) que balancea entre las direccionesvirtuales de las tareas y todas las instancias de eacutestas a lo largo del cluster Estoes necesario por dos motivos equilibrar la carga de los equipos con el fin deevitar un punto de uacutenico fallo mediante redundancia y evitar la contienda dedirecciones al ejecutar las tareas en puertos aleatorios
Este balanceador de carga estaacute basado en el trabajo de Michael Mitzenma-cher The Power of Two Choices in Randomized Load Balancing18 A grandesrasgos el algoritmo mantiene una media moacutevil exponencial de latencias paracada destino (backend) ademaacutes de las caiacutedas consecutivas Si un destino noresponde a una negociacioacuten en tres pasos (three way handshake) de forma con-secutiva en un periodo inferior a 5 ms se considera caiacutedo El algoritmo iterasobre los destinos disponibles en base a su histoacuterico de fallos y escoge dos deforma aleatoria de los cuales coge el de mejor meacutetrica
Las direcciones virtuales soacutelo se pueden resolver dentro del cluster porello para implementar la interfaz puacuteblica de la aplicacioacuten esto es el balancea-dor de carga de la interfaz web usaremos un paquete de DCOS denominadomarathon-lb un balanceador basado en HAProxy y adaptado por MesosphereEn este caso equilibra la carga de todas instancias de las tareas ejecutadas porel entorno Marathon por sus etiquetas y permite ademaacutes definir como puntode entrada muacuteltiples hosts virtuales definidos por sus nombres completos dedominio (FQDN por sus siglas en ingleacutes) en nuestro caso la interfaz puacuteblicadel balanceador de Azure para los agentes
Por motivos de seguridad todas las tareas se ejecutan en los agentes privadoses decir los que son exclusivamente accesibles desde la red interna Por su partemarathon-lb se ejecuta en el agente puacuteblico que cuenta con IP puacuteblica y lospuertos 80 (HTTP) y 8080 abiertos de forma que la aplicacioacuten sea accesibledesde Internet Esto es posible debido a que Apache Mesos permite reservarrecursos mediante roles asignados a nodos para un uso especiacutefico De esta formala arquitectura vista desde la aplicacioacuten quedariacutea como en la figura 19
18httpswwweecsharvardedu~michaelmpostscriptstpds2001pdf
31
Figura 19 Arquitectura de la aplicacioacuten web en DCOS
Ejecucioacuten
A la hora de desplegar la aplicacioacuten DCOS puede gestionarse medianteuna interfaz graacutefica o una interfaz de liacutenea de comandos La primera se accedea traveacutes de un navegador web en el puerto 80 (HTTP) y permite instalar losentornos disponibles observar el estado de los nodos y las tareas que se estaacutenejecutando y los ficheros de registros que eacutestas generan
La CLI permite el control desde un nodo o una maacutequina remota (suponiendoque los maestros tienen IP puacuteblica y el puerto 80 abierto) ya que DCOS tieneun sistema de autorizacioacuten que permite tener una interfaz puacuteblica con ciertasgarantiacuteas de seguridad
Por su parte cada entorno de trabajo puede ser controlado por la CLI peroademaacutes cuenta con sus propias interfaces Marathon expone una API HTTPen el puerto 8080 de la direccioacuten puacuteblica de los maestros del cluster asiacute comootra interfaz graacutefica Para desplegar un contenedor se podriacutea usar la CLI
$ dcos marathon app add lt f i l e j songt
O la API HTTP
$ cu r l minusX POST http lt ip_maestro gt8080v2apps minusd ltf i l e jsongt minusH Contentminustype app l i c a t i o n j son
32
612 Nomad
La arquitectura de Nomad es maacutes sencilla ya que solo requiere de un ficheroejecutable en todos los nodos para funcionar Si DCOS es la base de instala-cioacuten de entornos de terceros Nomad integra todas las funcionalidades baacutesicasesto es gestor de recursos planificador y ejecutor en los nodos cliente Estaherramienta cuenta con un menor tiempo de desarrollo y en el momento deescribir este documento cuenta exclusivamente con los siguientes controladoresen comparacioacuten con los entornos de DCOS
Motor Docker es decir funcioacuten de orquestacioacuten de contenedores
Ejecucioacuten de archivos binarios como comandos de Shell
Ejecucioacuten de aplicaciones Java
Virtualizacioacuten de maacutequinas mediante tecnologiacutea QEMU
Todos ellos necesitan que la tecnologiacutea subyacente esteacute instalada en las maacute-quinas clientes (Docker Java QEMU) Actualmente no permite el registro decontroladores por parte de terceros aunque estaacute planificado en un futuro ofreceruna interfaz para su desarrollo
Nomad no cuenta con el servicio de descubrimiento sin embargo puede inte-grarse con la herramienta Consul desarrollada por la misma empresa Por otrolado para el balanceo de carga usaremos un contenedor Docker con HAProxyuna herramienta de coacutedigo abierto que ofrece tanto servicios de proxy como debalanceador y cuyos ficheros de configuracioacuten completaremos con el proyectoConsul Template19
Consul
Consul sigue la misma arquitectura que Nomad es decir un nodo servidorque orquesta un conjunto de maacutequinas clientes y permite a los procesos que seejecutan en los equipos definirlos como servicios ofreciendo diversas caracteriacutes-ticas entorno a estos de los cuales vamos a usar dos
Descubrimiento de servicio Las maacutequinas clientes publican en el cataacutelogode servicios las tareas en ejecucioacuten y Consul les asigna nombres de dominioaccesibles por todos los miembros del cluster a traveacutes de la interfaz DNSincluida en esta herramientaConsul se integra con Nomad de forma que todas las tareas que se ejecu-ten en la segunda son automaacuteticamente publicados como servicios de laprimera de esta manera no hace falta conocer la direccioacuten de la maacutequinacliente donde se esteacute ejecutando el proceso ya que se puede acceder a eacutela traveacutes de su nombre de dominio de forma transparente Por ejemplo si
19[httpsgithubcomhashicorpconsul-template]
33
ejecutamos una tarea con ID web en el puerto 8080 se puede acceder aella en la direccioacuten webserviceconsul8080Para que las direcciones propias de Consul las resuelva su propio DNS y noel que esteacute asignado por defecto en la maacutequina usaremos la herramientadnsmasq20 que permite especificar la direccioacuten de un servidor DNS paraconsultas de direcciones especiacuteficas
Monitorizacioacuten Permite realizar comprobaciones del servicio y seguir su esta-do Aprovecharemos esta funcionalidad tanto para definir el propio procesode Nomad como servicio de Consul como las tareas desplegadas
HAProxy + Consul Template
HAProxy es una solucioacuten versaacutetil de coacutedigo abierto que ofrece solucionesde balanceo de carga y proxy Existen otras herramientas en el mercado comoNGINX o ldirectord sin embargo HAProxy suponiacutea una solucioacuten sencilla deconfigurar para mostrar el caso de uso
El uso de estas herramientas se debe a dos motivos para que no existacontienda con respecto a los puertos de los clientes usados por las tareas eacutestos sevan a asignar de forma dinaacutemica lo que en principio implicariacutea que la aplicacioacutendeberiacutea realizar consultas DNS de tipo SRV (que incluye puertos) a la interfazde Consul y balancear la carga entre tareas por redundancia y capacidad
Como la direccioacuten IP y puerto son variables cada vez que las tareas seactualicen o se reasignen es necesario volver a configurar HAProxy de formamanual Por ello HashiCorp ha desarrollado un programa denominado Con-sul Template que realiza peticiones sucesivas a la interfaz HTTP de Consul delas direcciones fiacutesicas de un servicio y reinicia automaacuteticamente el proceso deHAProxy Asiacute definiendo estas tareas como servicios Consul podremos tantomonitorizarlas como escalar las tareas dinaacutemicamente sin necesidad de cambiarel balanceador A partir del contenedor Docker oficial de HAProxy se ha desa-rrollado otro con la configuracioacuten baacutesica y con Consul Template para desplegarlocomo una tarea en Nomad
Despliegue
Se ha usado el mismo coacutedigo que en el apartado anterior con la persistenciaen el servicio de almacenamiento de Azure Desde la perspectiva del hardwarese implementaraacute la misma infraestructura que en el caso de DCOS (figura 18)estos es definiremos dos tipos de maacutequinas clientes un agente que se conectaraacutecon el balanceador de carga con nombre de dominio puacuteblico y donde se desple-garaacute el balanceador de carga de la vista web y agentes privados no accesiblesdesde fuera del cluster y donde se ejecutaraacuten el resto de tareas en la red inter-na La principal diferencia radica en las tareas que ejecutan HAproxy y ConsulTemplate que sustituye a las direcciones IP virtuales que ofrece DCOS
20httpwwwthekelleysorgukdnsmasqdochtml
34
Figura 20 Despliegue en Azure de Nomad+Consul
Cabe matizar que los balanceadores basados en HAProxy se implementanpor necesidad de la aplicacioacuten para el descubrimiento del servicio a diferenciade los de Azure que se implementan por motivos de seguridad y escalabilidaddel cluster en siacute
Configuracioacuten Nomad
Los ficheros de configuracioacuten de las maacutequinas maacutester y cliente son similaresy comparten la mayoriacutea de las opciones como por ejemplo el nombre del nodoo la interfaz de red donde escucha Nomad las peticiones Sus opciones son engeneral auto-explicativas sin embargo existen dos detalles que matizar
El proceso de Nomad escucha las peticiones tanto de los protocolos deconsenso como del usuario a traveacutes de una interfaz de red que se debeindicar en el fichero de configuracioacuten
En el caso de los clientes se deben indicar las direcciones de los servidoresdel cluster sin embargo se trata de un sistema dinaacutemico en el que losnodos pueden sufrir errores y cambiar de direccioacuten Por ello se ha definidoNomad como un servicio de Consul y asiacute poder definir la direccioacuten de losservidores como un nombre de dominio no por su direccioacuten fiacutesica que elservidor DNS de Consul se encargaraacute de resolver
Por defecto Nomad usa los siguientes puertos
API HTTP 4646 Peticiones HTTP y recepcioacuten de oacuterdenes mediante laliacutenea de comandos
RPC 4647 Protocolo de consenso entre los nodos del cluster
Serf 4648 Protocolo de gossip entre los servidores de los centros de datosgobernados por Nomad
35
Los dos uacuteltimos deben ser interfaces alcanzables por otros nodos sin embargo laAPI HTTP por motivos de seguridad deberiacutea ser local ya que en caso contrariocualquier persona con acceso a ella tiene el control sobre la herramienta Eacutestasolo deberiacutea estar accesible en un servidor o gestionarlo mediante una terminalSSH por ejemplo En este trabajo al ser una prueba de concepto se ha abiertoen todos los nodos
Trabajos de Nomad
Las tareas se detallan en ficheros con formato HashiCorp Configuration Lan-guage un derivado del formato JSON creado por la empresa que le da nombrecompatible con eacuteste y que permite comentarios
En estos ficheros se puede definir
La regioacuten y el centro de datos donde se ejecutaraacute (Nomad permite lagestioacuten de centros de datos geograacuteficamente distribuidos en regiones)
La poliacutetica de actualizacioacuten de la tarea
Grupo de tareas esto es que se ejecutaraacuten en el mismo nodo
El nuacutemero de grupos a ejecutarescalar asiacute como los liacutemite que debencumplir los nodos asignados
La poliacutetica de reinicio ante fallo o error
Tareas El controlador su configuracioacuten los paraacutemetros del servicio aso-ciado a registrar en Consul asiacute como los recursos que consume (puertosmemoria)
En nuestro caso usamos sobre todo el controlador Docker esto eso orques-tacioacuten de contenedores en los nodos clientes y tres de sus opciones
Imagen del contenedor Se han subido todas las imaacutegenes del proyecto a Doc-ker Hub donde por defecto se busca la imagen
Puertos Los puertos a usar por el contenedor que pueden ser estaacuteticos asigna-dos por el usuario o dinaacutemicos siendo Nomad el que se encarga de mapearun puerto libre del nodo cliente al expuesto por el contenedor
Servidores DNS Como usamos la interfaz DNS de Consul como descubri-miento de servicio se debe configurar el contenedor para que use cualquiernodo del cluster como servidor DNS
Configuracioacuten Consul
Al ser desarrolladas por la misma empresa los ficheros de configuracioacuten deConsul y Nomad comparten muchas opciones Consul tambieacuten acepta peticionesa traveacutes de una interfaz de red siendo los puertos usados por defecto
36
RPC 8300 8400 Maneja la peticiones del resto de nodos y usuarios
Serf 8301 8302 Protocolo gossip
HTTP API 8500
HTTPS API Desactivada por defecto
Interfaz DNS 8600
Se debe asignar a los protocolos internos del cluster esto es RPC y Serf unainterfaz alcanzable por los nodos y por el contrarioasignar a los dos uacuteltimos ala interfaz de loopback por motivos de seguridad
Cabe destacar que Consul tambieacuten cuenta con una interfaz graacutefica que per-mite ver el estado de los equipos y los servicios registrados y que se encuentra enel mismo puerto que la API HTTP en la direccioacuten httpIP_EQUIPO8500ui
Ejecucioacuten
Tanto Nomad como Consul requieren de la ejecucioacuten de un fichero en todoslos nodos integrantes del cluster Como prueba de concepto se ha decidido usardos servidores para ambos aunque cabe matizar que es un nuacutemero ineficienteya que la caiacuteda de uno de ellos supondriacutea la peacuterdida del cuoacuterum y por tantodel consenso del cluster
En primer lugar se arrancan los servidores que son los encargados de ejecu-tar el protocolo de consenso y gestionar el cluster y a continuacioacuten los clientesque no tienen praacutecticamente estado y dependen de los servidores
En el caso de Consul se debe indicar el directorio donde se guardan losficheros que describen los servicios asiacute como el archivo que especifica el resto delas opciones
1 Se inicia el primer servidor en uno de los equipos
$ consu l agent minuscon f i gminusd i r e t c consu l d s e r v i c e s minuscon f i gminus f i l e consu l_server j son
2 Los siguientes equipos deben unirse al anterior por lo que antildeadimos elargumento join con la direccioacuten del primer servidor Para el caso de otrosservidores
$ consu l agent minuscon f i gminusd i r e t c consu l d s e r v i c e s minuscon f i gminus f i l e consu l_server j son minus j o i n ltIP_servidor1gt
37
Una vez los servidores han alcanzado el consenso y elegido un liacuteder en losclientes
$ consu l agent minuscon f i gminusd i r e t c consu l d s e r v i c e s minuscon f i gminus f i l e c on su l_c l i en t j son minus j o i n ltIP_cualquierServ idorgt
El proceso para iniciar Nomad es igual y los comandos similares sin embargoya no es necesario indicar una direccioacuten IP fija en los equipos sino el nombre dedominio del servicio de Nomad registrado por Consul En el primer servidor
$ nomad agent minusc on f i g nomad_server j son
Y el resto de equipos (con su fichero de configuracioacuten correspondiente)$ nomad agent minusc on f i g nomad_server j son minus j o i n nomad s e r v i c e consu l
Por uacuteltimo para desplegar la aplicacioacuten web se han escrito tres ficherosque detallan las tareas de la interfaz web API y los balanceadores de cargaMediante la CLI
$ nomad run minusaddress=http lt ip_c lus te r gt4646 lt f i l e hclgt
O mediante la API HTTP de Nomad$ cu r l minusX POST minusd ltf i l e hclgthttp lt ip_c lus te r gt4646 jobltjob_namegt
Ansible
Como se puede comprobar con el aumento del nuacutemero de equipos pasa aser inviable manejar todos los nodos a traveacutes de terminal Ademaacutes como seha comentado con anterioridad Nomad requiere que en los nodos clientes es-teacuten instalados las herramientas que soporten las tareas por ejemplo el motorde Docker Por ello para facilitar tanto el arranque como la instalacioacuten de lasdependencias vamos a usar Ansible una herramienta de coacutedigo abierto desarro-llada en Python que permite gestionar configuraciones aprovisionar recursosdespliegue de aplicaciones de forma automaacutetica
A grandes rasgos esta herramienta funciona mediante ficheros en formatoYAML denominados play-books que describen un conjunto de pasos a ejecutaren una lista de equipos remotos Estos pasos son ejecutados por moacutedulos inde-pendientes a traveacutes de SSH es decir en cualquier ordenador con conexioacuten a los
38
hosts dado su contrasentildea o clave puacuteblica puede arrancar el script y realizariacutealos pasos de forma remota gestionando el cluster desde un solo equipo
Se han desarrollado guiones para lo siguiente
Descarga de los binarios de Nomad y Consul en todos los nodos copiade los ficheros de configuracioacuten baacutesicos y modificarlos de acuerdo a cadanodo (nombre del equipo direccioacuten IP)
Instalacioacuten de las dependencias
Arranque de Nomad y Consul
Ansible extiende su funcionalidad a traveacutes de moacutedulos independientes que per-miten por ejemplo instalar paquetes mediante herramientas de gestioacuten de pa-quetes (APT yum) aprovisionar automaacuteticamente maacutequinas virtuales de Ama-zon EC2
Algunas opciones de los ficheros de configuracioacuten de Nomad y Consul sondependientes del nodo particular por ejemplo la interfaz de red Para estetrabajo se ha realizado un moacutedulo para modificar los ficheros de configuracioacutende forma automaacutetica En el repositorio del proyecto se encuentra una carpetadonde se encuentran todos los ficheros necesarios para desplegar un clustertotalmente funcional solo requiere de una liacutenea de terminal con Ansible
$ ans ib l eminusplaybook minus i hos t s minusk ltssh_passgt minusu ltnode_usergt s i t e yml
39
62 Servicio de integracioacuten continua
Se ha implementado un sistema de integracioacuten continua que permite ejecu-tar tareas de compilacioacuten y pruebas de forma distribuida aumentando asiacute elrendimiento de los equipos En primer lugar se detallaraacute los motivos por los quepuede resultar beneficioso para las empresas una implementacioacuten de este tipo alo que seguiraacute los detalles del despliegue
621 DevOps
Metodologiacutea que defiende la comunicacioacuten y colaboracioacuten entre desarrolla-dores de software y los profesionales de operaciones a lo largo de todo el ciclo devida de una aplicacioacuten Estaacute muy relacionado con el desarrollo aacutegil de softwareesto es un enfoque para los proyectos que defiende el desarrollo iterativo e in-cremental donde los requisitos y soluciones evolucionan con el tiempo seguacuten lanecesidad del proyecto DevOps extiende esta filosofiacutea a todas los componentesde un servicio incluyendo sistemas y operaciones
Se trata de un concepto que cada organizacioacuten o empresa adapta a suspropias necesidades y procesos de negocio en este proyecto nos vamos a centraren la integracioacuten continua una praacutectica fundamental tanto del desarrollo aacutegilcomo de esta filosofiacutea
622 Integracioacuten Continua
Se define como una praacutectica de desarrollo software donde los miembros delequipo ponen en comuacuten su trabajo frecuentemente al menos una vez al diacutea21Cada integracioacuten se verifica con una compilacioacuten automaacutetica que incluye laejecucioacuten de pruebas para detectar errores de integracioacuten tan pronto como seaposible
Desde el punto de vista operativo esto supone automatizar la configuracioacutende equipos o el despliegue de maacutequinas virtuales donde compilar el proyecto yejecutar las pruebas y posteriormente eliminarlas Este flujo de trabajo se vebeneficiado en entornos distribuidos ya que el objetivo del desarrollador es com-probar el resultado de las pruebas raacutepidamente sin preocuparse del despliegueo los propios equipos
Para esta prueba de concepto vamos a usar Jenkins un servidor de integra-cioacuten continua escrito en Java que nos permite definir trabajos que contendraacutenla descripcioacuten tanto del entorno como su ejecucioacuten
Este sigue una estructura maestro-esclavo muy similar al de los gestores declusters usados en este proyecto el maestro contiene toda la loacutegica del servicio
21httpmartinfowlercomarticlescontinuousIntegrationhtml
40
trabajos autenticacioacuten y los esclavos son los encargados de la ejecucioacuten ensiacute Jenkins tiene varias viacuteas para aprovisionar los uacuteltimos
Mediante SSH
Interfaz graacutefica
Desarrollar un script propio
Ejecucioacuten de un fichero java
La ventaja de usar planificadores es que el despliegue de esclavos es dinaacutemicoes decir no tener una maacutequina especiacuteficamente configurada para ello DCOS yNomad se encargaraacuten de configurar estos despliegues en sus maacutequinas y poste-riormente eliminarlos Para ello se ha usado la uacuteltima opcioacuten definiendo tareasque descarguen el fichero java Con todo ello se consigue un entorno de inte-gracioacuten continua eficiente que ademaacutes permite la ejecucioacuten de otros servicios deforma independiente
Jenkins permite la creacioacuten de plugins que extienden sus funcionalidadesTanto Nomad22 como Apache Mesos cuentan con uno que permite su integra-cioacuten
Para esta prueba se va a usar el mismo proyecto que para el caso de usode orquestacioacuten de contenedores la aplicacioacuten web al que se le ha antildeadido untest para comprobar que se conecta correctamente a la base de datos medianteMocha un framework de Nodejs Por otro lado se antildeade el plugin de git ya queel coacutedigo se obtiene de GitHub el repositorio remoto de control de versiones delproyecto
El proceso general de ejecucioacuten seriacutea como sigue
1 Se ejecuta el maestro de Jenkins como tarea Docker partiendo de la imagenoficial
2 Al arrancar un trabajo se manda una tarea a los planificadores que laasignaraacuten a un nodo cliente Esta tarea consiste en la descarga del ficherode configuracioacuten Java y arrancarlo configurando el equipo como un clientede Jenkins temporalmente
3 Jenkins ejecuta el trabajo en el nuevo cliente en este caso iniciar la apli-cacioacuten web iniciar las pruebas y generar un informe
4 Se elimina el cliente
A continuacioacuten se detallan los matices de cada herramienta a la hora de imple-mentar este servicio
22Desarrollado por Ivo Verberk httpwwwivoverberknl
41
623 Jenkins con Nomad
El plugin permite la ejecucioacuten del fichero Java mediante dos controladorescontenedores Docker y Java En este proyecto nos hemos decantado por el pri-mero ya que nos ahorra instalar la maacutequina virtual de java en todos los nodoscliente Por ello se ha construido un contenedor base con Java para la ejecucioacutendel fichero de configuracioacuten y Nodejs para lanzar la aplicacioacuten web
El plugin se configura con la direccioacuten IP del cluster y el contenedor queejecuta el esclavo Jenkins Por su parte el trabajo en Jenkins se define conel repositorio en GitHub donde se aloja el coacutedigo del proyecto a probar y loscomandos a ejecutar en este caso npm update y npm test
624 Jenkins con DCOS
En el caso de DCOS su sistema de paquetes incluye Jenkins por lo queal instalarlo ya se tiene la configuracioacuten de Mesos totalmente funcional Sinembargo para ejecutar la aplicacioacuten en particular y las pruebas se requiere deNodejs en los equipos esclavos por ello debemos antildeadir un plugin de Jenkinsque permite instalar este entorno antes de ejecutar el trabajo Una vez hechoesto soacutelo queda definir la tarea igual que en el caso anterior
Cabe destacar que Mesosphere tambieacuten ha desarrollado un plugin que per-mite hacer despliegues en Marathon de tal manera que permitiriacutea con cadacommit del coacutedigo compilar la imagen del contenedor Docker y desplegarlaautomaacuteticamente aunque en este proyecto no se ha hecho pruebas de esta fun-cionalidad
42
7 Escalando la infraestructura
Uno de los factores clave que se busca a la hora de implementar sistemasdistribuidos es el poder escalar la infraestructura de forma maacutes sencilla estoes detectar que las maacutequinas estaacuten alcanzando el liacutemite de su capacidad yaumentar eacutesta ya sea mejorando sus caracteriacutesticas teacutecnicas o antildeadiendo maacutesnodos al cluster
El coacutedigo y todos los ficheros de configuracioacuten de esta seccioacuten tambieacuten sepueden encontrar en el repositorio del proyecto en GitHub23
71 Disentildeo
Microsoft Azure permite organizar los servicios cloud de forma loacutegica a traveacutesde grupos de recursos y asiacute poder crear o eliminar eacutestos en conjunto parauna aplicacioacuten determinada (por ejemplo una aplicacioacuten web suele requerir demaacutequinas virtuales bases de datos almacenamiento) Ademaacutes dispone dela opcioacuten de crear plantillas en formato JSON que permite al desarrolladordefinir los recursos y su interrelacioacuten para desplegar de forma automaacutetica unainfraestructura TI en la nube
Azure tambieacuten ofrece la posibilidad de monitorizar el estado de las maacutequinasvirtuales a traveacutes de extensiones lo que permite configurar el escalado automaacute-tico al alcanzar cierto liacutemite definido por el operador Eacutesta es a priori la formaen que deberiacutea implementarse hablando en teacuterminos de eficiencia sin embargoesta aproximacioacuten es totalmente dependiente de la plataforma es decir no sepuede extrapolar a otro proveedor o sobre recursos propios sin realizar un nue-vo disentildeo En este proyecto las tareas que son ejecutadas por estos equipos notienen estado ya que todo lo relativo a la persistencia lo hemos asignado fueradel cluster esto permite escalar la plataforma a traveacutes de otra aproximaciones
Las plantillas aceptan una serie de variables a indicar por el usuario entreotras los conjuntos de escala para definir los nodos aceptan una variable quedefine el nuacutemero de maacutequinas que los componen Por otro lado Azure ofreceuna API REST y kits de desarrollo software (SDK por sus siglas en ingleacutes) quepermiten su despliegue de forma programaacutetica Aprovechando estas facilidadesen este proyecto se va a aproximar la escalabilidad con el sucesivo desplieguede la infraestructura de forma automaacutetica se monitorizan los equipos y si sedetecta una maacutequina excesivamente cargada se aumenta el nuacutemero de equiposen la plantilla y se vuelve a desplegar
23httpsgithubcomAntonioAlfrzCloud-Orchestrators
43
En este proyecto se han disentildeado las plantillas para desplegar la arquitec-tura necesaria tanto de Nomad como de DCOS En el caso de la primera eldespliegue es maacutes descriptivo ya que incluye maacutequinas virtuales grupos de se-guridad redes En el caso de DCOS Azure cuenta con un servicio especiacuteficopara clusters gobernados por DCOS denominado Azure Container Service queincluye los componentes necesarios y la instalacioacuten ya realizada
72 Implementacioacuten
En primer lugar para monitorizar el estado de los equipos se va a usar laherramienta Nagios un sistema que permite controlar el estado del hardwarey los servicios de un equipo Se trata de una herramienta muy completa de laque se va a usar su capacidad para ejecutar comandos (plugins) en los nodospara detectar picos de carga generar alertas y ejecutar programas para estoseventos
Se ha desplegado una maacutequina virtual con esta herramienta en ambos siste-mas y se ha instalado una extensioacuten de Nagios (Nagios Remote Plugin Executor)en todos los nodos que permite ejecutar comprobaciones remotamente en con-creto para esta prueba de concepto medir el nivel de saturacioacuten de la unidadcentral de procesamiento (CPU por sus siglas del ingleacutes) Cuando sucede uncambio de estado de una maacutequina esto es cuando este paraacutemetro supera el liacutemi-te definido por el operador Nagios permite actuar en consecuencia ejecutandoprogramas por ello se ha desarrollado un script que ejecuta lo siguiente
Un programa desarrollado en Python con el SDK de Azure que modificalas plantillas y despliega los recursos
Un guioacuten de Ansible para instalar todos los componentes necesarios en lasnuevas maacutequinas y arrancar de nuevo el cluster y las aplicaciones
44
8 Resultados y conclusiones
En este uacuteltimo apartado se da una visioacuten global del proyecto asiacute como a lasconclusiones maacutes importantes a las que se ha llegado y posibles temas futurosde desarrollo
81 Comparacioacuten
Ambas herramientas ofrecen las funcionalidades para gestionar los recursoseficientemente ofreciendo a los desarrolladores una plataforma donde desplegarsus aplicaciones de forma distribuida independientemente de los equipos fiacutesicosy el hardware que las soporten
DCOS es una herramienta que en un comienzo fue privativa pero cuyos res-ponsables la empresa Mesosphere decidieron publicar una versioacuten de coacutedigoEacutesta nos permite gestionar un cluster de una forma sencilla y usable ademaacutes decomplementarlo con otras herramientas como el balanceador de carga integradoo la autenticacioacuten de usuarios ademaacutes estaacute basada en Apache Mesos un pro-yecto de relativa madurez y con el soporte de la Apache Software FoundationDe forma resumida DCOS ofrece muchas posibilidades y servicios a cambiode una arquitectura e instalacioacuten maacutes compleja
Por su parte HashiCorp con menor tiempo de desarrollo ha conseguidouna herramienta muy sencilla de desplegar que ademaacutes cumple con todas lasfuncionalidades baacutesicas ejecutando un simple binario en cada nodo se puededesplegar un gestor de clusters totalmente funcional Sin embargo no cuentacon todas las posibilidades de Mesos (Nomad cuenta con menos controladoresque entornos posibles de Mesos) ni con los antildeadidos de DCOS lo que implicael uso de otras herramientas para complementar el servicio (Consul HAProxy)
De entre las dificultades encontradas al usar estas herramientas y desplegaraplicaciones sobre ellas se puede destacar la depuracioacuten en ocasiones se desco-noce si un error viene de la propia herramienta de la aplicacioacuten desplegada o delequipo fiacutesico si no se cuenta con un sistema de procesamiento de registro unose puede encontrar con muacuteltiples terminales abiertas inspeccionando numerososficheros de registro buscando posibles errores Ademaacutes no dejan de ser solucio-nes que para usar eficientemente se debe conocer parte de su funcionamientoy sintaxis a la hora de describir la tareas lo que supone un esfuerzo antildeadido yaque cada una tiene sus particularidades y liacutemites
45
82 Conclusiones
En una sociedad cada vez maacutes digital las empresas deben adaptarse a unmercado cuya demanda de contenido no deja de crecer Las nuevas arquitecturascomo microservicios asiacute como la gran cantidad de datos generada implica queuna mejor gestioacuten de los recursos y la rapidez para desplegar o escalar solucionesdando valor al cliente lo maacutes raacutepido posible es uno de los objetivos de todas lasempresas de base tecnoloacutegica
Las ventajas que ofrecen los planificadores con aplicaciones distribuidas sonnumerosas sin ir maacutes lejos empresas tan punteras como Google llevan maacutesde 10 antildeos orquestando contenedores24 Por un lado permiten aumentar elrendimiento de los equipos propios y por otro implementar un servicio comoplataforma para despliegues distribuidos sobre cualquier conjunto hardware deesta forma se provee un servicio similar al de la nube puacuteblica pero con laprincipal diferencia de que se elimina la independencia con el proveedor (vendorlock-in) esto es las aplicaciones no tienen limitaciones impuestas por eacuteste talescomo lenguaje de programacioacuten o herramientas y permite despliegues hiacutebridosentre recursos propios y la nube
83 Objetivos conseguidos
Implementacioacuten de los planificadores propuestos en la nube Se ha en-tendido y detallado el funcionamiento de estas herramientas y se hanimplementado en el servicio de infraestructura de Microsoft Azure
Despliegue de aplicaciones y servicios distribuidos Servicios que se usanactualmente en la industria del desarrollo software asiacute como una aplica-cioacuten web con una arquitectura moderna han sido desplegados de formadistribuida en los equipos cumpliendo con la funcionalidad esperada ade-maacutes de consiguiendo una alta disponibilidad
Aproximacioacuten de arquitectura escalable Se ha hecho una aproximacioacutende infraestructura escalable de forma que sea parcialmente extrapolable aotros proveedores
24httpwwwnextplatformcom20160322decade-container-control-google
46
84 Liacuteneas de investigacioacuten
Siguiendo con la materia de este proyecto se presentan posibles liacuteneas deinvestigacioacuten
Analizar el despliegue con estas herramientas de aplicaciones de Big Datay comparar la eficiencia con respecto a soluciones especializadas
Analizar el rendimiento de los algoritmos de planificacioacuten antes pruebasde estreacutes y situaciones de alta contienda
Comparar el uso de estas herramientas con las praacutecticas actuales de laindustria o implementacioacuten en un sistema de produccioacuten real
47
Referencias
[1] LA Barroso y U Houmllzle laquoThe Datacenter as a Computer An Introduc-tion to the Design of Warehouse-Scale Machinesraquo En Morgan amp ClaypoolPublishers ()
[2] Systems Research Group ndash NetOS (University of Cambridge) The evolu-tion of cluster scheduler architectures 2016 url httpswwwclcamacukresearchsrgnetoscamsasblog2016-03-09-scheduler-architectureshtml
[3] A Das I Gupta y A Motivala SWIM Scalable Weakly-consistent Infection-style Process Group Membership Protocol Inf teacutec Dept of ComputerScience Cornell University url https www cs cornell edu ~asdasresearchdsn02-swimpdf
[4] D Dubhashi y A Das Mastering Mesos PACKT Publishing mayo de2016
[5] The Apache Software Foundation Apache Mesos documentation urlhttpsmesosapacheorg
[6] David Greenberg Building Applications on Mesos OrsquoReilly Media 2016[7] Armand Grillet Comparison of Container Schedulers Inf teacutec Technische
Universitaumlt Berlin[8] HashiCorp Consul documentation url httpswwwconsulio[9] HashiCorp Nomad documentation url httpsdcosio[10] Dan C Marinescu Cloud computing theory and practice Morgan Kauf-
mann 2013[11] Mesosphere DCOS documentation url httpswwwnomadproject
io[12] Microsoft Azure documentation url httpsazuremicrosoftcom
es-esdocumentation[13] D Ongaro y J Ousterhout In Search of an Understandable Consensus
Algorithm Inf teacutec Stanford University url httpsraftgithubioraftpdf
[14] Fei Teng laquoRessource allocation and schelduling models for cloud compu-tingraquo Tesis de mtriacutea Ecole Centrale Paris 2011
[15] A Williams y col Automation and Orchestration with Docker and Contai-ners A Comprehensive Overview of the Docker and Container Ecosystem3 The New Stack 2016
48
- Resumen
- Summary
- Iacutendice de figuras
- Introduccioacuten y objetivos
-
- Contexto
- Objetivos
- Estructura del documento
-
- Cloud Computing
- Nuevas cargas de trabajo
- Gestioacuten de recursos Planificadores
-
- Sistemas distribuidos
-
- Clasificacioacuten
-
- Herramientas
-
- DCOS
-
- Apache Mesos
- Ejemplos de uso
-
- Nomad
-
- Protocolo de consenso Raft
- Protocolo gossip SWIM
- Planificacioacuten
-
- Casos de uso y despliegue
-
- Aplicacioacuten Web
-
- DCOS
- Nomad
-
- Servicio de integracioacuten continua
-
- DevOps
- Integracioacuten Continua
- Jenkins con Nomad
- Jenkins con DCOS
-
- Escalando la infraestructura
-
- Disentildeo
- Implementacioacuten
-
- Resultados y conclusiones
-
- Comparacioacuten
- Conclusiones
- Objetivos conseguidos
- Liacuteneas de investigacioacuten
-
los recursos que debe ocupar en un nodo o las instrucciones de monitorizacioacuten
Para el servicio de descubrimiento DCOS ofrece la posibilidad de asignardirecciones IP virtuales (VIP por sus siglas en ingleacutes) a tareas que se compartenen todos los nodos DCOS lleva integrado un balanceador de carga a nivel TCP(el componente denominado Minuteman) que balancea entre las direccionesvirtuales de las tareas y todas las instancias de eacutestas a lo largo del cluster Estoes necesario por dos motivos equilibrar la carga de los equipos con el fin deevitar un punto de uacutenico fallo mediante redundancia y evitar la contienda dedirecciones al ejecutar las tareas en puertos aleatorios
Este balanceador de carga estaacute basado en el trabajo de Michael Mitzenma-cher The Power of Two Choices in Randomized Load Balancing18 A grandesrasgos el algoritmo mantiene una media moacutevil exponencial de latencias paracada destino (backend) ademaacutes de las caiacutedas consecutivas Si un destino noresponde a una negociacioacuten en tres pasos (three way handshake) de forma con-secutiva en un periodo inferior a 5 ms se considera caiacutedo El algoritmo iterasobre los destinos disponibles en base a su histoacuterico de fallos y escoge dos deforma aleatoria de los cuales coge el de mejor meacutetrica
Las direcciones virtuales soacutelo se pueden resolver dentro del cluster porello para implementar la interfaz puacuteblica de la aplicacioacuten esto es el balancea-dor de carga de la interfaz web usaremos un paquete de DCOS denominadomarathon-lb un balanceador basado en HAProxy y adaptado por MesosphereEn este caso equilibra la carga de todas instancias de las tareas ejecutadas porel entorno Marathon por sus etiquetas y permite ademaacutes definir como puntode entrada muacuteltiples hosts virtuales definidos por sus nombres completos dedominio (FQDN por sus siglas en ingleacutes) en nuestro caso la interfaz puacuteblicadel balanceador de Azure para los agentes
Por motivos de seguridad todas las tareas se ejecutan en los agentes privadoses decir los que son exclusivamente accesibles desde la red interna Por su partemarathon-lb se ejecuta en el agente puacuteblico que cuenta con IP puacuteblica y lospuertos 80 (HTTP) y 8080 abiertos de forma que la aplicacioacuten sea accesibledesde Internet Esto es posible debido a que Apache Mesos permite reservarrecursos mediante roles asignados a nodos para un uso especiacutefico De esta formala arquitectura vista desde la aplicacioacuten quedariacutea como en la figura 19
18httpswwweecsharvardedu~michaelmpostscriptstpds2001pdf
31
Figura 19 Arquitectura de la aplicacioacuten web en DCOS
Ejecucioacuten
A la hora de desplegar la aplicacioacuten DCOS puede gestionarse medianteuna interfaz graacutefica o una interfaz de liacutenea de comandos La primera se accedea traveacutes de un navegador web en el puerto 80 (HTTP) y permite instalar losentornos disponibles observar el estado de los nodos y las tareas que se estaacutenejecutando y los ficheros de registros que eacutestas generan
La CLI permite el control desde un nodo o una maacutequina remota (suponiendoque los maestros tienen IP puacuteblica y el puerto 80 abierto) ya que DCOS tieneun sistema de autorizacioacuten que permite tener una interfaz puacuteblica con ciertasgarantiacuteas de seguridad
Por su parte cada entorno de trabajo puede ser controlado por la CLI peroademaacutes cuenta con sus propias interfaces Marathon expone una API HTTPen el puerto 8080 de la direccioacuten puacuteblica de los maestros del cluster asiacute comootra interfaz graacutefica Para desplegar un contenedor se podriacutea usar la CLI
$ dcos marathon app add lt f i l e j songt
O la API HTTP
$ cu r l minusX POST http lt ip_maestro gt8080v2apps minusd ltf i l e jsongt minusH Contentminustype app l i c a t i o n j son
32
612 Nomad
La arquitectura de Nomad es maacutes sencilla ya que solo requiere de un ficheroejecutable en todos los nodos para funcionar Si DCOS es la base de instala-cioacuten de entornos de terceros Nomad integra todas las funcionalidades baacutesicasesto es gestor de recursos planificador y ejecutor en los nodos cliente Estaherramienta cuenta con un menor tiempo de desarrollo y en el momento deescribir este documento cuenta exclusivamente con los siguientes controladoresen comparacioacuten con los entornos de DCOS
Motor Docker es decir funcioacuten de orquestacioacuten de contenedores
Ejecucioacuten de archivos binarios como comandos de Shell
Ejecucioacuten de aplicaciones Java
Virtualizacioacuten de maacutequinas mediante tecnologiacutea QEMU
Todos ellos necesitan que la tecnologiacutea subyacente esteacute instalada en las maacute-quinas clientes (Docker Java QEMU) Actualmente no permite el registro decontroladores por parte de terceros aunque estaacute planificado en un futuro ofreceruna interfaz para su desarrollo
Nomad no cuenta con el servicio de descubrimiento sin embargo puede inte-grarse con la herramienta Consul desarrollada por la misma empresa Por otrolado para el balanceo de carga usaremos un contenedor Docker con HAProxyuna herramienta de coacutedigo abierto que ofrece tanto servicios de proxy como debalanceador y cuyos ficheros de configuracioacuten completaremos con el proyectoConsul Template19
Consul
Consul sigue la misma arquitectura que Nomad es decir un nodo servidorque orquesta un conjunto de maacutequinas clientes y permite a los procesos que seejecutan en los equipos definirlos como servicios ofreciendo diversas caracteriacutes-ticas entorno a estos de los cuales vamos a usar dos
Descubrimiento de servicio Las maacutequinas clientes publican en el cataacutelogode servicios las tareas en ejecucioacuten y Consul les asigna nombres de dominioaccesibles por todos los miembros del cluster a traveacutes de la interfaz DNSincluida en esta herramientaConsul se integra con Nomad de forma que todas las tareas que se ejecu-ten en la segunda son automaacuteticamente publicados como servicios de laprimera de esta manera no hace falta conocer la direccioacuten de la maacutequinacliente donde se esteacute ejecutando el proceso ya que se puede acceder a eacutela traveacutes de su nombre de dominio de forma transparente Por ejemplo si
19[httpsgithubcomhashicorpconsul-template]
33
ejecutamos una tarea con ID web en el puerto 8080 se puede acceder aella en la direccioacuten webserviceconsul8080Para que las direcciones propias de Consul las resuelva su propio DNS y noel que esteacute asignado por defecto en la maacutequina usaremos la herramientadnsmasq20 que permite especificar la direccioacuten de un servidor DNS paraconsultas de direcciones especiacuteficas
Monitorizacioacuten Permite realizar comprobaciones del servicio y seguir su esta-do Aprovecharemos esta funcionalidad tanto para definir el propio procesode Nomad como servicio de Consul como las tareas desplegadas
HAProxy + Consul Template
HAProxy es una solucioacuten versaacutetil de coacutedigo abierto que ofrece solucionesde balanceo de carga y proxy Existen otras herramientas en el mercado comoNGINX o ldirectord sin embargo HAProxy suponiacutea una solucioacuten sencilla deconfigurar para mostrar el caso de uso
El uso de estas herramientas se debe a dos motivos para que no existacontienda con respecto a los puertos de los clientes usados por las tareas eacutestos sevan a asignar de forma dinaacutemica lo que en principio implicariacutea que la aplicacioacutendeberiacutea realizar consultas DNS de tipo SRV (que incluye puertos) a la interfazde Consul y balancear la carga entre tareas por redundancia y capacidad
Como la direccioacuten IP y puerto son variables cada vez que las tareas seactualicen o se reasignen es necesario volver a configurar HAProxy de formamanual Por ello HashiCorp ha desarrollado un programa denominado Con-sul Template que realiza peticiones sucesivas a la interfaz HTTP de Consul delas direcciones fiacutesicas de un servicio y reinicia automaacuteticamente el proceso deHAProxy Asiacute definiendo estas tareas como servicios Consul podremos tantomonitorizarlas como escalar las tareas dinaacutemicamente sin necesidad de cambiarel balanceador A partir del contenedor Docker oficial de HAProxy se ha desa-rrollado otro con la configuracioacuten baacutesica y con Consul Template para desplegarlocomo una tarea en Nomad
Despliegue
Se ha usado el mismo coacutedigo que en el apartado anterior con la persistenciaen el servicio de almacenamiento de Azure Desde la perspectiva del hardwarese implementaraacute la misma infraestructura que en el caso de DCOS (figura 18)estos es definiremos dos tipos de maacutequinas clientes un agente que se conectaraacutecon el balanceador de carga con nombre de dominio puacuteblico y donde se desple-garaacute el balanceador de carga de la vista web y agentes privados no accesiblesdesde fuera del cluster y donde se ejecutaraacuten el resto de tareas en la red inter-na La principal diferencia radica en las tareas que ejecutan HAproxy y ConsulTemplate que sustituye a las direcciones IP virtuales que ofrece DCOS
20httpwwwthekelleysorgukdnsmasqdochtml
34
Figura 20 Despliegue en Azure de Nomad+Consul
Cabe matizar que los balanceadores basados en HAProxy se implementanpor necesidad de la aplicacioacuten para el descubrimiento del servicio a diferenciade los de Azure que se implementan por motivos de seguridad y escalabilidaddel cluster en siacute
Configuracioacuten Nomad
Los ficheros de configuracioacuten de las maacutequinas maacutester y cliente son similaresy comparten la mayoriacutea de las opciones como por ejemplo el nombre del nodoo la interfaz de red donde escucha Nomad las peticiones Sus opciones son engeneral auto-explicativas sin embargo existen dos detalles que matizar
El proceso de Nomad escucha las peticiones tanto de los protocolos deconsenso como del usuario a traveacutes de una interfaz de red que se debeindicar en el fichero de configuracioacuten
En el caso de los clientes se deben indicar las direcciones de los servidoresdel cluster sin embargo se trata de un sistema dinaacutemico en el que losnodos pueden sufrir errores y cambiar de direccioacuten Por ello se ha definidoNomad como un servicio de Consul y asiacute poder definir la direccioacuten de losservidores como un nombre de dominio no por su direccioacuten fiacutesica que elservidor DNS de Consul se encargaraacute de resolver
Por defecto Nomad usa los siguientes puertos
API HTTP 4646 Peticiones HTTP y recepcioacuten de oacuterdenes mediante laliacutenea de comandos
RPC 4647 Protocolo de consenso entre los nodos del cluster
Serf 4648 Protocolo de gossip entre los servidores de los centros de datosgobernados por Nomad
35
Los dos uacuteltimos deben ser interfaces alcanzables por otros nodos sin embargo laAPI HTTP por motivos de seguridad deberiacutea ser local ya que en caso contrariocualquier persona con acceso a ella tiene el control sobre la herramienta Eacutestasolo deberiacutea estar accesible en un servidor o gestionarlo mediante una terminalSSH por ejemplo En este trabajo al ser una prueba de concepto se ha abiertoen todos los nodos
Trabajos de Nomad
Las tareas se detallan en ficheros con formato HashiCorp Configuration Lan-guage un derivado del formato JSON creado por la empresa que le da nombrecompatible con eacuteste y que permite comentarios
En estos ficheros se puede definir
La regioacuten y el centro de datos donde se ejecutaraacute (Nomad permite lagestioacuten de centros de datos geograacuteficamente distribuidos en regiones)
La poliacutetica de actualizacioacuten de la tarea
Grupo de tareas esto es que se ejecutaraacuten en el mismo nodo
El nuacutemero de grupos a ejecutarescalar asiacute como los liacutemite que debencumplir los nodos asignados
La poliacutetica de reinicio ante fallo o error
Tareas El controlador su configuracioacuten los paraacutemetros del servicio aso-ciado a registrar en Consul asiacute como los recursos que consume (puertosmemoria)
En nuestro caso usamos sobre todo el controlador Docker esto eso orques-tacioacuten de contenedores en los nodos clientes y tres de sus opciones
Imagen del contenedor Se han subido todas las imaacutegenes del proyecto a Doc-ker Hub donde por defecto se busca la imagen
Puertos Los puertos a usar por el contenedor que pueden ser estaacuteticos asigna-dos por el usuario o dinaacutemicos siendo Nomad el que se encarga de mapearun puerto libre del nodo cliente al expuesto por el contenedor
Servidores DNS Como usamos la interfaz DNS de Consul como descubri-miento de servicio se debe configurar el contenedor para que use cualquiernodo del cluster como servidor DNS
Configuracioacuten Consul
Al ser desarrolladas por la misma empresa los ficheros de configuracioacuten deConsul y Nomad comparten muchas opciones Consul tambieacuten acepta peticionesa traveacutes de una interfaz de red siendo los puertos usados por defecto
36
RPC 8300 8400 Maneja la peticiones del resto de nodos y usuarios
Serf 8301 8302 Protocolo gossip
HTTP API 8500
HTTPS API Desactivada por defecto
Interfaz DNS 8600
Se debe asignar a los protocolos internos del cluster esto es RPC y Serf unainterfaz alcanzable por los nodos y por el contrarioasignar a los dos uacuteltimos ala interfaz de loopback por motivos de seguridad
Cabe destacar que Consul tambieacuten cuenta con una interfaz graacutefica que per-mite ver el estado de los equipos y los servicios registrados y que se encuentra enel mismo puerto que la API HTTP en la direccioacuten httpIP_EQUIPO8500ui
Ejecucioacuten
Tanto Nomad como Consul requieren de la ejecucioacuten de un fichero en todoslos nodos integrantes del cluster Como prueba de concepto se ha decidido usardos servidores para ambos aunque cabe matizar que es un nuacutemero ineficienteya que la caiacuteda de uno de ellos supondriacutea la peacuterdida del cuoacuterum y por tantodel consenso del cluster
En primer lugar se arrancan los servidores que son los encargados de ejecu-tar el protocolo de consenso y gestionar el cluster y a continuacioacuten los clientesque no tienen praacutecticamente estado y dependen de los servidores
En el caso de Consul se debe indicar el directorio donde se guardan losficheros que describen los servicios asiacute como el archivo que especifica el resto delas opciones
1 Se inicia el primer servidor en uno de los equipos
$ consu l agent minuscon f i gminusd i r e t c consu l d s e r v i c e s minuscon f i gminus f i l e consu l_server j son
2 Los siguientes equipos deben unirse al anterior por lo que antildeadimos elargumento join con la direccioacuten del primer servidor Para el caso de otrosservidores
$ consu l agent minuscon f i gminusd i r e t c consu l d s e r v i c e s minuscon f i gminus f i l e consu l_server j son minus j o i n ltIP_servidor1gt
37
Una vez los servidores han alcanzado el consenso y elegido un liacuteder en losclientes
$ consu l agent minuscon f i gminusd i r e t c consu l d s e r v i c e s minuscon f i gminus f i l e c on su l_c l i en t j son minus j o i n ltIP_cualquierServ idorgt
El proceso para iniciar Nomad es igual y los comandos similares sin embargoya no es necesario indicar una direccioacuten IP fija en los equipos sino el nombre dedominio del servicio de Nomad registrado por Consul En el primer servidor
$ nomad agent minusc on f i g nomad_server j son
Y el resto de equipos (con su fichero de configuracioacuten correspondiente)$ nomad agent minusc on f i g nomad_server j son minus j o i n nomad s e r v i c e consu l
Por uacuteltimo para desplegar la aplicacioacuten web se han escrito tres ficherosque detallan las tareas de la interfaz web API y los balanceadores de cargaMediante la CLI
$ nomad run minusaddress=http lt ip_c lus te r gt4646 lt f i l e hclgt
O mediante la API HTTP de Nomad$ cu r l minusX POST minusd ltf i l e hclgthttp lt ip_c lus te r gt4646 jobltjob_namegt
Ansible
Como se puede comprobar con el aumento del nuacutemero de equipos pasa aser inviable manejar todos los nodos a traveacutes de terminal Ademaacutes como seha comentado con anterioridad Nomad requiere que en los nodos clientes es-teacuten instalados las herramientas que soporten las tareas por ejemplo el motorde Docker Por ello para facilitar tanto el arranque como la instalacioacuten de lasdependencias vamos a usar Ansible una herramienta de coacutedigo abierto desarro-llada en Python que permite gestionar configuraciones aprovisionar recursosdespliegue de aplicaciones de forma automaacutetica
A grandes rasgos esta herramienta funciona mediante ficheros en formatoYAML denominados play-books que describen un conjunto de pasos a ejecutaren una lista de equipos remotos Estos pasos son ejecutados por moacutedulos inde-pendientes a traveacutes de SSH es decir en cualquier ordenador con conexioacuten a los
38
hosts dado su contrasentildea o clave puacuteblica puede arrancar el script y realizariacutealos pasos de forma remota gestionando el cluster desde un solo equipo
Se han desarrollado guiones para lo siguiente
Descarga de los binarios de Nomad y Consul en todos los nodos copiade los ficheros de configuracioacuten baacutesicos y modificarlos de acuerdo a cadanodo (nombre del equipo direccioacuten IP)
Instalacioacuten de las dependencias
Arranque de Nomad y Consul
Ansible extiende su funcionalidad a traveacutes de moacutedulos independientes que per-miten por ejemplo instalar paquetes mediante herramientas de gestioacuten de pa-quetes (APT yum) aprovisionar automaacuteticamente maacutequinas virtuales de Ama-zon EC2
Algunas opciones de los ficheros de configuracioacuten de Nomad y Consul sondependientes del nodo particular por ejemplo la interfaz de red Para estetrabajo se ha realizado un moacutedulo para modificar los ficheros de configuracioacutende forma automaacutetica En el repositorio del proyecto se encuentra una carpetadonde se encuentran todos los ficheros necesarios para desplegar un clustertotalmente funcional solo requiere de una liacutenea de terminal con Ansible
$ ans ib l eminusplaybook minus i hos t s minusk ltssh_passgt minusu ltnode_usergt s i t e yml
39
62 Servicio de integracioacuten continua
Se ha implementado un sistema de integracioacuten continua que permite ejecu-tar tareas de compilacioacuten y pruebas de forma distribuida aumentando asiacute elrendimiento de los equipos En primer lugar se detallaraacute los motivos por los quepuede resultar beneficioso para las empresas una implementacioacuten de este tipo alo que seguiraacute los detalles del despliegue
621 DevOps
Metodologiacutea que defiende la comunicacioacuten y colaboracioacuten entre desarrolla-dores de software y los profesionales de operaciones a lo largo de todo el ciclo devida de una aplicacioacuten Estaacute muy relacionado con el desarrollo aacutegil de softwareesto es un enfoque para los proyectos que defiende el desarrollo iterativo e in-cremental donde los requisitos y soluciones evolucionan con el tiempo seguacuten lanecesidad del proyecto DevOps extiende esta filosofiacutea a todas los componentesde un servicio incluyendo sistemas y operaciones
Se trata de un concepto que cada organizacioacuten o empresa adapta a suspropias necesidades y procesos de negocio en este proyecto nos vamos a centraren la integracioacuten continua una praacutectica fundamental tanto del desarrollo aacutegilcomo de esta filosofiacutea
622 Integracioacuten Continua
Se define como una praacutectica de desarrollo software donde los miembros delequipo ponen en comuacuten su trabajo frecuentemente al menos una vez al diacutea21Cada integracioacuten se verifica con una compilacioacuten automaacutetica que incluye laejecucioacuten de pruebas para detectar errores de integracioacuten tan pronto como seaposible
Desde el punto de vista operativo esto supone automatizar la configuracioacutende equipos o el despliegue de maacutequinas virtuales donde compilar el proyecto yejecutar las pruebas y posteriormente eliminarlas Este flujo de trabajo se vebeneficiado en entornos distribuidos ya que el objetivo del desarrollador es com-probar el resultado de las pruebas raacutepidamente sin preocuparse del despliegueo los propios equipos
Para esta prueba de concepto vamos a usar Jenkins un servidor de integra-cioacuten continua escrito en Java que nos permite definir trabajos que contendraacutenla descripcioacuten tanto del entorno como su ejecucioacuten
Este sigue una estructura maestro-esclavo muy similar al de los gestores declusters usados en este proyecto el maestro contiene toda la loacutegica del servicio
21httpmartinfowlercomarticlescontinuousIntegrationhtml
40
trabajos autenticacioacuten y los esclavos son los encargados de la ejecucioacuten ensiacute Jenkins tiene varias viacuteas para aprovisionar los uacuteltimos
Mediante SSH
Interfaz graacutefica
Desarrollar un script propio
Ejecucioacuten de un fichero java
La ventaja de usar planificadores es que el despliegue de esclavos es dinaacutemicoes decir no tener una maacutequina especiacuteficamente configurada para ello DCOS yNomad se encargaraacuten de configurar estos despliegues en sus maacutequinas y poste-riormente eliminarlos Para ello se ha usado la uacuteltima opcioacuten definiendo tareasque descarguen el fichero java Con todo ello se consigue un entorno de inte-gracioacuten continua eficiente que ademaacutes permite la ejecucioacuten de otros servicios deforma independiente
Jenkins permite la creacioacuten de plugins que extienden sus funcionalidadesTanto Nomad22 como Apache Mesos cuentan con uno que permite su integra-cioacuten
Para esta prueba se va a usar el mismo proyecto que para el caso de usode orquestacioacuten de contenedores la aplicacioacuten web al que se le ha antildeadido untest para comprobar que se conecta correctamente a la base de datos medianteMocha un framework de Nodejs Por otro lado se antildeade el plugin de git ya queel coacutedigo se obtiene de GitHub el repositorio remoto de control de versiones delproyecto
El proceso general de ejecucioacuten seriacutea como sigue
1 Se ejecuta el maestro de Jenkins como tarea Docker partiendo de la imagenoficial
2 Al arrancar un trabajo se manda una tarea a los planificadores que laasignaraacuten a un nodo cliente Esta tarea consiste en la descarga del ficherode configuracioacuten Java y arrancarlo configurando el equipo como un clientede Jenkins temporalmente
3 Jenkins ejecuta el trabajo en el nuevo cliente en este caso iniciar la apli-cacioacuten web iniciar las pruebas y generar un informe
4 Se elimina el cliente
A continuacioacuten se detallan los matices de cada herramienta a la hora de imple-mentar este servicio
22Desarrollado por Ivo Verberk httpwwwivoverberknl
41
623 Jenkins con Nomad
El plugin permite la ejecucioacuten del fichero Java mediante dos controladorescontenedores Docker y Java En este proyecto nos hemos decantado por el pri-mero ya que nos ahorra instalar la maacutequina virtual de java en todos los nodoscliente Por ello se ha construido un contenedor base con Java para la ejecucioacutendel fichero de configuracioacuten y Nodejs para lanzar la aplicacioacuten web
El plugin se configura con la direccioacuten IP del cluster y el contenedor queejecuta el esclavo Jenkins Por su parte el trabajo en Jenkins se define conel repositorio en GitHub donde se aloja el coacutedigo del proyecto a probar y loscomandos a ejecutar en este caso npm update y npm test
624 Jenkins con DCOS
En el caso de DCOS su sistema de paquetes incluye Jenkins por lo queal instalarlo ya se tiene la configuracioacuten de Mesos totalmente funcional Sinembargo para ejecutar la aplicacioacuten en particular y las pruebas se requiere deNodejs en los equipos esclavos por ello debemos antildeadir un plugin de Jenkinsque permite instalar este entorno antes de ejecutar el trabajo Una vez hechoesto soacutelo queda definir la tarea igual que en el caso anterior
Cabe destacar que Mesosphere tambieacuten ha desarrollado un plugin que per-mite hacer despliegues en Marathon de tal manera que permitiriacutea con cadacommit del coacutedigo compilar la imagen del contenedor Docker y desplegarlaautomaacuteticamente aunque en este proyecto no se ha hecho pruebas de esta fun-cionalidad
42
7 Escalando la infraestructura
Uno de los factores clave que se busca a la hora de implementar sistemasdistribuidos es el poder escalar la infraestructura de forma maacutes sencilla estoes detectar que las maacutequinas estaacuten alcanzando el liacutemite de su capacidad yaumentar eacutesta ya sea mejorando sus caracteriacutesticas teacutecnicas o antildeadiendo maacutesnodos al cluster
El coacutedigo y todos los ficheros de configuracioacuten de esta seccioacuten tambieacuten sepueden encontrar en el repositorio del proyecto en GitHub23
71 Disentildeo
Microsoft Azure permite organizar los servicios cloud de forma loacutegica a traveacutesde grupos de recursos y asiacute poder crear o eliminar eacutestos en conjunto parauna aplicacioacuten determinada (por ejemplo una aplicacioacuten web suele requerir demaacutequinas virtuales bases de datos almacenamiento) Ademaacutes dispone dela opcioacuten de crear plantillas en formato JSON que permite al desarrolladordefinir los recursos y su interrelacioacuten para desplegar de forma automaacutetica unainfraestructura TI en la nube
Azure tambieacuten ofrece la posibilidad de monitorizar el estado de las maacutequinasvirtuales a traveacutes de extensiones lo que permite configurar el escalado automaacute-tico al alcanzar cierto liacutemite definido por el operador Eacutesta es a priori la formaen que deberiacutea implementarse hablando en teacuterminos de eficiencia sin embargoesta aproximacioacuten es totalmente dependiente de la plataforma es decir no sepuede extrapolar a otro proveedor o sobre recursos propios sin realizar un nue-vo disentildeo En este proyecto las tareas que son ejecutadas por estos equipos notienen estado ya que todo lo relativo a la persistencia lo hemos asignado fueradel cluster esto permite escalar la plataforma a traveacutes de otra aproximaciones
Las plantillas aceptan una serie de variables a indicar por el usuario entreotras los conjuntos de escala para definir los nodos aceptan una variable quedefine el nuacutemero de maacutequinas que los componen Por otro lado Azure ofreceuna API REST y kits de desarrollo software (SDK por sus siglas en ingleacutes) quepermiten su despliegue de forma programaacutetica Aprovechando estas facilidadesen este proyecto se va a aproximar la escalabilidad con el sucesivo desplieguede la infraestructura de forma automaacutetica se monitorizan los equipos y si sedetecta una maacutequina excesivamente cargada se aumenta el nuacutemero de equiposen la plantilla y se vuelve a desplegar
23httpsgithubcomAntonioAlfrzCloud-Orchestrators
43
En este proyecto se han disentildeado las plantillas para desplegar la arquitec-tura necesaria tanto de Nomad como de DCOS En el caso de la primera eldespliegue es maacutes descriptivo ya que incluye maacutequinas virtuales grupos de se-guridad redes En el caso de DCOS Azure cuenta con un servicio especiacuteficopara clusters gobernados por DCOS denominado Azure Container Service queincluye los componentes necesarios y la instalacioacuten ya realizada
72 Implementacioacuten
En primer lugar para monitorizar el estado de los equipos se va a usar laherramienta Nagios un sistema que permite controlar el estado del hardwarey los servicios de un equipo Se trata de una herramienta muy completa de laque se va a usar su capacidad para ejecutar comandos (plugins) en los nodospara detectar picos de carga generar alertas y ejecutar programas para estoseventos
Se ha desplegado una maacutequina virtual con esta herramienta en ambos siste-mas y se ha instalado una extensioacuten de Nagios (Nagios Remote Plugin Executor)en todos los nodos que permite ejecutar comprobaciones remotamente en con-creto para esta prueba de concepto medir el nivel de saturacioacuten de la unidadcentral de procesamiento (CPU por sus siglas del ingleacutes) Cuando sucede uncambio de estado de una maacutequina esto es cuando este paraacutemetro supera el liacutemi-te definido por el operador Nagios permite actuar en consecuencia ejecutandoprogramas por ello se ha desarrollado un script que ejecuta lo siguiente
Un programa desarrollado en Python con el SDK de Azure que modificalas plantillas y despliega los recursos
Un guioacuten de Ansible para instalar todos los componentes necesarios en lasnuevas maacutequinas y arrancar de nuevo el cluster y las aplicaciones
44
8 Resultados y conclusiones
En este uacuteltimo apartado se da una visioacuten global del proyecto asiacute como a lasconclusiones maacutes importantes a las que se ha llegado y posibles temas futurosde desarrollo
81 Comparacioacuten
Ambas herramientas ofrecen las funcionalidades para gestionar los recursoseficientemente ofreciendo a los desarrolladores una plataforma donde desplegarsus aplicaciones de forma distribuida independientemente de los equipos fiacutesicosy el hardware que las soporten
DCOS es una herramienta que en un comienzo fue privativa pero cuyos res-ponsables la empresa Mesosphere decidieron publicar una versioacuten de coacutedigoEacutesta nos permite gestionar un cluster de una forma sencilla y usable ademaacutes decomplementarlo con otras herramientas como el balanceador de carga integradoo la autenticacioacuten de usuarios ademaacutes estaacute basada en Apache Mesos un pro-yecto de relativa madurez y con el soporte de la Apache Software FoundationDe forma resumida DCOS ofrece muchas posibilidades y servicios a cambiode una arquitectura e instalacioacuten maacutes compleja
Por su parte HashiCorp con menor tiempo de desarrollo ha conseguidouna herramienta muy sencilla de desplegar que ademaacutes cumple con todas lasfuncionalidades baacutesicas ejecutando un simple binario en cada nodo se puededesplegar un gestor de clusters totalmente funcional Sin embargo no cuentacon todas las posibilidades de Mesos (Nomad cuenta con menos controladoresque entornos posibles de Mesos) ni con los antildeadidos de DCOS lo que implicael uso de otras herramientas para complementar el servicio (Consul HAProxy)
De entre las dificultades encontradas al usar estas herramientas y desplegaraplicaciones sobre ellas se puede destacar la depuracioacuten en ocasiones se desco-noce si un error viene de la propia herramienta de la aplicacioacuten desplegada o delequipo fiacutesico si no se cuenta con un sistema de procesamiento de registro unose puede encontrar con muacuteltiples terminales abiertas inspeccionando numerososficheros de registro buscando posibles errores Ademaacutes no dejan de ser solucio-nes que para usar eficientemente se debe conocer parte de su funcionamientoy sintaxis a la hora de describir la tareas lo que supone un esfuerzo antildeadido yaque cada una tiene sus particularidades y liacutemites
45
82 Conclusiones
En una sociedad cada vez maacutes digital las empresas deben adaptarse a unmercado cuya demanda de contenido no deja de crecer Las nuevas arquitecturascomo microservicios asiacute como la gran cantidad de datos generada implica queuna mejor gestioacuten de los recursos y la rapidez para desplegar o escalar solucionesdando valor al cliente lo maacutes raacutepido posible es uno de los objetivos de todas lasempresas de base tecnoloacutegica
Las ventajas que ofrecen los planificadores con aplicaciones distribuidas sonnumerosas sin ir maacutes lejos empresas tan punteras como Google llevan maacutesde 10 antildeos orquestando contenedores24 Por un lado permiten aumentar elrendimiento de los equipos propios y por otro implementar un servicio comoplataforma para despliegues distribuidos sobre cualquier conjunto hardware deesta forma se provee un servicio similar al de la nube puacuteblica pero con laprincipal diferencia de que se elimina la independencia con el proveedor (vendorlock-in) esto es las aplicaciones no tienen limitaciones impuestas por eacuteste talescomo lenguaje de programacioacuten o herramientas y permite despliegues hiacutebridosentre recursos propios y la nube
83 Objetivos conseguidos
Implementacioacuten de los planificadores propuestos en la nube Se ha en-tendido y detallado el funcionamiento de estas herramientas y se hanimplementado en el servicio de infraestructura de Microsoft Azure
Despliegue de aplicaciones y servicios distribuidos Servicios que se usanactualmente en la industria del desarrollo software asiacute como una aplica-cioacuten web con una arquitectura moderna han sido desplegados de formadistribuida en los equipos cumpliendo con la funcionalidad esperada ade-maacutes de consiguiendo una alta disponibilidad
Aproximacioacuten de arquitectura escalable Se ha hecho una aproximacioacutende infraestructura escalable de forma que sea parcialmente extrapolable aotros proveedores
24httpwwwnextplatformcom20160322decade-container-control-google
46
84 Liacuteneas de investigacioacuten
Siguiendo con la materia de este proyecto se presentan posibles liacuteneas deinvestigacioacuten
Analizar el despliegue con estas herramientas de aplicaciones de Big Datay comparar la eficiencia con respecto a soluciones especializadas
Analizar el rendimiento de los algoritmos de planificacioacuten antes pruebasde estreacutes y situaciones de alta contienda
Comparar el uso de estas herramientas con las praacutecticas actuales de laindustria o implementacioacuten en un sistema de produccioacuten real
47
Referencias
[1] LA Barroso y U Houmllzle laquoThe Datacenter as a Computer An Introduc-tion to the Design of Warehouse-Scale Machinesraquo En Morgan amp ClaypoolPublishers ()
[2] Systems Research Group ndash NetOS (University of Cambridge) The evolu-tion of cluster scheduler architectures 2016 url httpswwwclcamacukresearchsrgnetoscamsasblog2016-03-09-scheduler-architectureshtml
[3] A Das I Gupta y A Motivala SWIM Scalable Weakly-consistent Infection-style Process Group Membership Protocol Inf teacutec Dept of ComputerScience Cornell University url https www cs cornell edu ~asdasresearchdsn02-swimpdf
[4] D Dubhashi y A Das Mastering Mesos PACKT Publishing mayo de2016
[5] The Apache Software Foundation Apache Mesos documentation urlhttpsmesosapacheorg
[6] David Greenberg Building Applications on Mesos OrsquoReilly Media 2016[7] Armand Grillet Comparison of Container Schedulers Inf teacutec Technische
Universitaumlt Berlin[8] HashiCorp Consul documentation url httpswwwconsulio[9] HashiCorp Nomad documentation url httpsdcosio[10] Dan C Marinescu Cloud computing theory and practice Morgan Kauf-
mann 2013[11] Mesosphere DCOS documentation url httpswwwnomadproject
io[12] Microsoft Azure documentation url httpsazuremicrosoftcom
es-esdocumentation[13] D Ongaro y J Ousterhout In Search of an Understandable Consensus
Algorithm Inf teacutec Stanford University url httpsraftgithubioraftpdf
[14] Fei Teng laquoRessource allocation and schelduling models for cloud compu-tingraquo Tesis de mtriacutea Ecole Centrale Paris 2011
[15] A Williams y col Automation and Orchestration with Docker and Contai-ners A Comprehensive Overview of the Docker and Container Ecosystem3 The New Stack 2016
48
- Resumen
- Summary
- Iacutendice de figuras
- Introduccioacuten y objetivos
-
- Contexto
- Objetivos
- Estructura del documento
-
- Cloud Computing
- Nuevas cargas de trabajo
- Gestioacuten de recursos Planificadores
-
- Sistemas distribuidos
-
- Clasificacioacuten
-
- Herramientas
-
- DCOS
-
- Apache Mesos
- Ejemplos de uso
-
- Nomad
-
- Protocolo de consenso Raft
- Protocolo gossip SWIM
- Planificacioacuten
-
- Casos de uso y despliegue
-
- Aplicacioacuten Web
-
- DCOS
- Nomad
-
- Servicio de integracioacuten continua
-
- DevOps
- Integracioacuten Continua
- Jenkins con Nomad
- Jenkins con DCOS
-
- Escalando la infraestructura
-
- Disentildeo
- Implementacioacuten
-
- Resultados y conclusiones
-
- Comparacioacuten
- Conclusiones
- Objetivos conseguidos
- Liacuteneas de investigacioacuten
-
Figura 19 Arquitectura de la aplicacioacuten web en DCOS
Ejecucioacuten
A la hora de desplegar la aplicacioacuten DCOS puede gestionarse medianteuna interfaz graacutefica o una interfaz de liacutenea de comandos La primera se accedea traveacutes de un navegador web en el puerto 80 (HTTP) y permite instalar losentornos disponibles observar el estado de los nodos y las tareas que se estaacutenejecutando y los ficheros de registros que eacutestas generan
La CLI permite el control desde un nodo o una maacutequina remota (suponiendoque los maestros tienen IP puacuteblica y el puerto 80 abierto) ya que DCOS tieneun sistema de autorizacioacuten que permite tener una interfaz puacuteblica con ciertasgarantiacuteas de seguridad
Por su parte cada entorno de trabajo puede ser controlado por la CLI peroademaacutes cuenta con sus propias interfaces Marathon expone una API HTTPen el puerto 8080 de la direccioacuten puacuteblica de los maestros del cluster asiacute comootra interfaz graacutefica Para desplegar un contenedor se podriacutea usar la CLI
$ dcos marathon app add lt f i l e j songt
O la API HTTP
$ cu r l minusX POST http lt ip_maestro gt8080v2apps minusd ltf i l e jsongt minusH Contentminustype app l i c a t i o n j son
32
612 Nomad
La arquitectura de Nomad es maacutes sencilla ya que solo requiere de un ficheroejecutable en todos los nodos para funcionar Si DCOS es la base de instala-cioacuten de entornos de terceros Nomad integra todas las funcionalidades baacutesicasesto es gestor de recursos planificador y ejecutor en los nodos cliente Estaherramienta cuenta con un menor tiempo de desarrollo y en el momento deescribir este documento cuenta exclusivamente con los siguientes controladoresen comparacioacuten con los entornos de DCOS
Motor Docker es decir funcioacuten de orquestacioacuten de contenedores
Ejecucioacuten de archivos binarios como comandos de Shell
Ejecucioacuten de aplicaciones Java
Virtualizacioacuten de maacutequinas mediante tecnologiacutea QEMU
Todos ellos necesitan que la tecnologiacutea subyacente esteacute instalada en las maacute-quinas clientes (Docker Java QEMU) Actualmente no permite el registro decontroladores por parte de terceros aunque estaacute planificado en un futuro ofreceruna interfaz para su desarrollo
Nomad no cuenta con el servicio de descubrimiento sin embargo puede inte-grarse con la herramienta Consul desarrollada por la misma empresa Por otrolado para el balanceo de carga usaremos un contenedor Docker con HAProxyuna herramienta de coacutedigo abierto que ofrece tanto servicios de proxy como debalanceador y cuyos ficheros de configuracioacuten completaremos con el proyectoConsul Template19
Consul
Consul sigue la misma arquitectura que Nomad es decir un nodo servidorque orquesta un conjunto de maacutequinas clientes y permite a los procesos que seejecutan en los equipos definirlos como servicios ofreciendo diversas caracteriacutes-ticas entorno a estos de los cuales vamos a usar dos
Descubrimiento de servicio Las maacutequinas clientes publican en el cataacutelogode servicios las tareas en ejecucioacuten y Consul les asigna nombres de dominioaccesibles por todos los miembros del cluster a traveacutes de la interfaz DNSincluida en esta herramientaConsul se integra con Nomad de forma que todas las tareas que se ejecu-ten en la segunda son automaacuteticamente publicados como servicios de laprimera de esta manera no hace falta conocer la direccioacuten de la maacutequinacliente donde se esteacute ejecutando el proceso ya que se puede acceder a eacutela traveacutes de su nombre de dominio de forma transparente Por ejemplo si
19[httpsgithubcomhashicorpconsul-template]
33
ejecutamos una tarea con ID web en el puerto 8080 se puede acceder aella en la direccioacuten webserviceconsul8080Para que las direcciones propias de Consul las resuelva su propio DNS y noel que esteacute asignado por defecto en la maacutequina usaremos la herramientadnsmasq20 que permite especificar la direccioacuten de un servidor DNS paraconsultas de direcciones especiacuteficas
Monitorizacioacuten Permite realizar comprobaciones del servicio y seguir su esta-do Aprovecharemos esta funcionalidad tanto para definir el propio procesode Nomad como servicio de Consul como las tareas desplegadas
HAProxy + Consul Template
HAProxy es una solucioacuten versaacutetil de coacutedigo abierto que ofrece solucionesde balanceo de carga y proxy Existen otras herramientas en el mercado comoNGINX o ldirectord sin embargo HAProxy suponiacutea una solucioacuten sencilla deconfigurar para mostrar el caso de uso
El uso de estas herramientas se debe a dos motivos para que no existacontienda con respecto a los puertos de los clientes usados por las tareas eacutestos sevan a asignar de forma dinaacutemica lo que en principio implicariacutea que la aplicacioacutendeberiacutea realizar consultas DNS de tipo SRV (que incluye puertos) a la interfazde Consul y balancear la carga entre tareas por redundancia y capacidad
Como la direccioacuten IP y puerto son variables cada vez que las tareas seactualicen o se reasignen es necesario volver a configurar HAProxy de formamanual Por ello HashiCorp ha desarrollado un programa denominado Con-sul Template que realiza peticiones sucesivas a la interfaz HTTP de Consul delas direcciones fiacutesicas de un servicio y reinicia automaacuteticamente el proceso deHAProxy Asiacute definiendo estas tareas como servicios Consul podremos tantomonitorizarlas como escalar las tareas dinaacutemicamente sin necesidad de cambiarel balanceador A partir del contenedor Docker oficial de HAProxy se ha desa-rrollado otro con la configuracioacuten baacutesica y con Consul Template para desplegarlocomo una tarea en Nomad
Despliegue
Se ha usado el mismo coacutedigo que en el apartado anterior con la persistenciaen el servicio de almacenamiento de Azure Desde la perspectiva del hardwarese implementaraacute la misma infraestructura que en el caso de DCOS (figura 18)estos es definiremos dos tipos de maacutequinas clientes un agente que se conectaraacutecon el balanceador de carga con nombre de dominio puacuteblico y donde se desple-garaacute el balanceador de carga de la vista web y agentes privados no accesiblesdesde fuera del cluster y donde se ejecutaraacuten el resto de tareas en la red inter-na La principal diferencia radica en las tareas que ejecutan HAproxy y ConsulTemplate que sustituye a las direcciones IP virtuales que ofrece DCOS
20httpwwwthekelleysorgukdnsmasqdochtml
34
Figura 20 Despliegue en Azure de Nomad+Consul
Cabe matizar que los balanceadores basados en HAProxy se implementanpor necesidad de la aplicacioacuten para el descubrimiento del servicio a diferenciade los de Azure que se implementan por motivos de seguridad y escalabilidaddel cluster en siacute
Configuracioacuten Nomad
Los ficheros de configuracioacuten de las maacutequinas maacutester y cliente son similaresy comparten la mayoriacutea de las opciones como por ejemplo el nombre del nodoo la interfaz de red donde escucha Nomad las peticiones Sus opciones son engeneral auto-explicativas sin embargo existen dos detalles que matizar
El proceso de Nomad escucha las peticiones tanto de los protocolos deconsenso como del usuario a traveacutes de una interfaz de red que se debeindicar en el fichero de configuracioacuten
En el caso de los clientes se deben indicar las direcciones de los servidoresdel cluster sin embargo se trata de un sistema dinaacutemico en el que losnodos pueden sufrir errores y cambiar de direccioacuten Por ello se ha definidoNomad como un servicio de Consul y asiacute poder definir la direccioacuten de losservidores como un nombre de dominio no por su direccioacuten fiacutesica que elservidor DNS de Consul se encargaraacute de resolver
Por defecto Nomad usa los siguientes puertos
API HTTP 4646 Peticiones HTTP y recepcioacuten de oacuterdenes mediante laliacutenea de comandos
RPC 4647 Protocolo de consenso entre los nodos del cluster
Serf 4648 Protocolo de gossip entre los servidores de los centros de datosgobernados por Nomad
35
Los dos uacuteltimos deben ser interfaces alcanzables por otros nodos sin embargo laAPI HTTP por motivos de seguridad deberiacutea ser local ya que en caso contrariocualquier persona con acceso a ella tiene el control sobre la herramienta Eacutestasolo deberiacutea estar accesible en un servidor o gestionarlo mediante una terminalSSH por ejemplo En este trabajo al ser una prueba de concepto se ha abiertoen todos los nodos
Trabajos de Nomad
Las tareas se detallan en ficheros con formato HashiCorp Configuration Lan-guage un derivado del formato JSON creado por la empresa que le da nombrecompatible con eacuteste y que permite comentarios
En estos ficheros se puede definir
La regioacuten y el centro de datos donde se ejecutaraacute (Nomad permite lagestioacuten de centros de datos geograacuteficamente distribuidos en regiones)
La poliacutetica de actualizacioacuten de la tarea
Grupo de tareas esto es que se ejecutaraacuten en el mismo nodo
El nuacutemero de grupos a ejecutarescalar asiacute como los liacutemite que debencumplir los nodos asignados
La poliacutetica de reinicio ante fallo o error
Tareas El controlador su configuracioacuten los paraacutemetros del servicio aso-ciado a registrar en Consul asiacute como los recursos que consume (puertosmemoria)
En nuestro caso usamos sobre todo el controlador Docker esto eso orques-tacioacuten de contenedores en los nodos clientes y tres de sus opciones
Imagen del contenedor Se han subido todas las imaacutegenes del proyecto a Doc-ker Hub donde por defecto se busca la imagen
Puertos Los puertos a usar por el contenedor que pueden ser estaacuteticos asigna-dos por el usuario o dinaacutemicos siendo Nomad el que se encarga de mapearun puerto libre del nodo cliente al expuesto por el contenedor
Servidores DNS Como usamos la interfaz DNS de Consul como descubri-miento de servicio se debe configurar el contenedor para que use cualquiernodo del cluster como servidor DNS
Configuracioacuten Consul
Al ser desarrolladas por la misma empresa los ficheros de configuracioacuten deConsul y Nomad comparten muchas opciones Consul tambieacuten acepta peticionesa traveacutes de una interfaz de red siendo los puertos usados por defecto
36
RPC 8300 8400 Maneja la peticiones del resto de nodos y usuarios
Serf 8301 8302 Protocolo gossip
HTTP API 8500
HTTPS API Desactivada por defecto
Interfaz DNS 8600
Se debe asignar a los protocolos internos del cluster esto es RPC y Serf unainterfaz alcanzable por los nodos y por el contrarioasignar a los dos uacuteltimos ala interfaz de loopback por motivos de seguridad
Cabe destacar que Consul tambieacuten cuenta con una interfaz graacutefica que per-mite ver el estado de los equipos y los servicios registrados y que se encuentra enel mismo puerto que la API HTTP en la direccioacuten httpIP_EQUIPO8500ui
Ejecucioacuten
Tanto Nomad como Consul requieren de la ejecucioacuten de un fichero en todoslos nodos integrantes del cluster Como prueba de concepto se ha decidido usardos servidores para ambos aunque cabe matizar que es un nuacutemero ineficienteya que la caiacuteda de uno de ellos supondriacutea la peacuterdida del cuoacuterum y por tantodel consenso del cluster
En primer lugar se arrancan los servidores que son los encargados de ejecu-tar el protocolo de consenso y gestionar el cluster y a continuacioacuten los clientesque no tienen praacutecticamente estado y dependen de los servidores
En el caso de Consul se debe indicar el directorio donde se guardan losficheros que describen los servicios asiacute como el archivo que especifica el resto delas opciones
1 Se inicia el primer servidor en uno de los equipos
$ consu l agent minuscon f i gminusd i r e t c consu l d s e r v i c e s minuscon f i gminus f i l e consu l_server j son
2 Los siguientes equipos deben unirse al anterior por lo que antildeadimos elargumento join con la direccioacuten del primer servidor Para el caso de otrosservidores
$ consu l agent minuscon f i gminusd i r e t c consu l d s e r v i c e s minuscon f i gminus f i l e consu l_server j son minus j o i n ltIP_servidor1gt
37
Una vez los servidores han alcanzado el consenso y elegido un liacuteder en losclientes
$ consu l agent minuscon f i gminusd i r e t c consu l d s e r v i c e s minuscon f i gminus f i l e c on su l_c l i en t j son minus j o i n ltIP_cualquierServ idorgt
El proceso para iniciar Nomad es igual y los comandos similares sin embargoya no es necesario indicar una direccioacuten IP fija en los equipos sino el nombre dedominio del servicio de Nomad registrado por Consul En el primer servidor
$ nomad agent minusc on f i g nomad_server j son
Y el resto de equipos (con su fichero de configuracioacuten correspondiente)$ nomad agent minusc on f i g nomad_server j son minus j o i n nomad s e r v i c e consu l
Por uacuteltimo para desplegar la aplicacioacuten web se han escrito tres ficherosque detallan las tareas de la interfaz web API y los balanceadores de cargaMediante la CLI
$ nomad run minusaddress=http lt ip_c lus te r gt4646 lt f i l e hclgt
O mediante la API HTTP de Nomad$ cu r l minusX POST minusd ltf i l e hclgthttp lt ip_c lus te r gt4646 jobltjob_namegt
Ansible
Como se puede comprobar con el aumento del nuacutemero de equipos pasa aser inviable manejar todos los nodos a traveacutes de terminal Ademaacutes como seha comentado con anterioridad Nomad requiere que en los nodos clientes es-teacuten instalados las herramientas que soporten las tareas por ejemplo el motorde Docker Por ello para facilitar tanto el arranque como la instalacioacuten de lasdependencias vamos a usar Ansible una herramienta de coacutedigo abierto desarro-llada en Python que permite gestionar configuraciones aprovisionar recursosdespliegue de aplicaciones de forma automaacutetica
A grandes rasgos esta herramienta funciona mediante ficheros en formatoYAML denominados play-books que describen un conjunto de pasos a ejecutaren una lista de equipos remotos Estos pasos son ejecutados por moacutedulos inde-pendientes a traveacutes de SSH es decir en cualquier ordenador con conexioacuten a los
38
hosts dado su contrasentildea o clave puacuteblica puede arrancar el script y realizariacutealos pasos de forma remota gestionando el cluster desde un solo equipo
Se han desarrollado guiones para lo siguiente
Descarga de los binarios de Nomad y Consul en todos los nodos copiade los ficheros de configuracioacuten baacutesicos y modificarlos de acuerdo a cadanodo (nombre del equipo direccioacuten IP)
Instalacioacuten de las dependencias
Arranque de Nomad y Consul
Ansible extiende su funcionalidad a traveacutes de moacutedulos independientes que per-miten por ejemplo instalar paquetes mediante herramientas de gestioacuten de pa-quetes (APT yum) aprovisionar automaacuteticamente maacutequinas virtuales de Ama-zon EC2
Algunas opciones de los ficheros de configuracioacuten de Nomad y Consul sondependientes del nodo particular por ejemplo la interfaz de red Para estetrabajo se ha realizado un moacutedulo para modificar los ficheros de configuracioacutende forma automaacutetica En el repositorio del proyecto se encuentra una carpetadonde se encuentran todos los ficheros necesarios para desplegar un clustertotalmente funcional solo requiere de una liacutenea de terminal con Ansible
$ ans ib l eminusplaybook minus i hos t s minusk ltssh_passgt minusu ltnode_usergt s i t e yml
39
62 Servicio de integracioacuten continua
Se ha implementado un sistema de integracioacuten continua que permite ejecu-tar tareas de compilacioacuten y pruebas de forma distribuida aumentando asiacute elrendimiento de los equipos En primer lugar se detallaraacute los motivos por los quepuede resultar beneficioso para las empresas una implementacioacuten de este tipo alo que seguiraacute los detalles del despliegue
621 DevOps
Metodologiacutea que defiende la comunicacioacuten y colaboracioacuten entre desarrolla-dores de software y los profesionales de operaciones a lo largo de todo el ciclo devida de una aplicacioacuten Estaacute muy relacionado con el desarrollo aacutegil de softwareesto es un enfoque para los proyectos que defiende el desarrollo iterativo e in-cremental donde los requisitos y soluciones evolucionan con el tiempo seguacuten lanecesidad del proyecto DevOps extiende esta filosofiacutea a todas los componentesde un servicio incluyendo sistemas y operaciones
Se trata de un concepto que cada organizacioacuten o empresa adapta a suspropias necesidades y procesos de negocio en este proyecto nos vamos a centraren la integracioacuten continua una praacutectica fundamental tanto del desarrollo aacutegilcomo de esta filosofiacutea
622 Integracioacuten Continua
Se define como una praacutectica de desarrollo software donde los miembros delequipo ponen en comuacuten su trabajo frecuentemente al menos una vez al diacutea21Cada integracioacuten se verifica con una compilacioacuten automaacutetica que incluye laejecucioacuten de pruebas para detectar errores de integracioacuten tan pronto como seaposible
Desde el punto de vista operativo esto supone automatizar la configuracioacutende equipos o el despliegue de maacutequinas virtuales donde compilar el proyecto yejecutar las pruebas y posteriormente eliminarlas Este flujo de trabajo se vebeneficiado en entornos distribuidos ya que el objetivo del desarrollador es com-probar el resultado de las pruebas raacutepidamente sin preocuparse del despliegueo los propios equipos
Para esta prueba de concepto vamos a usar Jenkins un servidor de integra-cioacuten continua escrito en Java que nos permite definir trabajos que contendraacutenla descripcioacuten tanto del entorno como su ejecucioacuten
Este sigue una estructura maestro-esclavo muy similar al de los gestores declusters usados en este proyecto el maestro contiene toda la loacutegica del servicio
21httpmartinfowlercomarticlescontinuousIntegrationhtml
40
trabajos autenticacioacuten y los esclavos son los encargados de la ejecucioacuten ensiacute Jenkins tiene varias viacuteas para aprovisionar los uacuteltimos
Mediante SSH
Interfaz graacutefica
Desarrollar un script propio
Ejecucioacuten de un fichero java
La ventaja de usar planificadores es que el despliegue de esclavos es dinaacutemicoes decir no tener una maacutequina especiacuteficamente configurada para ello DCOS yNomad se encargaraacuten de configurar estos despliegues en sus maacutequinas y poste-riormente eliminarlos Para ello se ha usado la uacuteltima opcioacuten definiendo tareasque descarguen el fichero java Con todo ello se consigue un entorno de inte-gracioacuten continua eficiente que ademaacutes permite la ejecucioacuten de otros servicios deforma independiente
Jenkins permite la creacioacuten de plugins que extienden sus funcionalidadesTanto Nomad22 como Apache Mesos cuentan con uno que permite su integra-cioacuten
Para esta prueba se va a usar el mismo proyecto que para el caso de usode orquestacioacuten de contenedores la aplicacioacuten web al que se le ha antildeadido untest para comprobar que se conecta correctamente a la base de datos medianteMocha un framework de Nodejs Por otro lado se antildeade el plugin de git ya queel coacutedigo se obtiene de GitHub el repositorio remoto de control de versiones delproyecto
El proceso general de ejecucioacuten seriacutea como sigue
1 Se ejecuta el maestro de Jenkins como tarea Docker partiendo de la imagenoficial
2 Al arrancar un trabajo se manda una tarea a los planificadores que laasignaraacuten a un nodo cliente Esta tarea consiste en la descarga del ficherode configuracioacuten Java y arrancarlo configurando el equipo como un clientede Jenkins temporalmente
3 Jenkins ejecuta el trabajo en el nuevo cliente en este caso iniciar la apli-cacioacuten web iniciar las pruebas y generar un informe
4 Se elimina el cliente
A continuacioacuten se detallan los matices de cada herramienta a la hora de imple-mentar este servicio
22Desarrollado por Ivo Verberk httpwwwivoverberknl
41
623 Jenkins con Nomad
El plugin permite la ejecucioacuten del fichero Java mediante dos controladorescontenedores Docker y Java En este proyecto nos hemos decantado por el pri-mero ya que nos ahorra instalar la maacutequina virtual de java en todos los nodoscliente Por ello se ha construido un contenedor base con Java para la ejecucioacutendel fichero de configuracioacuten y Nodejs para lanzar la aplicacioacuten web
El plugin se configura con la direccioacuten IP del cluster y el contenedor queejecuta el esclavo Jenkins Por su parte el trabajo en Jenkins se define conel repositorio en GitHub donde se aloja el coacutedigo del proyecto a probar y loscomandos a ejecutar en este caso npm update y npm test
624 Jenkins con DCOS
En el caso de DCOS su sistema de paquetes incluye Jenkins por lo queal instalarlo ya se tiene la configuracioacuten de Mesos totalmente funcional Sinembargo para ejecutar la aplicacioacuten en particular y las pruebas se requiere deNodejs en los equipos esclavos por ello debemos antildeadir un plugin de Jenkinsque permite instalar este entorno antes de ejecutar el trabajo Una vez hechoesto soacutelo queda definir la tarea igual que en el caso anterior
Cabe destacar que Mesosphere tambieacuten ha desarrollado un plugin que per-mite hacer despliegues en Marathon de tal manera que permitiriacutea con cadacommit del coacutedigo compilar la imagen del contenedor Docker y desplegarlaautomaacuteticamente aunque en este proyecto no se ha hecho pruebas de esta fun-cionalidad
42
7 Escalando la infraestructura
Uno de los factores clave que se busca a la hora de implementar sistemasdistribuidos es el poder escalar la infraestructura de forma maacutes sencilla estoes detectar que las maacutequinas estaacuten alcanzando el liacutemite de su capacidad yaumentar eacutesta ya sea mejorando sus caracteriacutesticas teacutecnicas o antildeadiendo maacutesnodos al cluster
El coacutedigo y todos los ficheros de configuracioacuten de esta seccioacuten tambieacuten sepueden encontrar en el repositorio del proyecto en GitHub23
71 Disentildeo
Microsoft Azure permite organizar los servicios cloud de forma loacutegica a traveacutesde grupos de recursos y asiacute poder crear o eliminar eacutestos en conjunto parauna aplicacioacuten determinada (por ejemplo una aplicacioacuten web suele requerir demaacutequinas virtuales bases de datos almacenamiento) Ademaacutes dispone dela opcioacuten de crear plantillas en formato JSON que permite al desarrolladordefinir los recursos y su interrelacioacuten para desplegar de forma automaacutetica unainfraestructura TI en la nube
Azure tambieacuten ofrece la posibilidad de monitorizar el estado de las maacutequinasvirtuales a traveacutes de extensiones lo que permite configurar el escalado automaacute-tico al alcanzar cierto liacutemite definido por el operador Eacutesta es a priori la formaen que deberiacutea implementarse hablando en teacuterminos de eficiencia sin embargoesta aproximacioacuten es totalmente dependiente de la plataforma es decir no sepuede extrapolar a otro proveedor o sobre recursos propios sin realizar un nue-vo disentildeo En este proyecto las tareas que son ejecutadas por estos equipos notienen estado ya que todo lo relativo a la persistencia lo hemos asignado fueradel cluster esto permite escalar la plataforma a traveacutes de otra aproximaciones
Las plantillas aceptan una serie de variables a indicar por el usuario entreotras los conjuntos de escala para definir los nodos aceptan una variable quedefine el nuacutemero de maacutequinas que los componen Por otro lado Azure ofreceuna API REST y kits de desarrollo software (SDK por sus siglas en ingleacutes) quepermiten su despliegue de forma programaacutetica Aprovechando estas facilidadesen este proyecto se va a aproximar la escalabilidad con el sucesivo desplieguede la infraestructura de forma automaacutetica se monitorizan los equipos y si sedetecta una maacutequina excesivamente cargada se aumenta el nuacutemero de equiposen la plantilla y se vuelve a desplegar
23httpsgithubcomAntonioAlfrzCloud-Orchestrators
43
En este proyecto se han disentildeado las plantillas para desplegar la arquitec-tura necesaria tanto de Nomad como de DCOS En el caso de la primera eldespliegue es maacutes descriptivo ya que incluye maacutequinas virtuales grupos de se-guridad redes En el caso de DCOS Azure cuenta con un servicio especiacuteficopara clusters gobernados por DCOS denominado Azure Container Service queincluye los componentes necesarios y la instalacioacuten ya realizada
72 Implementacioacuten
En primer lugar para monitorizar el estado de los equipos se va a usar laherramienta Nagios un sistema que permite controlar el estado del hardwarey los servicios de un equipo Se trata de una herramienta muy completa de laque se va a usar su capacidad para ejecutar comandos (plugins) en los nodospara detectar picos de carga generar alertas y ejecutar programas para estoseventos
Se ha desplegado una maacutequina virtual con esta herramienta en ambos siste-mas y se ha instalado una extensioacuten de Nagios (Nagios Remote Plugin Executor)en todos los nodos que permite ejecutar comprobaciones remotamente en con-creto para esta prueba de concepto medir el nivel de saturacioacuten de la unidadcentral de procesamiento (CPU por sus siglas del ingleacutes) Cuando sucede uncambio de estado de una maacutequina esto es cuando este paraacutemetro supera el liacutemi-te definido por el operador Nagios permite actuar en consecuencia ejecutandoprogramas por ello se ha desarrollado un script que ejecuta lo siguiente
Un programa desarrollado en Python con el SDK de Azure que modificalas plantillas y despliega los recursos
Un guioacuten de Ansible para instalar todos los componentes necesarios en lasnuevas maacutequinas y arrancar de nuevo el cluster y las aplicaciones
44
8 Resultados y conclusiones
En este uacuteltimo apartado se da una visioacuten global del proyecto asiacute como a lasconclusiones maacutes importantes a las que se ha llegado y posibles temas futurosde desarrollo
81 Comparacioacuten
Ambas herramientas ofrecen las funcionalidades para gestionar los recursoseficientemente ofreciendo a los desarrolladores una plataforma donde desplegarsus aplicaciones de forma distribuida independientemente de los equipos fiacutesicosy el hardware que las soporten
DCOS es una herramienta que en un comienzo fue privativa pero cuyos res-ponsables la empresa Mesosphere decidieron publicar una versioacuten de coacutedigoEacutesta nos permite gestionar un cluster de una forma sencilla y usable ademaacutes decomplementarlo con otras herramientas como el balanceador de carga integradoo la autenticacioacuten de usuarios ademaacutes estaacute basada en Apache Mesos un pro-yecto de relativa madurez y con el soporte de la Apache Software FoundationDe forma resumida DCOS ofrece muchas posibilidades y servicios a cambiode una arquitectura e instalacioacuten maacutes compleja
Por su parte HashiCorp con menor tiempo de desarrollo ha conseguidouna herramienta muy sencilla de desplegar que ademaacutes cumple con todas lasfuncionalidades baacutesicas ejecutando un simple binario en cada nodo se puededesplegar un gestor de clusters totalmente funcional Sin embargo no cuentacon todas las posibilidades de Mesos (Nomad cuenta con menos controladoresque entornos posibles de Mesos) ni con los antildeadidos de DCOS lo que implicael uso de otras herramientas para complementar el servicio (Consul HAProxy)
De entre las dificultades encontradas al usar estas herramientas y desplegaraplicaciones sobre ellas se puede destacar la depuracioacuten en ocasiones se desco-noce si un error viene de la propia herramienta de la aplicacioacuten desplegada o delequipo fiacutesico si no se cuenta con un sistema de procesamiento de registro unose puede encontrar con muacuteltiples terminales abiertas inspeccionando numerososficheros de registro buscando posibles errores Ademaacutes no dejan de ser solucio-nes que para usar eficientemente se debe conocer parte de su funcionamientoy sintaxis a la hora de describir la tareas lo que supone un esfuerzo antildeadido yaque cada una tiene sus particularidades y liacutemites
45
82 Conclusiones
En una sociedad cada vez maacutes digital las empresas deben adaptarse a unmercado cuya demanda de contenido no deja de crecer Las nuevas arquitecturascomo microservicios asiacute como la gran cantidad de datos generada implica queuna mejor gestioacuten de los recursos y la rapidez para desplegar o escalar solucionesdando valor al cliente lo maacutes raacutepido posible es uno de los objetivos de todas lasempresas de base tecnoloacutegica
Las ventajas que ofrecen los planificadores con aplicaciones distribuidas sonnumerosas sin ir maacutes lejos empresas tan punteras como Google llevan maacutesde 10 antildeos orquestando contenedores24 Por un lado permiten aumentar elrendimiento de los equipos propios y por otro implementar un servicio comoplataforma para despliegues distribuidos sobre cualquier conjunto hardware deesta forma se provee un servicio similar al de la nube puacuteblica pero con laprincipal diferencia de que se elimina la independencia con el proveedor (vendorlock-in) esto es las aplicaciones no tienen limitaciones impuestas por eacuteste talescomo lenguaje de programacioacuten o herramientas y permite despliegues hiacutebridosentre recursos propios y la nube
83 Objetivos conseguidos
Implementacioacuten de los planificadores propuestos en la nube Se ha en-tendido y detallado el funcionamiento de estas herramientas y se hanimplementado en el servicio de infraestructura de Microsoft Azure
Despliegue de aplicaciones y servicios distribuidos Servicios que se usanactualmente en la industria del desarrollo software asiacute como una aplica-cioacuten web con una arquitectura moderna han sido desplegados de formadistribuida en los equipos cumpliendo con la funcionalidad esperada ade-maacutes de consiguiendo una alta disponibilidad
Aproximacioacuten de arquitectura escalable Se ha hecho una aproximacioacutende infraestructura escalable de forma que sea parcialmente extrapolable aotros proveedores
24httpwwwnextplatformcom20160322decade-container-control-google
46
84 Liacuteneas de investigacioacuten
Siguiendo con la materia de este proyecto se presentan posibles liacuteneas deinvestigacioacuten
Analizar el despliegue con estas herramientas de aplicaciones de Big Datay comparar la eficiencia con respecto a soluciones especializadas
Analizar el rendimiento de los algoritmos de planificacioacuten antes pruebasde estreacutes y situaciones de alta contienda
Comparar el uso de estas herramientas con las praacutecticas actuales de laindustria o implementacioacuten en un sistema de produccioacuten real
47
Referencias
[1] LA Barroso y U Houmllzle laquoThe Datacenter as a Computer An Introduc-tion to the Design of Warehouse-Scale Machinesraquo En Morgan amp ClaypoolPublishers ()
[2] Systems Research Group ndash NetOS (University of Cambridge) The evolu-tion of cluster scheduler architectures 2016 url httpswwwclcamacukresearchsrgnetoscamsasblog2016-03-09-scheduler-architectureshtml
[3] A Das I Gupta y A Motivala SWIM Scalable Weakly-consistent Infection-style Process Group Membership Protocol Inf teacutec Dept of ComputerScience Cornell University url https www cs cornell edu ~asdasresearchdsn02-swimpdf
[4] D Dubhashi y A Das Mastering Mesos PACKT Publishing mayo de2016
[5] The Apache Software Foundation Apache Mesos documentation urlhttpsmesosapacheorg
[6] David Greenberg Building Applications on Mesos OrsquoReilly Media 2016[7] Armand Grillet Comparison of Container Schedulers Inf teacutec Technische
Universitaumlt Berlin[8] HashiCorp Consul documentation url httpswwwconsulio[9] HashiCorp Nomad documentation url httpsdcosio[10] Dan C Marinescu Cloud computing theory and practice Morgan Kauf-
mann 2013[11] Mesosphere DCOS documentation url httpswwwnomadproject
io[12] Microsoft Azure documentation url httpsazuremicrosoftcom
es-esdocumentation[13] D Ongaro y J Ousterhout In Search of an Understandable Consensus
Algorithm Inf teacutec Stanford University url httpsraftgithubioraftpdf
[14] Fei Teng laquoRessource allocation and schelduling models for cloud compu-tingraquo Tesis de mtriacutea Ecole Centrale Paris 2011
[15] A Williams y col Automation and Orchestration with Docker and Contai-ners A Comprehensive Overview of the Docker and Container Ecosystem3 The New Stack 2016
48
- Resumen
- Summary
- Iacutendice de figuras
- Introduccioacuten y objetivos
-
- Contexto
- Objetivos
- Estructura del documento
-
- Cloud Computing
- Nuevas cargas de trabajo
- Gestioacuten de recursos Planificadores
-
- Sistemas distribuidos
-
- Clasificacioacuten
-
- Herramientas
-
- DCOS
-
- Apache Mesos
- Ejemplos de uso
-
- Nomad
-
- Protocolo de consenso Raft
- Protocolo gossip SWIM
- Planificacioacuten
-
- Casos de uso y despliegue
-
- Aplicacioacuten Web
-
- DCOS
- Nomad
-
- Servicio de integracioacuten continua
-
- DevOps
- Integracioacuten Continua
- Jenkins con Nomad
- Jenkins con DCOS
-
- Escalando la infraestructura
-
- Disentildeo
- Implementacioacuten
-
- Resultados y conclusiones
-
- Comparacioacuten
- Conclusiones
- Objetivos conseguidos
- Liacuteneas de investigacioacuten
-
612 Nomad
La arquitectura de Nomad es maacutes sencilla ya que solo requiere de un ficheroejecutable en todos los nodos para funcionar Si DCOS es la base de instala-cioacuten de entornos de terceros Nomad integra todas las funcionalidades baacutesicasesto es gestor de recursos planificador y ejecutor en los nodos cliente Estaherramienta cuenta con un menor tiempo de desarrollo y en el momento deescribir este documento cuenta exclusivamente con los siguientes controladoresen comparacioacuten con los entornos de DCOS
Motor Docker es decir funcioacuten de orquestacioacuten de contenedores
Ejecucioacuten de archivos binarios como comandos de Shell
Ejecucioacuten de aplicaciones Java
Virtualizacioacuten de maacutequinas mediante tecnologiacutea QEMU
Todos ellos necesitan que la tecnologiacutea subyacente esteacute instalada en las maacute-quinas clientes (Docker Java QEMU) Actualmente no permite el registro decontroladores por parte de terceros aunque estaacute planificado en un futuro ofreceruna interfaz para su desarrollo
Nomad no cuenta con el servicio de descubrimiento sin embargo puede inte-grarse con la herramienta Consul desarrollada por la misma empresa Por otrolado para el balanceo de carga usaremos un contenedor Docker con HAProxyuna herramienta de coacutedigo abierto que ofrece tanto servicios de proxy como debalanceador y cuyos ficheros de configuracioacuten completaremos con el proyectoConsul Template19
Consul
Consul sigue la misma arquitectura que Nomad es decir un nodo servidorque orquesta un conjunto de maacutequinas clientes y permite a los procesos que seejecutan en los equipos definirlos como servicios ofreciendo diversas caracteriacutes-ticas entorno a estos de los cuales vamos a usar dos
Descubrimiento de servicio Las maacutequinas clientes publican en el cataacutelogode servicios las tareas en ejecucioacuten y Consul les asigna nombres de dominioaccesibles por todos los miembros del cluster a traveacutes de la interfaz DNSincluida en esta herramientaConsul se integra con Nomad de forma que todas las tareas que se ejecu-ten en la segunda son automaacuteticamente publicados como servicios de laprimera de esta manera no hace falta conocer la direccioacuten de la maacutequinacliente donde se esteacute ejecutando el proceso ya que se puede acceder a eacutela traveacutes de su nombre de dominio de forma transparente Por ejemplo si
19[httpsgithubcomhashicorpconsul-template]
33
ejecutamos una tarea con ID web en el puerto 8080 se puede acceder aella en la direccioacuten webserviceconsul8080Para que las direcciones propias de Consul las resuelva su propio DNS y noel que esteacute asignado por defecto en la maacutequina usaremos la herramientadnsmasq20 que permite especificar la direccioacuten de un servidor DNS paraconsultas de direcciones especiacuteficas
Monitorizacioacuten Permite realizar comprobaciones del servicio y seguir su esta-do Aprovecharemos esta funcionalidad tanto para definir el propio procesode Nomad como servicio de Consul como las tareas desplegadas
HAProxy + Consul Template
HAProxy es una solucioacuten versaacutetil de coacutedigo abierto que ofrece solucionesde balanceo de carga y proxy Existen otras herramientas en el mercado comoNGINX o ldirectord sin embargo HAProxy suponiacutea una solucioacuten sencilla deconfigurar para mostrar el caso de uso
El uso de estas herramientas se debe a dos motivos para que no existacontienda con respecto a los puertos de los clientes usados por las tareas eacutestos sevan a asignar de forma dinaacutemica lo que en principio implicariacutea que la aplicacioacutendeberiacutea realizar consultas DNS de tipo SRV (que incluye puertos) a la interfazde Consul y balancear la carga entre tareas por redundancia y capacidad
Como la direccioacuten IP y puerto son variables cada vez que las tareas seactualicen o se reasignen es necesario volver a configurar HAProxy de formamanual Por ello HashiCorp ha desarrollado un programa denominado Con-sul Template que realiza peticiones sucesivas a la interfaz HTTP de Consul delas direcciones fiacutesicas de un servicio y reinicia automaacuteticamente el proceso deHAProxy Asiacute definiendo estas tareas como servicios Consul podremos tantomonitorizarlas como escalar las tareas dinaacutemicamente sin necesidad de cambiarel balanceador A partir del contenedor Docker oficial de HAProxy se ha desa-rrollado otro con la configuracioacuten baacutesica y con Consul Template para desplegarlocomo una tarea en Nomad
Despliegue
Se ha usado el mismo coacutedigo que en el apartado anterior con la persistenciaen el servicio de almacenamiento de Azure Desde la perspectiva del hardwarese implementaraacute la misma infraestructura que en el caso de DCOS (figura 18)estos es definiremos dos tipos de maacutequinas clientes un agente que se conectaraacutecon el balanceador de carga con nombre de dominio puacuteblico y donde se desple-garaacute el balanceador de carga de la vista web y agentes privados no accesiblesdesde fuera del cluster y donde se ejecutaraacuten el resto de tareas en la red inter-na La principal diferencia radica en las tareas que ejecutan HAproxy y ConsulTemplate que sustituye a las direcciones IP virtuales que ofrece DCOS
20httpwwwthekelleysorgukdnsmasqdochtml
34
Figura 20 Despliegue en Azure de Nomad+Consul
Cabe matizar que los balanceadores basados en HAProxy se implementanpor necesidad de la aplicacioacuten para el descubrimiento del servicio a diferenciade los de Azure que se implementan por motivos de seguridad y escalabilidaddel cluster en siacute
Configuracioacuten Nomad
Los ficheros de configuracioacuten de las maacutequinas maacutester y cliente son similaresy comparten la mayoriacutea de las opciones como por ejemplo el nombre del nodoo la interfaz de red donde escucha Nomad las peticiones Sus opciones son engeneral auto-explicativas sin embargo existen dos detalles que matizar
El proceso de Nomad escucha las peticiones tanto de los protocolos deconsenso como del usuario a traveacutes de una interfaz de red que se debeindicar en el fichero de configuracioacuten
En el caso de los clientes se deben indicar las direcciones de los servidoresdel cluster sin embargo se trata de un sistema dinaacutemico en el que losnodos pueden sufrir errores y cambiar de direccioacuten Por ello se ha definidoNomad como un servicio de Consul y asiacute poder definir la direccioacuten de losservidores como un nombre de dominio no por su direccioacuten fiacutesica que elservidor DNS de Consul se encargaraacute de resolver
Por defecto Nomad usa los siguientes puertos
API HTTP 4646 Peticiones HTTP y recepcioacuten de oacuterdenes mediante laliacutenea de comandos
RPC 4647 Protocolo de consenso entre los nodos del cluster
Serf 4648 Protocolo de gossip entre los servidores de los centros de datosgobernados por Nomad
35
Los dos uacuteltimos deben ser interfaces alcanzables por otros nodos sin embargo laAPI HTTP por motivos de seguridad deberiacutea ser local ya que en caso contrariocualquier persona con acceso a ella tiene el control sobre la herramienta Eacutestasolo deberiacutea estar accesible en un servidor o gestionarlo mediante una terminalSSH por ejemplo En este trabajo al ser una prueba de concepto se ha abiertoen todos los nodos
Trabajos de Nomad
Las tareas se detallan en ficheros con formato HashiCorp Configuration Lan-guage un derivado del formato JSON creado por la empresa que le da nombrecompatible con eacuteste y que permite comentarios
En estos ficheros se puede definir
La regioacuten y el centro de datos donde se ejecutaraacute (Nomad permite lagestioacuten de centros de datos geograacuteficamente distribuidos en regiones)
La poliacutetica de actualizacioacuten de la tarea
Grupo de tareas esto es que se ejecutaraacuten en el mismo nodo
El nuacutemero de grupos a ejecutarescalar asiacute como los liacutemite que debencumplir los nodos asignados
La poliacutetica de reinicio ante fallo o error
Tareas El controlador su configuracioacuten los paraacutemetros del servicio aso-ciado a registrar en Consul asiacute como los recursos que consume (puertosmemoria)
En nuestro caso usamos sobre todo el controlador Docker esto eso orques-tacioacuten de contenedores en los nodos clientes y tres de sus opciones
Imagen del contenedor Se han subido todas las imaacutegenes del proyecto a Doc-ker Hub donde por defecto se busca la imagen
Puertos Los puertos a usar por el contenedor que pueden ser estaacuteticos asigna-dos por el usuario o dinaacutemicos siendo Nomad el que se encarga de mapearun puerto libre del nodo cliente al expuesto por el contenedor
Servidores DNS Como usamos la interfaz DNS de Consul como descubri-miento de servicio se debe configurar el contenedor para que use cualquiernodo del cluster como servidor DNS
Configuracioacuten Consul
Al ser desarrolladas por la misma empresa los ficheros de configuracioacuten deConsul y Nomad comparten muchas opciones Consul tambieacuten acepta peticionesa traveacutes de una interfaz de red siendo los puertos usados por defecto
36
RPC 8300 8400 Maneja la peticiones del resto de nodos y usuarios
Serf 8301 8302 Protocolo gossip
HTTP API 8500
HTTPS API Desactivada por defecto
Interfaz DNS 8600
Se debe asignar a los protocolos internos del cluster esto es RPC y Serf unainterfaz alcanzable por los nodos y por el contrarioasignar a los dos uacuteltimos ala interfaz de loopback por motivos de seguridad
Cabe destacar que Consul tambieacuten cuenta con una interfaz graacutefica que per-mite ver el estado de los equipos y los servicios registrados y que se encuentra enel mismo puerto que la API HTTP en la direccioacuten httpIP_EQUIPO8500ui
Ejecucioacuten
Tanto Nomad como Consul requieren de la ejecucioacuten de un fichero en todoslos nodos integrantes del cluster Como prueba de concepto se ha decidido usardos servidores para ambos aunque cabe matizar que es un nuacutemero ineficienteya que la caiacuteda de uno de ellos supondriacutea la peacuterdida del cuoacuterum y por tantodel consenso del cluster
En primer lugar se arrancan los servidores que son los encargados de ejecu-tar el protocolo de consenso y gestionar el cluster y a continuacioacuten los clientesque no tienen praacutecticamente estado y dependen de los servidores
En el caso de Consul se debe indicar el directorio donde se guardan losficheros que describen los servicios asiacute como el archivo que especifica el resto delas opciones
1 Se inicia el primer servidor en uno de los equipos
$ consu l agent minuscon f i gminusd i r e t c consu l d s e r v i c e s minuscon f i gminus f i l e consu l_server j son
2 Los siguientes equipos deben unirse al anterior por lo que antildeadimos elargumento join con la direccioacuten del primer servidor Para el caso de otrosservidores
$ consu l agent minuscon f i gminusd i r e t c consu l d s e r v i c e s minuscon f i gminus f i l e consu l_server j son minus j o i n ltIP_servidor1gt
37
Una vez los servidores han alcanzado el consenso y elegido un liacuteder en losclientes
$ consu l agent minuscon f i gminusd i r e t c consu l d s e r v i c e s minuscon f i gminus f i l e c on su l_c l i en t j son minus j o i n ltIP_cualquierServ idorgt
El proceso para iniciar Nomad es igual y los comandos similares sin embargoya no es necesario indicar una direccioacuten IP fija en los equipos sino el nombre dedominio del servicio de Nomad registrado por Consul En el primer servidor
$ nomad agent minusc on f i g nomad_server j son
Y el resto de equipos (con su fichero de configuracioacuten correspondiente)$ nomad agent minusc on f i g nomad_server j son minus j o i n nomad s e r v i c e consu l
Por uacuteltimo para desplegar la aplicacioacuten web se han escrito tres ficherosque detallan las tareas de la interfaz web API y los balanceadores de cargaMediante la CLI
$ nomad run minusaddress=http lt ip_c lus te r gt4646 lt f i l e hclgt
O mediante la API HTTP de Nomad$ cu r l minusX POST minusd ltf i l e hclgthttp lt ip_c lus te r gt4646 jobltjob_namegt
Ansible
Como se puede comprobar con el aumento del nuacutemero de equipos pasa aser inviable manejar todos los nodos a traveacutes de terminal Ademaacutes como seha comentado con anterioridad Nomad requiere que en los nodos clientes es-teacuten instalados las herramientas que soporten las tareas por ejemplo el motorde Docker Por ello para facilitar tanto el arranque como la instalacioacuten de lasdependencias vamos a usar Ansible una herramienta de coacutedigo abierto desarro-llada en Python que permite gestionar configuraciones aprovisionar recursosdespliegue de aplicaciones de forma automaacutetica
A grandes rasgos esta herramienta funciona mediante ficheros en formatoYAML denominados play-books que describen un conjunto de pasos a ejecutaren una lista de equipos remotos Estos pasos son ejecutados por moacutedulos inde-pendientes a traveacutes de SSH es decir en cualquier ordenador con conexioacuten a los
38
hosts dado su contrasentildea o clave puacuteblica puede arrancar el script y realizariacutealos pasos de forma remota gestionando el cluster desde un solo equipo
Se han desarrollado guiones para lo siguiente
Descarga de los binarios de Nomad y Consul en todos los nodos copiade los ficheros de configuracioacuten baacutesicos y modificarlos de acuerdo a cadanodo (nombre del equipo direccioacuten IP)
Instalacioacuten de las dependencias
Arranque de Nomad y Consul
Ansible extiende su funcionalidad a traveacutes de moacutedulos independientes que per-miten por ejemplo instalar paquetes mediante herramientas de gestioacuten de pa-quetes (APT yum) aprovisionar automaacuteticamente maacutequinas virtuales de Ama-zon EC2
Algunas opciones de los ficheros de configuracioacuten de Nomad y Consul sondependientes del nodo particular por ejemplo la interfaz de red Para estetrabajo se ha realizado un moacutedulo para modificar los ficheros de configuracioacutende forma automaacutetica En el repositorio del proyecto se encuentra una carpetadonde se encuentran todos los ficheros necesarios para desplegar un clustertotalmente funcional solo requiere de una liacutenea de terminal con Ansible
$ ans ib l eminusplaybook minus i hos t s minusk ltssh_passgt minusu ltnode_usergt s i t e yml
39
62 Servicio de integracioacuten continua
Se ha implementado un sistema de integracioacuten continua que permite ejecu-tar tareas de compilacioacuten y pruebas de forma distribuida aumentando asiacute elrendimiento de los equipos En primer lugar se detallaraacute los motivos por los quepuede resultar beneficioso para las empresas una implementacioacuten de este tipo alo que seguiraacute los detalles del despliegue
621 DevOps
Metodologiacutea que defiende la comunicacioacuten y colaboracioacuten entre desarrolla-dores de software y los profesionales de operaciones a lo largo de todo el ciclo devida de una aplicacioacuten Estaacute muy relacionado con el desarrollo aacutegil de softwareesto es un enfoque para los proyectos que defiende el desarrollo iterativo e in-cremental donde los requisitos y soluciones evolucionan con el tiempo seguacuten lanecesidad del proyecto DevOps extiende esta filosofiacutea a todas los componentesde un servicio incluyendo sistemas y operaciones
Se trata de un concepto que cada organizacioacuten o empresa adapta a suspropias necesidades y procesos de negocio en este proyecto nos vamos a centraren la integracioacuten continua una praacutectica fundamental tanto del desarrollo aacutegilcomo de esta filosofiacutea
622 Integracioacuten Continua
Se define como una praacutectica de desarrollo software donde los miembros delequipo ponen en comuacuten su trabajo frecuentemente al menos una vez al diacutea21Cada integracioacuten se verifica con una compilacioacuten automaacutetica que incluye laejecucioacuten de pruebas para detectar errores de integracioacuten tan pronto como seaposible
Desde el punto de vista operativo esto supone automatizar la configuracioacutende equipos o el despliegue de maacutequinas virtuales donde compilar el proyecto yejecutar las pruebas y posteriormente eliminarlas Este flujo de trabajo se vebeneficiado en entornos distribuidos ya que el objetivo del desarrollador es com-probar el resultado de las pruebas raacutepidamente sin preocuparse del despliegueo los propios equipos
Para esta prueba de concepto vamos a usar Jenkins un servidor de integra-cioacuten continua escrito en Java que nos permite definir trabajos que contendraacutenla descripcioacuten tanto del entorno como su ejecucioacuten
Este sigue una estructura maestro-esclavo muy similar al de los gestores declusters usados en este proyecto el maestro contiene toda la loacutegica del servicio
21httpmartinfowlercomarticlescontinuousIntegrationhtml
40
trabajos autenticacioacuten y los esclavos son los encargados de la ejecucioacuten ensiacute Jenkins tiene varias viacuteas para aprovisionar los uacuteltimos
Mediante SSH
Interfaz graacutefica
Desarrollar un script propio
Ejecucioacuten de un fichero java
La ventaja de usar planificadores es que el despliegue de esclavos es dinaacutemicoes decir no tener una maacutequina especiacuteficamente configurada para ello DCOS yNomad se encargaraacuten de configurar estos despliegues en sus maacutequinas y poste-riormente eliminarlos Para ello se ha usado la uacuteltima opcioacuten definiendo tareasque descarguen el fichero java Con todo ello se consigue un entorno de inte-gracioacuten continua eficiente que ademaacutes permite la ejecucioacuten de otros servicios deforma independiente
Jenkins permite la creacioacuten de plugins que extienden sus funcionalidadesTanto Nomad22 como Apache Mesos cuentan con uno que permite su integra-cioacuten
Para esta prueba se va a usar el mismo proyecto que para el caso de usode orquestacioacuten de contenedores la aplicacioacuten web al que se le ha antildeadido untest para comprobar que se conecta correctamente a la base de datos medianteMocha un framework de Nodejs Por otro lado se antildeade el plugin de git ya queel coacutedigo se obtiene de GitHub el repositorio remoto de control de versiones delproyecto
El proceso general de ejecucioacuten seriacutea como sigue
1 Se ejecuta el maestro de Jenkins como tarea Docker partiendo de la imagenoficial
2 Al arrancar un trabajo se manda una tarea a los planificadores que laasignaraacuten a un nodo cliente Esta tarea consiste en la descarga del ficherode configuracioacuten Java y arrancarlo configurando el equipo como un clientede Jenkins temporalmente
3 Jenkins ejecuta el trabajo en el nuevo cliente en este caso iniciar la apli-cacioacuten web iniciar las pruebas y generar un informe
4 Se elimina el cliente
A continuacioacuten se detallan los matices de cada herramienta a la hora de imple-mentar este servicio
22Desarrollado por Ivo Verberk httpwwwivoverberknl
41
623 Jenkins con Nomad
El plugin permite la ejecucioacuten del fichero Java mediante dos controladorescontenedores Docker y Java En este proyecto nos hemos decantado por el pri-mero ya que nos ahorra instalar la maacutequina virtual de java en todos los nodoscliente Por ello se ha construido un contenedor base con Java para la ejecucioacutendel fichero de configuracioacuten y Nodejs para lanzar la aplicacioacuten web
El plugin se configura con la direccioacuten IP del cluster y el contenedor queejecuta el esclavo Jenkins Por su parte el trabajo en Jenkins se define conel repositorio en GitHub donde se aloja el coacutedigo del proyecto a probar y loscomandos a ejecutar en este caso npm update y npm test
624 Jenkins con DCOS
En el caso de DCOS su sistema de paquetes incluye Jenkins por lo queal instalarlo ya se tiene la configuracioacuten de Mesos totalmente funcional Sinembargo para ejecutar la aplicacioacuten en particular y las pruebas se requiere deNodejs en los equipos esclavos por ello debemos antildeadir un plugin de Jenkinsque permite instalar este entorno antes de ejecutar el trabajo Una vez hechoesto soacutelo queda definir la tarea igual que en el caso anterior
Cabe destacar que Mesosphere tambieacuten ha desarrollado un plugin que per-mite hacer despliegues en Marathon de tal manera que permitiriacutea con cadacommit del coacutedigo compilar la imagen del contenedor Docker y desplegarlaautomaacuteticamente aunque en este proyecto no se ha hecho pruebas de esta fun-cionalidad
42
7 Escalando la infraestructura
Uno de los factores clave que se busca a la hora de implementar sistemasdistribuidos es el poder escalar la infraestructura de forma maacutes sencilla estoes detectar que las maacutequinas estaacuten alcanzando el liacutemite de su capacidad yaumentar eacutesta ya sea mejorando sus caracteriacutesticas teacutecnicas o antildeadiendo maacutesnodos al cluster
El coacutedigo y todos los ficheros de configuracioacuten de esta seccioacuten tambieacuten sepueden encontrar en el repositorio del proyecto en GitHub23
71 Disentildeo
Microsoft Azure permite organizar los servicios cloud de forma loacutegica a traveacutesde grupos de recursos y asiacute poder crear o eliminar eacutestos en conjunto parauna aplicacioacuten determinada (por ejemplo una aplicacioacuten web suele requerir demaacutequinas virtuales bases de datos almacenamiento) Ademaacutes dispone dela opcioacuten de crear plantillas en formato JSON que permite al desarrolladordefinir los recursos y su interrelacioacuten para desplegar de forma automaacutetica unainfraestructura TI en la nube
Azure tambieacuten ofrece la posibilidad de monitorizar el estado de las maacutequinasvirtuales a traveacutes de extensiones lo que permite configurar el escalado automaacute-tico al alcanzar cierto liacutemite definido por el operador Eacutesta es a priori la formaen que deberiacutea implementarse hablando en teacuterminos de eficiencia sin embargoesta aproximacioacuten es totalmente dependiente de la plataforma es decir no sepuede extrapolar a otro proveedor o sobre recursos propios sin realizar un nue-vo disentildeo En este proyecto las tareas que son ejecutadas por estos equipos notienen estado ya que todo lo relativo a la persistencia lo hemos asignado fueradel cluster esto permite escalar la plataforma a traveacutes de otra aproximaciones
Las plantillas aceptan una serie de variables a indicar por el usuario entreotras los conjuntos de escala para definir los nodos aceptan una variable quedefine el nuacutemero de maacutequinas que los componen Por otro lado Azure ofreceuna API REST y kits de desarrollo software (SDK por sus siglas en ingleacutes) quepermiten su despliegue de forma programaacutetica Aprovechando estas facilidadesen este proyecto se va a aproximar la escalabilidad con el sucesivo desplieguede la infraestructura de forma automaacutetica se monitorizan los equipos y si sedetecta una maacutequina excesivamente cargada se aumenta el nuacutemero de equiposen la plantilla y se vuelve a desplegar
23httpsgithubcomAntonioAlfrzCloud-Orchestrators
43
En este proyecto se han disentildeado las plantillas para desplegar la arquitec-tura necesaria tanto de Nomad como de DCOS En el caso de la primera eldespliegue es maacutes descriptivo ya que incluye maacutequinas virtuales grupos de se-guridad redes En el caso de DCOS Azure cuenta con un servicio especiacuteficopara clusters gobernados por DCOS denominado Azure Container Service queincluye los componentes necesarios y la instalacioacuten ya realizada
72 Implementacioacuten
En primer lugar para monitorizar el estado de los equipos se va a usar laherramienta Nagios un sistema que permite controlar el estado del hardwarey los servicios de un equipo Se trata de una herramienta muy completa de laque se va a usar su capacidad para ejecutar comandos (plugins) en los nodospara detectar picos de carga generar alertas y ejecutar programas para estoseventos
Se ha desplegado una maacutequina virtual con esta herramienta en ambos siste-mas y se ha instalado una extensioacuten de Nagios (Nagios Remote Plugin Executor)en todos los nodos que permite ejecutar comprobaciones remotamente en con-creto para esta prueba de concepto medir el nivel de saturacioacuten de la unidadcentral de procesamiento (CPU por sus siglas del ingleacutes) Cuando sucede uncambio de estado de una maacutequina esto es cuando este paraacutemetro supera el liacutemi-te definido por el operador Nagios permite actuar en consecuencia ejecutandoprogramas por ello se ha desarrollado un script que ejecuta lo siguiente
Un programa desarrollado en Python con el SDK de Azure que modificalas plantillas y despliega los recursos
Un guioacuten de Ansible para instalar todos los componentes necesarios en lasnuevas maacutequinas y arrancar de nuevo el cluster y las aplicaciones
44
8 Resultados y conclusiones
En este uacuteltimo apartado se da una visioacuten global del proyecto asiacute como a lasconclusiones maacutes importantes a las que se ha llegado y posibles temas futurosde desarrollo
81 Comparacioacuten
Ambas herramientas ofrecen las funcionalidades para gestionar los recursoseficientemente ofreciendo a los desarrolladores una plataforma donde desplegarsus aplicaciones de forma distribuida independientemente de los equipos fiacutesicosy el hardware que las soporten
DCOS es una herramienta que en un comienzo fue privativa pero cuyos res-ponsables la empresa Mesosphere decidieron publicar una versioacuten de coacutedigoEacutesta nos permite gestionar un cluster de una forma sencilla y usable ademaacutes decomplementarlo con otras herramientas como el balanceador de carga integradoo la autenticacioacuten de usuarios ademaacutes estaacute basada en Apache Mesos un pro-yecto de relativa madurez y con el soporte de la Apache Software FoundationDe forma resumida DCOS ofrece muchas posibilidades y servicios a cambiode una arquitectura e instalacioacuten maacutes compleja
Por su parte HashiCorp con menor tiempo de desarrollo ha conseguidouna herramienta muy sencilla de desplegar que ademaacutes cumple con todas lasfuncionalidades baacutesicas ejecutando un simple binario en cada nodo se puededesplegar un gestor de clusters totalmente funcional Sin embargo no cuentacon todas las posibilidades de Mesos (Nomad cuenta con menos controladoresque entornos posibles de Mesos) ni con los antildeadidos de DCOS lo que implicael uso de otras herramientas para complementar el servicio (Consul HAProxy)
De entre las dificultades encontradas al usar estas herramientas y desplegaraplicaciones sobre ellas se puede destacar la depuracioacuten en ocasiones se desco-noce si un error viene de la propia herramienta de la aplicacioacuten desplegada o delequipo fiacutesico si no se cuenta con un sistema de procesamiento de registro unose puede encontrar con muacuteltiples terminales abiertas inspeccionando numerososficheros de registro buscando posibles errores Ademaacutes no dejan de ser solucio-nes que para usar eficientemente se debe conocer parte de su funcionamientoy sintaxis a la hora de describir la tareas lo que supone un esfuerzo antildeadido yaque cada una tiene sus particularidades y liacutemites
45
82 Conclusiones
En una sociedad cada vez maacutes digital las empresas deben adaptarse a unmercado cuya demanda de contenido no deja de crecer Las nuevas arquitecturascomo microservicios asiacute como la gran cantidad de datos generada implica queuna mejor gestioacuten de los recursos y la rapidez para desplegar o escalar solucionesdando valor al cliente lo maacutes raacutepido posible es uno de los objetivos de todas lasempresas de base tecnoloacutegica
Las ventajas que ofrecen los planificadores con aplicaciones distribuidas sonnumerosas sin ir maacutes lejos empresas tan punteras como Google llevan maacutesde 10 antildeos orquestando contenedores24 Por un lado permiten aumentar elrendimiento de los equipos propios y por otro implementar un servicio comoplataforma para despliegues distribuidos sobre cualquier conjunto hardware deesta forma se provee un servicio similar al de la nube puacuteblica pero con laprincipal diferencia de que se elimina la independencia con el proveedor (vendorlock-in) esto es las aplicaciones no tienen limitaciones impuestas por eacuteste talescomo lenguaje de programacioacuten o herramientas y permite despliegues hiacutebridosentre recursos propios y la nube
83 Objetivos conseguidos
Implementacioacuten de los planificadores propuestos en la nube Se ha en-tendido y detallado el funcionamiento de estas herramientas y se hanimplementado en el servicio de infraestructura de Microsoft Azure
Despliegue de aplicaciones y servicios distribuidos Servicios que se usanactualmente en la industria del desarrollo software asiacute como una aplica-cioacuten web con una arquitectura moderna han sido desplegados de formadistribuida en los equipos cumpliendo con la funcionalidad esperada ade-maacutes de consiguiendo una alta disponibilidad
Aproximacioacuten de arquitectura escalable Se ha hecho una aproximacioacutende infraestructura escalable de forma que sea parcialmente extrapolable aotros proveedores
24httpwwwnextplatformcom20160322decade-container-control-google
46
84 Liacuteneas de investigacioacuten
Siguiendo con la materia de este proyecto se presentan posibles liacuteneas deinvestigacioacuten
Analizar el despliegue con estas herramientas de aplicaciones de Big Datay comparar la eficiencia con respecto a soluciones especializadas
Analizar el rendimiento de los algoritmos de planificacioacuten antes pruebasde estreacutes y situaciones de alta contienda
Comparar el uso de estas herramientas con las praacutecticas actuales de laindustria o implementacioacuten en un sistema de produccioacuten real
47
Referencias
[1] LA Barroso y U Houmllzle laquoThe Datacenter as a Computer An Introduc-tion to the Design of Warehouse-Scale Machinesraquo En Morgan amp ClaypoolPublishers ()
[2] Systems Research Group ndash NetOS (University of Cambridge) The evolu-tion of cluster scheduler architectures 2016 url httpswwwclcamacukresearchsrgnetoscamsasblog2016-03-09-scheduler-architectureshtml
[3] A Das I Gupta y A Motivala SWIM Scalable Weakly-consistent Infection-style Process Group Membership Protocol Inf teacutec Dept of ComputerScience Cornell University url https www cs cornell edu ~asdasresearchdsn02-swimpdf
[4] D Dubhashi y A Das Mastering Mesos PACKT Publishing mayo de2016
[5] The Apache Software Foundation Apache Mesos documentation urlhttpsmesosapacheorg
[6] David Greenberg Building Applications on Mesos OrsquoReilly Media 2016[7] Armand Grillet Comparison of Container Schedulers Inf teacutec Technische
Universitaumlt Berlin[8] HashiCorp Consul documentation url httpswwwconsulio[9] HashiCorp Nomad documentation url httpsdcosio[10] Dan C Marinescu Cloud computing theory and practice Morgan Kauf-
mann 2013[11] Mesosphere DCOS documentation url httpswwwnomadproject
io[12] Microsoft Azure documentation url httpsazuremicrosoftcom
es-esdocumentation[13] D Ongaro y J Ousterhout In Search of an Understandable Consensus
Algorithm Inf teacutec Stanford University url httpsraftgithubioraftpdf
[14] Fei Teng laquoRessource allocation and schelduling models for cloud compu-tingraquo Tesis de mtriacutea Ecole Centrale Paris 2011
[15] A Williams y col Automation and Orchestration with Docker and Contai-ners A Comprehensive Overview of the Docker and Container Ecosystem3 The New Stack 2016
48
- Resumen
- Summary
- Iacutendice de figuras
- Introduccioacuten y objetivos
-
- Contexto
- Objetivos
- Estructura del documento
-
- Cloud Computing
- Nuevas cargas de trabajo
- Gestioacuten de recursos Planificadores
-
- Sistemas distribuidos
-
- Clasificacioacuten
-
- Herramientas
-
- DCOS
-
- Apache Mesos
- Ejemplos de uso
-
- Nomad
-
- Protocolo de consenso Raft
- Protocolo gossip SWIM
- Planificacioacuten
-
- Casos de uso y despliegue
-
- Aplicacioacuten Web
-
- DCOS
- Nomad
-
- Servicio de integracioacuten continua
-
- DevOps
- Integracioacuten Continua
- Jenkins con Nomad
- Jenkins con DCOS
-
- Escalando la infraestructura
-
- Disentildeo
- Implementacioacuten
-
- Resultados y conclusiones
-
- Comparacioacuten
- Conclusiones
- Objetivos conseguidos
- Liacuteneas de investigacioacuten
-
ejecutamos una tarea con ID web en el puerto 8080 se puede acceder aella en la direccioacuten webserviceconsul8080Para que las direcciones propias de Consul las resuelva su propio DNS y noel que esteacute asignado por defecto en la maacutequina usaremos la herramientadnsmasq20 que permite especificar la direccioacuten de un servidor DNS paraconsultas de direcciones especiacuteficas
Monitorizacioacuten Permite realizar comprobaciones del servicio y seguir su esta-do Aprovecharemos esta funcionalidad tanto para definir el propio procesode Nomad como servicio de Consul como las tareas desplegadas
HAProxy + Consul Template
HAProxy es una solucioacuten versaacutetil de coacutedigo abierto que ofrece solucionesde balanceo de carga y proxy Existen otras herramientas en el mercado comoNGINX o ldirectord sin embargo HAProxy suponiacutea una solucioacuten sencilla deconfigurar para mostrar el caso de uso
El uso de estas herramientas se debe a dos motivos para que no existacontienda con respecto a los puertos de los clientes usados por las tareas eacutestos sevan a asignar de forma dinaacutemica lo que en principio implicariacutea que la aplicacioacutendeberiacutea realizar consultas DNS de tipo SRV (que incluye puertos) a la interfazde Consul y balancear la carga entre tareas por redundancia y capacidad
Como la direccioacuten IP y puerto son variables cada vez que las tareas seactualicen o se reasignen es necesario volver a configurar HAProxy de formamanual Por ello HashiCorp ha desarrollado un programa denominado Con-sul Template que realiza peticiones sucesivas a la interfaz HTTP de Consul delas direcciones fiacutesicas de un servicio y reinicia automaacuteticamente el proceso deHAProxy Asiacute definiendo estas tareas como servicios Consul podremos tantomonitorizarlas como escalar las tareas dinaacutemicamente sin necesidad de cambiarel balanceador A partir del contenedor Docker oficial de HAProxy se ha desa-rrollado otro con la configuracioacuten baacutesica y con Consul Template para desplegarlocomo una tarea en Nomad
Despliegue
Se ha usado el mismo coacutedigo que en el apartado anterior con la persistenciaen el servicio de almacenamiento de Azure Desde la perspectiva del hardwarese implementaraacute la misma infraestructura que en el caso de DCOS (figura 18)estos es definiremos dos tipos de maacutequinas clientes un agente que se conectaraacutecon el balanceador de carga con nombre de dominio puacuteblico y donde se desple-garaacute el balanceador de carga de la vista web y agentes privados no accesiblesdesde fuera del cluster y donde se ejecutaraacuten el resto de tareas en la red inter-na La principal diferencia radica en las tareas que ejecutan HAproxy y ConsulTemplate que sustituye a las direcciones IP virtuales que ofrece DCOS
20httpwwwthekelleysorgukdnsmasqdochtml
34
Figura 20 Despliegue en Azure de Nomad+Consul
Cabe matizar que los balanceadores basados en HAProxy se implementanpor necesidad de la aplicacioacuten para el descubrimiento del servicio a diferenciade los de Azure que se implementan por motivos de seguridad y escalabilidaddel cluster en siacute
Configuracioacuten Nomad
Los ficheros de configuracioacuten de las maacutequinas maacutester y cliente son similaresy comparten la mayoriacutea de las opciones como por ejemplo el nombre del nodoo la interfaz de red donde escucha Nomad las peticiones Sus opciones son engeneral auto-explicativas sin embargo existen dos detalles que matizar
El proceso de Nomad escucha las peticiones tanto de los protocolos deconsenso como del usuario a traveacutes de una interfaz de red que se debeindicar en el fichero de configuracioacuten
En el caso de los clientes se deben indicar las direcciones de los servidoresdel cluster sin embargo se trata de un sistema dinaacutemico en el que losnodos pueden sufrir errores y cambiar de direccioacuten Por ello se ha definidoNomad como un servicio de Consul y asiacute poder definir la direccioacuten de losservidores como un nombre de dominio no por su direccioacuten fiacutesica que elservidor DNS de Consul se encargaraacute de resolver
Por defecto Nomad usa los siguientes puertos
API HTTP 4646 Peticiones HTTP y recepcioacuten de oacuterdenes mediante laliacutenea de comandos
RPC 4647 Protocolo de consenso entre los nodos del cluster
Serf 4648 Protocolo de gossip entre los servidores de los centros de datosgobernados por Nomad
35
Los dos uacuteltimos deben ser interfaces alcanzables por otros nodos sin embargo laAPI HTTP por motivos de seguridad deberiacutea ser local ya que en caso contrariocualquier persona con acceso a ella tiene el control sobre la herramienta Eacutestasolo deberiacutea estar accesible en un servidor o gestionarlo mediante una terminalSSH por ejemplo En este trabajo al ser una prueba de concepto se ha abiertoen todos los nodos
Trabajos de Nomad
Las tareas se detallan en ficheros con formato HashiCorp Configuration Lan-guage un derivado del formato JSON creado por la empresa que le da nombrecompatible con eacuteste y que permite comentarios
En estos ficheros se puede definir
La regioacuten y el centro de datos donde se ejecutaraacute (Nomad permite lagestioacuten de centros de datos geograacuteficamente distribuidos en regiones)
La poliacutetica de actualizacioacuten de la tarea
Grupo de tareas esto es que se ejecutaraacuten en el mismo nodo
El nuacutemero de grupos a ejecutarescalar asiacute como los liacutemite que debencumplir los nodos asignados
La poliacutetica de reinicio ante fallo o error
Tareas El controlador su configuracioacuten los paraacutemetros del servicio aso-ciado a registrar en Consul asiacute como los recursos que consume (puertosmemoria)
En nuestro caso usamos sobre todo el controlador Docker esto eso orques-tacioacuten de contenedores en los nodos clientes y tres de sus opciones
Imagen del contenedor Se han subido todas las imaacutegenes del proyecto a Doc-ker Hub donde por defecto se busca la imagen
Puertos Los puertos a usar por el contenedor que pueden ser estaacuteticos asigna-dos por el usuario o dinaacutemicos siendo Nomad el que se encarga de mapearun puerto libre del nodo cliente al expuesto por el contenedor
Servidores DNS Como usamos la interfaz DNS de Consul como descubri-miento de servicio se debe configurar el contenedor para que use cualquiernodo del cluster como servidor DNS
Configuracioacuten Consul
Al ser desarrolladas por la misma empresa los ficheros de configuracioacuten deConsul y Nomad comparten muchas opciones Consul tambieacuten acepta peticionesa traveacutes de una interfaz de red siendo los puertos usados por defecto
36
RPC 8300 8400 Maneja la peticiones del resto de nodos y usuarios
Serf 8301 8302 Protocolo gossip
HTTP API 8500
HTTPS API Desactivada por defecto
Interfaz DNS 8600
Se debe asignar a los protocolos internos del cluster esto es RPC y Serf unainterfaz alcanzable por los nodos y por el contrarioasignar a los dos uacuteltimos ala interfaz de loopback por motivos de seguridad
Cabe destacar que Consul tambieacuten cuenta con una interfaz graacutefica que per-mite ver el estado de los equipos y los servicios registrados y que se encuentra enel mismo puerto que la API HTTP en la direccioacuten httpIP_EQUIPO8500ui
Ejecucioacuten
Tanto Nomad como Consul requieren de la ejecucioacuten de un fichero en todoslos nodos integrantes del cluster Como prueba de concepto se ha decidido usardos servidores para ambos aunque cabe matizar que es un nuacutemero ineficienteya que la caiacuteda de uno de ellos supondriacutea la peacuterdida del cuoacuterum y por tantodel consenso del cluster
En primer lugar se arrancan los servidores que son los encargados de ejecu-tar el protocolo de consenso y gestionar el cluster y a continuacioacuten los clientesque no tienen praacutecticamente estado y dependen de los servidores
En el caso de Consul se debe indicar el directorio donde se guardan losficheros que describen los servicios asiacute como el archivo que especifica el resto delas opciones
1 Se inicia el primer servidor en uno de los equipos
$ consu l agent minuscon f i gminusd i r e t c consu l d s e r v i c e s minuscon f i gminus f i l e consu l_server j son
2 Los siguientes equipos deben unirse al anterior por lo que antildeadimos elargumento join con la direccioacuten del primer servidor Para el caso de otrosservidores
$ consu l agent minuscon f i gminusd i r e t c consu l d s e r v i c e s minuscon f i gminus f i l e consu l_server j son minus j o i n ltIP_servidor1gt
37
Una vez los servidores han alcanzado el consenso y elegido un liacuteder en losclientes
$ consu l agent minuscon f i gminusd i r e t c consu l d s e r v i c e s minuscon f i gminus f i l e c on su l_c l i en t j son minus j o i n ltIP_cualquierServ idorgt
El proceso para iniciar Nomad es igual y los comandos similares sin embargoya no es necesario indicar una direccioacuten IP fija en los equipos sino el nombre dedominio del servicio de Nomad registrado por Consul En el primer servidor
$ nomad agent minusc on f i g nomad_server j son
Y el resto de equipos (con su fichero de configuracioacuten correspondiente)$ nomad agent minusc on f i g nomad_server j son minus j o i n nomad s e r v i c e consu l
Por uacuteltimo para desplegar la aplicacioacuten web se han escrito tres ficherosque detallan las tareas de la interfaz web API y los balanceadores de cargaMediante la CLI
$ nomad run minusaddress=http lt ip_c lus te r gt4646 lt f i l e hclgt
O mediante la API HTTP de Nomad$ cu r l minusX POST minusd ltf i l e hclgthttp lt ip_c lus te r gt4646 jobltjob_namegt
Ansible
Como se puede comprobar con el aumento del nuacutemero de equipos pasa aser inviable manejar todos los nodos a traveacutes de terminal Ademaacutes como seha comentado con anterioridad Nomad requiere que en los nodos clientes es-teacuten instalados las herramientas que soporten las tareas por ejemplo el motorde Docker Por ello para facilitar tanto el arranque como la instalacioacuten de lasdependencias vamos a usar Ansible una herramienta de coacutedigo abierto desarro-llada en Python que permite gestionar configuraciones aprovisionar recursosdespliegue de aplicaciones de forma automaacutetica
A grandes rasgos esta herramienta funciona mediante ficheros en formatoYAML denominados play-books que describen un conjunto de pasos a ejecutaren una lista de equipos remotos Estos pasos son ejecutados por moacutedulos inde-pendientes a traveacutes de SSH es decir en cualquier ordenador con conexioacuten a los
38
hosts dado su contrasentildea o clave puacuteblica puede arrancar el script y realizariacutealos pasos de forma remota gestionando el cluster desde un solo equipo
Se han desarrollado guiones para lo siguiente
Descarga de los binarios de Nomad y Consul en todos los nodos copiade los ficheros de configuracioacuten baacutesicos y modificarlos de acuerdo a cadanodo (nombre del equipo direccioacuten IP)
Instalacioacuten de las dependencias
Arranque de Nomad y Consul
Ansible extiende su funcionalidad a traveacutes de moacutedulos independientes que per-miten por ejemplo instalar paquetes mediante herramientas de gestioacuten de pa-quetes (APT yum) aprovisionar automaacuteticamente maacutequinas virtuales de Ama-zon EC2
Algunas opciones de los ficheros de configuracioacuten de Nomad y Consul sondependientes del nodo particular por ejemplo la interfaz de red Para estetrabajo se ha realizado un moacutedulo para modificar los ficheros de configuracioacutende forma automaacutetica En el repositorio del proyecto se encuentra una carpetadonde se encuentran todos los ficheros necesarios para desplegar un clustertotalmente funcional solo requiere de una liacutenea de terminal con Ansible
$ ans ib l eminusplaybook minus i hos t s minusk ltssh_passgt minusu ltnode_usergt s i t e yml
39
62 Servicio de integracioacuten continua
Se ha implementado un sistema de integracioacuten continua que permite ejecu-tar tareas de compilacioacuten y pruebas de forma distribuida aumentando asiacute elrendimiento de los equipos En primer lugar se detallaraacute los motivos por los quepuede resultar beneficioso para las empresas una implementacioacuten de este tipo alo que seguiraacute los detalles del despliegue
621 DevOps
Metodologiacutea que defiende la comunicacioacuten y colaboracioacuten entre desarrolla-dores de software y los profesionales de operaciones a lo largo de todo el ciclo devida de una aplicacioacuten Estaacute muy relacionado con el desarrollo aacutegil de softwareesto es un enfoque para los proyectos que defiende el desarrollo iterativo e in-cremental donde los requisitos y soluciones evolucionan con el tiempo seguacuten lanecesidad del proyecto DevOps extiende esta filosofiacutea a todas los componentesde un servicio incluyendo sistemas y operaciones
Se trata de un concepto que cada organizacioacuten o empresa adapta a suspropias necesidades y procesos de negocio en este proyecto nos vamos a centraren la integracioacuten continua una praacutectica fundamental tanto del desarrollo aacutegilcomo de esta filosofiacutea
622 Integracioacuten Continua
Se define como una praacutectica de desarrollo software donde los miembros delequipo ponen en comuacuten su trabajo frecuentemente al menos una vez al diacutea21Cada integracioacuten se verifica con una compilacioacuten automaacutetica que incluye laejecucioacuten de pruebas para detectar errores de integracioacuten tan pronto como seaposible
Desde el punto de vista operativo esto supone automatizar la configuracioacutende equipos o el despliegue de maacutequinas virtuales donde compilar el proyecto yejecutar las pruebas y posteriormente eliminarlas Este flujo de trabajo se vebeneficiado en entornos distribuidos ya que el objetivo del desarrollador es com-probar el resultado de las pruebas raacutepidamente sin preocuparse del despliegueo los propios equipos
Para esta prueba de concepto vamos a usar Jenkins un servidor de integra-cioacuten continua escrito en Java que nos permite definir trabajos que contendraacutenla descripcioacuten tanto del entorno como su ejecucioacuten
Este sigue una estructura maestro-esclavo muy similar al de los gestores declusters usados en este proyecto el maestro contiene toda la loacutegica del servicio
21httpmartinfowlercomarticlescontinuousIntegrationhtml
40
trabajos autenticacioacuten y los esclavos son los encargados de la ejecucioacuten ensiacute Jenkins tiene varias viacuteas para aprovisionar los uacuteltimos
Mediante SSH
Interfaz graacutefica
Desarrollar un script propio
Ejecucioacuten de un fichero java
La ventaja de usar planificadores es que el despliegue de esclavos es dinaacutemicoes decir no tener una maacutequina especiacuteficamente configurada para ello DCOS yNomad se encargaraacuten de configurar estos despliegues en sus maacutequinas y poste-riormente eliminarlos Para ello se ha usado la uacuteltima opcioacuten definiendo tareasque descarguen el fichero java Con todo ello se consigue un entorno de inte-gracioacuten continua eficiente que ademaacutes permite la ejecucioacuten de otros servicios deforma independiente
Jenkins permite la creacioacuten de plugins que extienden sus funcionalidadesTanto Nomad22 como Apache Mesos cuentan con uno que permite su integra-cioacuten
Para esta prueba se va a usar el mismo proyecto que para el caso de usode orquestacioacuten de contenedores la aplicacioacuten web al que se le ha antildeadido untest para comprobar que se conecta correctamente a la base de datos medianteMocha un framework de Nodejs Por otro lado se antildeade el plugin de git ya queel coacutedigo se obtiene de GitHub el repositorio remoto de control de versiones delproyecto
El proceso general de ejecucioacuten seriacutea como sigue
1 Se ejecuta el maestro de Jenkins como tarea Docker partiendo de la imagenoficial
2 Al arrancar un trabajo se manda una tarea a los planificadores que laasignaraacuten a un nodo cliente Esta tarea consiste en la descarga del ficherode configuracioacuten Java y arrancarlo configurando el equipo como un clientede Jenkins temporalmente
3 Jenkins ejecuta el trabajo en el nuevo cliente en este caso iniciar la apli-cacioacuten web iniciar las pruebas y generar un informe
4 Se elimina el cliente
A continuacioacuten se detallan los matices de cada herramienta a la hora de imple-mentar este servicio
22Desarrollado por Ivo Verberk httpwwwivoverberknl
41
623 Jenkins con Nomad
El plugin permite la ejecucioacuten del fichero Java mediante dos controladorescontenedores Docker y Java En este proyecto nos hemos decantado por el pri-mero ya que nos ahorra instalar la maacutequina virtual de java en todos los nodoscliente Por ello se ha construido un contenedor base con Java para la ejecucioacutendel fichero de configuracioacuten y Nodejs para lanzar la aplicacioacuten web
El plugin se configura con la direccioacuten IP del cluster y el contenedor queejecuta el esclavo Jenkins Por su parte el trabajo en Jenkins se define conel repositorio en GitHub donde se aloja el coacutedigo del proyecto a probar y loscomandos a ejecutar en este caso npm update y npm test
624 Jenkins con DCOS
En el caso de DCOS su sistema de paquetes incluye Jenkins por lo queal instalarlo ya se tiene la configuracioacuten de Mesos totalmente funcional Sinembargo para ejecutar la aplicacioacuten en particular y las pruebas se requiere deNodejs en los equipos esclavos por ello debemos antildeadir un plugin de Jenkinsque permite instalar este entorno antes de ejecutar el trabajo Una vez hechoesto soacutelo queda definir la tarea igual que en el caso anterior
Cabe destacar que Mesosphere tambieacuten ha desarrollado un plugin que per-mite hacer despliegues en Marathon de tal manera que permitiriacutea con cadacommit del coacutedigo compilar la imagen del contenedor Docker y desplegarlaautomaacuteticamente aunque en este proyecto no se ha hecho pruebas de esta fun-cionalidad
42
7 Escalando la infraestructura
Uno de los factores clave que se busca a la hora de implementar sistemasdistribuidos es el poder escalar la infraestructura de forma maacutes sencilla estoes detectar que las maacutequinas estaacuten alcanzando el liacutemite de su capacidad yaumentar eacutesta ya sea mejorando sus caracteriacutesticas teacutecnicas o antildeadiendo maacutesnodos al cluster
El coacutedigo y todos los ficheros de configuracioacuten de esta seccioacuten tambieacuten sepueden encontrar en el repositorio del proyecto en GitHub23
71 Disentildeo
Microsoft Azure permite organizar los servicios cloud de forma loacutegica a traveacutesde grupos de recursos y asiacute poder crear o eliminar eacutestos en conjunto parauna aplicacioacuten determinada (por ejemplo una aplicacioacuten web suele requerir demaacutequinas virtuales bases de datos almacenamiento) Ademaacutes dispone dela opcioacuten de crear plantillas en formato JSON que permite al desarrolladordefinir los recursos y su interrelacioacuten para desplegar de forma automaacutetica unainfraestructura TI en la nube
Azure tambieacuten ofrece la posibilidad de monitorizar el estado de las maacutequinasvirtuales a traveacutes de extensiones lo que permite configurar el escalado automaacute-tico al alcanzar cierto liacutemite definido por el operador Eacutesta es a priori la formaen que deberiacutea implementarse hablando en teacuterminos de eficiencia sin embargoesta aproximacioacuten es totalmente dependiente de la plataforma es decir no sepuede extrapolar a otro proveedor o sobre recursos propios sin realizar un nue-vo disentildeo En este proyecto las tareas que son ejecutadas por estos equipos notienen estado ya que todo lo relativo a la persistencia lo hemos asignado fueradel cluster esto permite escalar la plataforma a traveacutes de otra aproximaciones
Las plantillas aceptan una serie de variables a indicar por el usuario entreotras los conjuntos de escala para definir los nodos aceptan una variable quedefine el nuacutemero de maacutequinas que los componen Por otro lado Azure ofreceuna API REST y kits de desarrollo software (SDK por sus siglas en ingleacutes) quepermiten su despliegue de forma programaacutetica Aprovechando estas facilidadesen este proyecto se va a aproximar la escalabilidad con el sucesivo desplieguede la infraestructura de forma automaacutetica se monitorizan los equipos y si sedetecta una maacutequina excesivamente cargada se aumenta el nuacutemero de equiposen la plantilla y se vuelve a desplegar
23httpsgithubcomAntonioAlfrzCloud-Orchestrators
43
En este proyecto se han disentildeado las plantillas para desplegar la arquitec-tura necesaria tanto de Nomad como de DCOS En el caso de la primera eldespliegue es maacutes descriptivo ya que incluye maacutequinas virtuales grupos de se-guridad redes En el caso de DCOS Azure cuenta con un servicio especiacuteficopara clusters gobernados por DCOS denominado Azure Container Service queincluye los componentes necesarios y la instalacioacuten ya realizada
72 Implementacioacuten
En primer lugar para monitorizar el estado de los equipos se va a usar laherramienta Nagios un sistema que permite controlar el estado del hardwarey los servicios de un equipo Se trata de una herramienta muy completa de laque se va a usar su capacidad para ejecutar comandos (plugins) en los nodospara detectar picos de carga generar alertas y ejecutar programas para estoseventos
Se ha desplegado una maacutequina virtual con esta herramienta en ambos siste-mas y se ha instalado una extensioacuten de Nagios (Nagios Remote Plugin Executor)en todos los nodos que permite ejecutar comprobaciones remotamente en con-creto para esta prueba de concepto medir el nivel de saturacioacuten de la unidadcentral de procesamiento (CPU por sus siglas del ingleacutes) Cuando sucede uncambio de estado de una maacutequina esto es cuando este paraacutemetro supera el liacutemi-te definido por el operador Nagios permite actuar en consecuencia ejecutandoprogramas por ello se ha desarrollado un script que ejecuta lo siguiente
Un programa desarrollado en Python con el SDK de Azure que modificalas plantillas y despliega los recursos
Un guioacuten de Ansible para instalar todos los componentes necesarios en lasnuevas maacutequinas y arrancar de nuevo el cluster y las aplicaciones
44
8 Resultados y conclusiones
En este uacuteltimo apartado se da una visioacuten global del proyecto asiacute como a lasconclusiones maacutes importantes a las que se ha llegado y posibles temas futurosde desarrollo
81 Comparacioacuten
Ambas herramientas ofrecen las funcionalidades para gestionar los recursoseficientemente ofreciendo a los desarrolladores una plataforma donde desplegarsus aplicaciones de forma distribuida independientemente de los equipos fiacutesicosy el hardware que las soporten
DCOS es una herramienta que en un comienzo fue privativa pero cuyos res-ponsables la empresa Mesosphere decidieron publicar una versioacuten de coacutedigoEacutesta nos permite gestionar un cluster de una forma sencilla y usable ademaacutes decomplementarlo con otras herramientas como el balanceador de carga integradoo la autenticacioacuten de usuarios ademaacutes estaacute basada en Apache Mesos un pro-yecto de relativa madurez y con el soporte de la Apache Software FoundationDe forma resumida DCOS ofrece muchas posibilidades y servicios a cambiode una arquitectura e instalacioacuten maacutes compleja
Por su parte HashiCorp con menor tiempo de desarrollo ha conseguidouna herramienta muy sencilla de desplegar que ademaacutes cumple con todas lasfuncionalidades baacutesicas ejecutando un simple binario en cada nodo se puededesplegar un gestor de clusters totalmente funcional Sin embargo no cuentacon todas las posibilidades de Mesos (Nomad cuenta con menos controladoresque entornos posibles de Mesos) ni con los antildeadidos de DCOS lo que implicael uso de otras herramientas para complementar el servicio (Consul HAProxy)
De entre las dificultades encontradas al usar estas herramientas y desplegaraplicaciones sobre ellas se puede destacar la depuracioacuten en ocasiones se desco-noce si un error viene de la propia herramienta de la aplicacioacuten desplegada o delequipo fiacutesico si no se cuenta con un sistema de procesamiento de registro unose puede encontrar con muacuteltiples terminales abiertas inspeccionando numerososficheros de registro buscando posibles errores Ademaacutes no dejan de ser solucio-nes que para usar eficientemente se debe conocer parte de su funcionamientoy sintaxis a la hora de describir la tareas lo que supone un esfuerzo antildeadido yaque cada una tiene sus particularidades y liacutemites
45
82 Conclusiones
En una sociedad cada vez maacutes digital las empresas deben adaptarse a unmercado cuya demanda de contenido no deja de crecer Las nuevas arquitecturascomo microservicios asiacute como la gran cantidad de datos generada implica queuna mejor gestioacuten de los recursos y la rapidez para desplegar o escalar solucionesdando valor al cliente lo maacutes raacutepido posible es uno de los objetivos de todas lasempresas de base tecnoloacutegica
Las ventajas que ofrecen los planificadores con aplicaciones distribuidas sonnumerosas sin ir maacutes lejos empresas tan punteras como Google llevan maacutesde 10 antildeos orquestando contenedores24 Por un lado permiten aumentar elrendimiento de los equipos propios y por otro implementar un servicio comoplataforma para despliegues distribuidos sobre cualquier conjunto hardware deesta forma se provee un servicio similar al de la nube puacuteblica pero con laprincipal diferencia de que se elimina la independencia con el proveedor (vendorlock-in) esto es las aplicaciones no tienen limitaciones impuestas por eacuteste talescomo lenguaje de programacioacuten o herramientas y permite despliegues hiacutebridosentre recursos propios y la nube
83 Objetivos conseguidos
Implementacioacuten de los planificadores propuestos en la nube Se ha en-tendido y detallado el funcionamiento de estas herramientas y se hanimplementado en el servicio de infraestructura de Microsoft Azure
Despliegue de aplicaciones y servicios distribuidos Servicios que se usanactualmente en la industria del desarrollo software asiacute como una aplica-cioacuten web con una arquitectura moderna han sido desplegados de formadistribuida en los equipos cumpliendo con la funcionalidad esperada ade-maacutes de consiguiendo una alta disponibilidad
Aproximacioacuten de arquitectura escalable Se ha hecho una aproximacioacutende infraestructura escalable de forma que sea parcialmente extrapolable aotros proveedores
24httpwwwnextplatformcom20160322decade-container-control-google
46
84 Liacuteneas de investigacioacuten
Siguiendo con la materia de este proyecto se presentan posibles liacuteneas deinvestigacioacuten
Analizar el despliegue con estas herramientas de aplicaciones de Big Datay comparar la eficiencia con respecto a soluciones especializadas
Analizar el rendimiento de los algoritmos de planificacioacuten antes pruebasde estreacutes y situaciones de alta contienda
Comparar el uso de estas herramientas con las praacutecticas actuales de laindustria o implementacioacuten en un sistema de produccioacuten real
47
Referencias
[1] LA Barroso y U Houmllzle laquoThe Datacenter as a Computer An Introduc-tion to the Design of Warehouse-Scale Machinesraquo En Morgan amp ClaypoolPublishers ()
[2] Systems Research Group ndash NetOS (University of Cambridge) The evolu-tion of cluster scheduler architectures 2016 url httpswwwclcamacukresearchsrgnetoscamsasblog2016-03-09-scheduler-architectureshtml
[3] A Das I Gupta y A Motivala SWIM Scalable Weakly-consistent Infection-style Process Group Membership Protocol Inf teacutec Dept of ComputerScience Cornell University url https www cs cornell edu ~asdasresearchdsn02-swimpdf
[4] D Dubhashi y A Das Mastering Mesos PACKT Publishing mayo de2016
[5] The Apache Software Foundation Apache Mesos documentation urlhttpsmesosapacheorg
[6] David Greenberg Building Applications on Mesos OrsquoReilly Media 2016[7] Armand Grillet Comparison of Container Schedulers Inf teacutec Technische
Universitaumlt Berlin[8] HashiCorp Consul documentation url httpswwwconsulio[9] HashiCorp Nomad documentation url httpsdcosio[10] Dan C Marinescu Cloud computing theory and practice Morgan Kauf-
mann 2013[11] Mesosphere DCOS documentation url httpswwwnomadproject
io[12] Microsoft Azure documentation url httpsazuremicrosoftcom
es-esdocumentation[13] D Ongaro y J Ousterhout In Search of an Understandable Consensus
Algorithm Inf teacutec Stanford University url httpsraftgithubioraftpdf
[14] Fei Teng laquoRessource allocation and schelduling models for cloud compu-tingraquo Tesis de mtriacutea Ecole Centrale Paris 2011
[15] A Williams y col Automation and Orchestration with Docker and Contai-ners A Comprehensive Overview of the Docker and Container Ecosystem3 The New Stack 2016
48
- Resumen
- Summary
- Iacutendice de figuras
- Introduccioacuten y objetivos
-
- Contexto
- Objetivos
- Estructura del documento
-
- Cloud Computing
- Nuevas cargas de trabajo
- Gestioacuten de recursos Planificadores
-
- Sistemas distribuidos
-
- Clasificacioacuten
-
- Herramientas
-
- DCOS
-
- Apache Mesos
- Ejemplos de uso
-
- Nomad
-
- Protocolo de consenso Raft
- Protocolo gossip SWIM
- Planificacioacuten
-
- Casos de uso y despliegue
-
- Aplicacioacuten Web
-
- DCOS
- Nomad
-
- Servicio de integracioacuten continua
-
- DevOps
- Integracioacuten Continua
- Jenkins con Nomad
- Jenkins con DCOS
-
- Escalando la infraestructura
-
- Disentildeo
- Implementacioacuten
-
- Resultados y conclusiones
-
- Comparacioacuten
- Conclusiones
- Objetivos conseguidos
- Liacuteneas de investigacioacuten
-
Figura 20 Despliegue en Azure de Nomad+Consul
Cabe matizar que los balanceadores basados en HAProxy se implementanpor necesidad de la aplicacioacuten para el descubrimiento del servicio a diferenciade los de Azure que se implementan por motivos de seguridad y escalabilidaddel cluster en siacute
Configuracioacuten Nomad
Los ficheros de configuracioacuten de las maacutequinas maacutester y cliente son similaresy comparten la mayoriacutea de las opciones como por ejemplo el nombre del nodoo la interfaz de red donde escucha Nomad las peticiones Sus opciones son engeneral auto-explicativas sin embargo existen dos detalles que matizar
El proceso de Nomad escucha las peticiones tanto de los protocolos deconsenso como del usuario a traveacutes de una interfaz de red que se debeindicar en el fichero de configuracioacuten
En el caso de los clientes se deben indicar las direcciones de los servidoresdel cluster sin embargo se trata de un sistema dinaacutemico en el que losnodos pueden sufrir errores y cambiar de direccioacuten Por ello se ha definidoNomad como un servicio de Consul y asiacute poder definir la direccioacuten de losservidores como un nombre de dominio no por su direccioacuten fiacutesica que elservidor DNS de Consul se encargaraacute de resolver
Por defecto Nomad usa los siguientes puertos
API HTTP 4646 Peticiones HTTP y recepcioacuten de oacuterdenes mediante laliacutenea de comandos
RPC 4647 Protocolo de consenso entre los nodos del cluster
Serf 4648 Protocolo de gossip entre los servidores de los centros de datosgobernados por Nomad
35
Los dos uacuteltimos deben ser interfaces alcanzables por otros nodos sin embargo laAPI HTTP por motivos de seguridad deberiacutea ser local ya que en caso contrariocualquier persona con acceso a ella tiene el control sobre la herramienta Eacutestasolo deberiacutea estar accesible en un servidor o gestionarlo mediante una terminalSSH por ejemplo En este trabajo al ser una prueba de concepto se ha abiertoen todos los nodos
Trabajos de Nomad
Las tareas se detallan en ficheros con formato HashiCorp Configuration Lan-guage un derivado del formato JSON creado por la empresa que le da nombrecompatible con eacuteste y que permite comentarios
En estos ficheros se puede definir
La regioacuten y el centro de datos donde se ejecutaraacute (Nomad permite lagestioacuten de centros de datos geograacuteficamente distribuidos en regiones)
La poliacutetica de actualizacioacuten de la tarea
Grupo de tareas esto es que se ejecutaraacuten en el mismo nodo
El nuacutemero de grupos a ejecutarescalar asiacute como los liacutemite que debencumplir los nodos asignados
La poliacutetica de reinicio ante fallo o error
Tareas El controlador su configuracioacuten los paraacutemetros del servicio aso-ciado a registrar en Consul asiacute como los recursos que consume (puertosmemoria)
En nuestro caso usamos sobre todo el controlador Docker esto eso orques-tacioacuten de contenedores en los nodos clientes y tres de sus opciones
Imagen del contenedor Se han subido todas las imaacutegenes del proyecto a Doc-ker Hub donde por defecto se busca la imagen
Puertos Los puertos a usar por el contenedor que pueden ser estaacuteticos asigna-dos por el usuario o dinaacutemicos siendo Nomad el que se encarga de mapearun puerto libre del nodo cliente al expuesto por el contenedor
Servidores DNS Como usamos la interfaz DNS de Consul como descubri-miento de servicio se debe configurar el contenedor para que use cualquiernodo del cluster como servidor DNS
Configuracioacuten Consul
Al ser desarrolladas por la misma empresa los ficheros de configuracioacuten deConsul y Nomad comparten muchas opciones Consul tambieacuten acepta peticionesa traveacutes de una interfaz de red siendo los puertos usados por defecto
36
RPC 8300 8400 Maneja la peticiones del resto de nodos y usuarios
Serf 8301 8302 Protocolo gossip
HTTP API 8500
HTTPS API Desactivada por defecto
Interfaz DNS 8600
Se debe asignar a los protocolos internos del cluster esto es RPC y Serf unainterfaz alcanzable por los nodos y por el contrarioasignar a los dos uacuteltimos ala interfaz de loopback por motivos de seguridad
Cabe destacar que Consul tambieacuten cuenta con una interfaz graacutefica que per-mite ver el estado de los equipos y los servicios registrados y que se encuentra enel mismo puerto que la API HTTP en la direccioacuten httpIP_EQUIPO8500ui
Ejecucioacuten
Tanto Nomad como Consul requieren de la ejecucioacuten de un fichero en todoslos nodos integrantes del cluster Como prueba de concepto se ha decidido usardos servidores para ambos aunque cabe matizar que es un nuacutemero ineficienteya que la caiacuteda de uno de ellos supondriacutea la peacuterdida del cuoacuterum y por tantodel consenso del cluster
En primer lugar se arrancan los servidores que son los encargados de ejecu-tar el protocolo de consenso y gestionar el cluster y a continuacioacuten los clientesque no tienen praacutecticamente estado y dependen de los servidores
En el caso de Consul se debe indicar el directorio donde se guardan losficheros que describen los servicios asiacute como el archivo que especifica el resto delas opciones
1 Se inicia el primer servidor en uno de los equipos
$ consu l agent minuscon f i gminusd i r e t c consu l d s e r v i c e s minuscon f i gminus f i l e consu l_server j son
2 Los siguientes equipos deben unirse al anterior por lo que antildeadimos elargumento join con la direccioacuten del primer servidor Para el caso de otrosservidores
$ consu l agent minuscon f i gminusd i r e t c consu l d s e r v i c e s minuscon f i gminus f i l e consu l_server j son minus j o i n ltIP_servidor1gt
37
Una vez los servidores han alcanzado el consenso y elegido un liacuteder en losclientes
$ consu l agent minuscon f i gminusd i r e t c consu l d s e r v i c e s minuscon f i gminus f i l e c on su l_c l i en t j son minus j o i n ltIP_cualquierServ idorgt
El proceso para iniciar Nomad es igual y los comandos similares sin embargoya no es necesario indicar una direccioacuten IP fija en los equipos sino el nombre dedominio del servicio de Nomad registrado por Consul En el primer servidor
$ nomad agent minusc on f i g nomad_server j son
Y el resto de equipos (con su fichero de configuracioacuten correspondiente)$ nomad agent minusc on f i g nomad_server j son minus j o i n nomad s e r v i c e consu l
Por uacuteltimo para desplegar la aplicacioacuten web se han escrito tres ficherosque detallan las tareas de la interfaz web API y los balanceadores de cargaMediante la CLI
$ nomad run minusaddress=http lt ip_c lus te r gt4646 lt f i l e hclgt
O mediante la API HTTP de Nomad$ cu r l minusX POST minusd ltf i l e hclgthttp lt ip_c lus te r gt4646 jobltjob_namegt
Ansible
Como se puede comprobar con el aumento del nuacutemero de equipos pasa aser inviable manejar todos los nodos a traveacutes de terminal Ademaacutes como seha comentado con anterioridad Nomad requiere que en los nodos clientes es-teacuten instalados las herramientas que soporten las tareas por ejemplo el motorde Docker Por ello para facilitar tanto el arranque como la instalacioacuten de lasdependencias vamos a usar Ansible una herramienta de coacutedigo abierto desarro-llada en Python que permite gestionar configuraciones aprovisionar recursosdespliegue de aplicaciones de forma automaacutetica
A grandes rasgos esta herramienta funciona mediante ficheros en formatoYAML denominados play-books que describen un conjunto de pasos a ejecutaren una lista de equipos remotos Estos pasos son ejecutados por moacutedulos inde-pendientes a traveacutes de SSH es decir en cualquier ordenador con conexioacuten a los
38
hosts dado su contrasentildea o clave puacuteblica puede arrancar el script y realizariacutealos pasos de forma remota gestionando el cluster desde un solo equipo
Se han desarrollado guiones para lo siguiente
Descarga de los binarios de Nomad y Consul en todos los nodos copiade los ficheros de configuracioacuten baacutesicos y modificarlos de acuerdo a cadanodo (nombre del equipo direccioacuten IP)
Instalacioacuten de las dependencias
Arranque de Nomad y Consul
Ansible extiende su funcionalidad a traveacutes de moacutedulos independientes que per-miten por ejemplo instalar paquetes mediante herramientas de gestioacuten de pa-quetes (APT yum) aprovisionar automaacuteticamente maacutequinas virtuales de Ama-zon EC2
Algunas opciones de los ficheros de configuracioacuten de Nomad y Consul sondependientes del nodo particular por ejemplo la interfaz de red Para estetrabajo se ha realizado un moacutedulo para modificar los ficheros de configuracioacutende forma automaacutetica En el repositorio del proyecto se encuentra una carpetadonde se encuentran todos los ficheros necesarios para desplegar un clustertotalmente funcional solo requiere de una liacutenea de terminal con Ansible
$ ans ib l eminusplaybook minus i hos t s minusk ltssh_passgt minusu ltnode_usergt s i t e yml
39
62 Servicio de integracioacuten continua
Se ha implementado un sistema de integracioacuten continua que permite ejecu-tar tareas de compilacioacuten y pruebas de forma distribuida aumentando asiacute elrendimiento de los equipos En primer lugar se detallaraacute los motivos por los quepuede resultar beneficioso para las empresas una implementacioacuten de este tipo alo que seguiraacute los detalles del despliegue
621 DevOps
Metodologiacutea que defiende la comunicacioacuten y colaboracioacuten entre desarrolla-dores de software y los profesionales de operaciones a lo largo de todo el ciclo devida de una aplicacioacuten Estaacute muy relacionado con el desarrollo aacutegil de softwareesto es un enfoque para los proyectos que defiende el desarrollo iterativo e in-cremental donde los requisitos y soluciones evolucionan con el tiempo seguacuten lanecesidad del proyecto DevOps extiende esta filosofiacutea a todas los componentesde un servicio incluyendo sistemas y operaciones
Se trata de un concepto que cada organizacioacuten o empresa adapta a suspropias necesidades y procesos de negocio en este proyecto nos vamos a centraren la integracioacuten continua una praacutectica fundamental tanto del desarrollo aacutegilcomo de esta filosofiacutea
622 Integracioacuten Continua
Se define como una praacutectica de desarrollo software donde los miembros delequipo ponen en comuacuten su trabajo frecuentemente al menos una vez al diacutea21Cada integracioacuten se verifica con una compilacioacuten automaacutetica que incluye laejecucioacuten de pruebas para detectar errores de integracioacuten tan pronto como seaposible
Desde el punto de vista operativo esto supone automatizar la configuracioacutende equipos o el despliegue de maacutequinas virtuales donde compilar el proyecto yejecutar las pruebas y posteriormente eliminarlas Este flujo de trabajo se vebeneficiado en entornos distribuidos ya que el objetivo del desarrollador es com-probar el resultado de las pruebas raacutepidamente sin preocuparse del despliegueo los propios equipos
Para esta prueba de concepto vamos a usar Jenkins un servidor de integra-cioacuten continua escrito en Java que nos permite definir trabajos que contendraacutenla descripcioacuten tanto del entorno como su ejecucioacuten
Este sigue una estructura maestro-esclavo muy similar al de los gestores declusters usados en este proyecto el maestro contiene toda la loacutegica del servicio
21httpmartinfowlercomarticlescontinuousIntegrationhtml
40
trabajos autenticacioacuten y los esclavos son los encargados de la ejecucioacuten ensiacute Jenkins tiene varias viacuteas para aprovisionar los uacuteltimos
Mediante SSH
Interfaz graacutefica
Desarrollar un script propio
Ejecucioacuten de un fichero java
La ventaja de usar planificadores es que el despliegue de esclavos es dinaacutemicoes decir no tener una maacutequina especiacuteficamente configurada para ello DCOS yNomad se encargaraacuten de configurar estos despliegues en sus maacutequinas y poste-riormente eliminarlos Para ello se ha usado la uacuteltima opcioacuten definiendo tareasque descarguen el fichero java Con todo ello se consigue un entorno de inte-gracioacuten continua eficiente que ademaacutes permite la ejecucioacuten de otros servicios deforma independiente
Jenkins permite la creacioacuten de plugins que extienden sus funcionalidadesTanto Nomad22 como Apache Mesos cuentan con uno que permite su integra-cioacuten
Para esta prueba se va a usar el mismo proyecto que para el caso de usode orquestacioacuten de contenedores la aplicacioacuten web al que se le ha antildeadido untest para comprobar que se conecta correctamente a la base de datos medianteMocha un framework de Nodejs Por otro lado se antildeade el plugin de git ya queel coacutedigo se obtiene de GitHub el repositorio remoto de control de versiones delproyecto
El proceso general de ejecucioacuten seriacutea como sigue
1 Se ejecuta el maestro de Jenkins como tarea Docker partiendo de la imagenoficial
2 Al arrancar un trabajo se manda una tarea a los planificadores que laasignaraacuten a un nodo cliente Esta tarea consiste en la descarga del ficherode configuracioacuten Java y arrancarlo configurando el equipo como un clientede Jenkins temporalmente
3 Jenkins ejecuta el trabajo en el nuevo cliente en este caso iniciar la apli-cacioacuten web iniciar las pruebas y generar un informe
4 Se elimina el cliente
A continuacioacuten se detallan los matices de cada herramienta a la hora de imple-mentar este servicio
22Desarrollado por Ivo Verberk httpwwwivoverberknl
41
623 Jenkins con Nomad
El plugin permite la ejecucioacuten del fichero Java mediante dos controladorescontenedores Docker y Java En este proyecto nos hemos decantado por el pri-mero ya que nos ahorra instalar la maacutequina virtual de java en todos los nodoscliente Por ello se ha construido un contenedor base con Java para la ejecucioacutendel fichero de configuracioacuten y Nodejs para lanzar la aplicacioacuten web
El plugin se configura con la direccioacuten IP del cluster y el contenedor queejecuta el esclavo Jenkins Por su parte el trabajo en Jenkins se define conel repositorio en GitHub donde se aloja el coacutedigo del proyecto a probar y loscomandos a ejecutar en este caso npm update y npm test
624 Jenkins con DCOS
En el caso de DCOS su sistema de paquetes incluye Jenkins por lo queal instalarlo ya se tiene la configuracioacuten de Mesos totalmente funcional Sinembargo para ejecutar la aplicacioacuten en particular y las pruebas se requiere deNodejs en los equipos esclavos por ello debemos antildeadir un plugin de Jenkinsque permite instalar este entorno antes de ejecutar el trabajo Una vez hechoesto soacutelo queda definir la tarea igual que en el caso anterior
Cabe destacar que Mesosphere tambieacuten ha desarrollado un plugin que per-mite hacer despliegues en Marathon de tal manera que permitiriacutea con cadacommit del coacutedigo compilar la imagen del contenedor Docker y desplegarlaautomaacuteticamente aunque en este proyecto no se ha hecho pruebas de esta fun-cionalidad
42
7 Escalando la infraestructura
Uno de los factores clave que se busca a la hora de implementar sistemasdistribuidos es el poder escalar la infraestructura de forma maacutes sencilla estoes detectar que las maacutequinas estaacuten alcanzando el liacutemite de su capacidad yaumentar eacutesta ya sea mejorando sus caracteriacutesticas teacutecnicas o antildeadiendo maacutesnodos al cluster
El coacutedigo y todos los ficheros de configuracioacuten de esta seccioacuten tambieacuten sepueden encontrar en el repositorio del proyecto en GitHub23
71 Disentildeo
Microsoft Azure permite organizar los servicios cloud de forma loacutegica a traveacutesde grupos de recursos y asiacute poder crear o eliminar eacutestos en conjunto parauna aplicacioacuten determinada (por ejemplo una aplicacioacuten web suele requerir demaacutequinas virtuales bases de datos almacenamiento) Ademaacutes dispone dela opcioacuten de crear plantillas en formato JSON que permite al desarrolladordefinir los recursos y su interrelacioacuten para desplegar de forma automaacutetica unainfraestructura TI en la nube
Azure tambieacuten ofrece la posibilidad de monitorizar el estado de las maacutequinasvirtuales a traveacutes de extensiones lo que permite configurar el escalado automaacute-tico al alcanzar cierto liacutemite definido por el operador Eacutesta es a priori la formaen que deberiacutea implementarse hablando en teacuterminos de eficiencia sin embargoesta aproximacioacuten es totalmente dependiente de la plataforma es decir no sepuede extrapolar a otro proveedor o sobre recursos propios sin realizar un nue-vo disentildeo En este proyecto las tareas que son ejecutadas por estos equipos notienen estado ya que todo lo relativo a la persistencia lo hemos asignado fueradel cluster esto permite escalar la plataforma a traveacutes de otra aproximaciones
Las plantillas aceptan una serie de variables a indicar por el usuario entreotras los conjuntos de escala para definir los nodos aceptan una variable quedefine el nuacutemero de maacutequinas que los componen Por otro lado Azure ofreceuna API REST y kits de desarrollo software (SDK por sus siglas en ingleacutes) quepermiten su despliegue de forma programaacutetica Aprovechando estas facilidadesen este proyecto se va a aproximar la escalabilidad con el sucesivo desplieguede la infraestructura de forma automaacutetica se monitorizan los equipos y si sedetecta una maacutequina excesivamente cargada se aumenta el nuacutemero de equiposen la plantilla y se vuelve a desplegar
23httpsgithubcomAntonioAlfrzCloud-Orchestrators
43
En este proyecto se han disentildeado las plantillas para desplegar la arquitec-tura necesaria tanto de Nomad como de DCOS En el caso de la primera eldespliegue es maacutes descriptivo ya que incluye maacutequinas virtuales grupos de se-guridad redes En el caso de DCOS Azure cuenta con un servicio especiacuteficopara clusters gobernados por DCOS denominado Azure Container Service queincluye los componentes necesarios y la instalacioacuten ya realizada
72 Implementacioacuten
En primer lugar para monitorizar el estado de los equipos se va a usar laherramienta Nagios un sistema que permite controlar el estado del hardwarey los servicios de un equipo Se trata de una herramienta muy completa de laque se va a usar su capacidad para ejecutar comandos (plugins) en los nodospara detectar picos de carga generar alertas y ejecutar programas para estoseventos
Se ha desplegado una maacutequina virtual con esta herramienta en ambos siste-mas y se ha instalado una extensioacuten de Nagios (Nagios Remote Plugin Executor)en todos los nodos que permite ejecutar comprobaciones remotamente en con-creto para esta prueba de concepto medir el nivel de saturacioacuten de la unidadcentral de procesamiento (CPU por sus siglas del ingleacutes) Cuando sucede uncambio de estado de una maacutequina esto es cuando este paraacutemetro supera el liacutemi-te definido por el operador Nagios permite actuar en consecuencia ejecutandoprogramas por ello se ha desarrollado un script que ejecuta lo siguiente
Un programa desarrollado en Python con el SDK de Azure que modificalas plantillas y despliega los recursos
Un guioacuten de Ansible para instalar todos los componentes necesarios en lasnuevas maacutequinas y arrancar de nuevo el cluster y las aplicaciones
44
8 Resultados y conclusiones
En este uacuteltimo apartado se da una visioacuten global del proyecto asiacute como a lasconclusiones maacutes importantes a las que se ha llegado y posibles temas futurosde desarrollo
81 Comparacioacuten
Ambas herramientas ofrecen las funcionalidades para gestionar los recursoseficientemente ofreciendo a los desarrolladores una plataforma donde desplegarsus aplicaciones de forma distribuida independientemente de los equipos fiacutesicosy el hardware que las soporten
DCOS es una herramienta que en un comienzo fue privativa pero cuyos res-ponsables la empresa Mesosphere decidieron publicar una versioacuten de coacutedigoEacutesta nos permite gestionar un cluster de una forma sencilla y usable ademaacutes decomplementarlo con otras herramientas como el balanceador de carga integradoo la autenticacioacuten de usuarios ademaacutes estaacute basada en Apache Mesos un pro-yecto de relativa madurez y con el soporte de la Apache Software FoundationDe forma resumida DCOS ofrece muchas posibilidades y servicios a cambiode una arquitectura e instalacioacuten maacutes compleja
Por su parte HashiCorp con menor tiempo de desarrollo ha conseguidouna herramienta muy sencilla de desplegar que ademaacutes cumple con todas lasfuncionalidades baacutesicas ejecutando un simple binario en cada nodo se puededesplegar un gestor de clusters totalmente funcional Sin embargo no cuentacon todas las posibilidades de Mesos (Nomad cuenta con menos controladoresque entornos posibles de Mesos) ni con los antildeadidos de DCOS lo que implicael uso de otras herramientas para complementar el servicio (Consul HAProxy)
De entre las dificultades encontradas al usar estas herramientas y desplegaraplicaciones sobre ellas se puede destacar la depuracioacuten en ocasiones se desco-noce si un error viene de la propia herramienta de la aplicacioacuten desplegada o delequipo fiacutesico si no se cuenta con un sistema de procesamiento de registro unose puede encontrar con muacuteltiples terminales abiertas inspeccionando numerososficheros de registro buscando posibles errores Ademaacutes no dejan de ser solucio-nes que para usar eficientemente se debe conocer parte de su funcionamientoy sintaxis a la hora de describir la tareas lo que supone un esfuerzo antildeadido yaque cada una tiene sus particularidades y liacutemites
45
82 Conclusiones
En una sociedad cada vez maacutes digital las empresas deben adaptarse a unmercado cuya demanda de contenido no deja de crecer Las nuevas arquitecturascomo microservicios asiacute como la gran cantidad de datos generada implica queuna mejor gestioacuten de los recursos y la rapidez para desplegar o escalar solucionesdando valor al cliente lo maacutes raacutepido posible es uno de los objetivos de todas lasempresas de base tecnoloacutegica
Las ventajas que ofrecen los planificadores con aplicaciones distribuidas sonnumerosas sin ir maacutes lejos empresas tan punteras como Google llevan maacutesde 10 antildeos orquestando contenedores24 Por un lado permiten aumentar elrendimiento de los equipos propios y por otro implementar un servicio comoplataforma para despliegues distribuidos sobre cualquier conjunto hardware deesta forma se provee un servicio similar al de la nube puacuteblica pero con laprincipal diferencia de que se elimina la independencia con el proveedor (vendorlock-in) esto es las aplicaciones no tienen limitaciones impuestas por eacuteste talescomo lenguaje de programacioacuten o herramientas y permite despliegues hiacutebridosentre recursos propios y la nube
83 Objetivos conseguidos
Implementacioacuten de los planificadores propuestos en la nube Se ha en-tendido y detallado el funcionamiento de estas herramientas y se hanimplementado en el servicio de infraestructura de Microsoft Azure
Despliegue de aplicaciones y servicios distribuidos Servicios que se usanactualmente en la industria del desarrollo software asiacute como una aplica-cioacuten web con una arquitectura moderna han sido desplegados de formadistribuida en los equipos cumpliendo con la funcionalidad esperada ade-maacutes de consiguiendo una alta disponibilidad
Aproximacioacuten de arquitectura escalable Se ha hecho una aproximacioacutende infraestructura escalable de forma que sea parcialmente extrapolable aotros proveedores
24httpwwwnextplatformcom20160322decade-container-control-google
46
84 Liacuteneas de investigacioacuten
Siguiendo con la materia de este proyecto se presentan posibles liacuteneas deinvestigacioacuten
Analizar el despliegue con estas herramientas de aplicaciones de Big Datay comparar la eficiencia con respecto a soluciones especializadas
Analizar el rendimiento de los algoritmos de planificacioacuten antes pruebasde estreacutes y situaciones de alta contienda
Comparar el uso de estas herramientas con las praacutecticas actuales de laindustria o implementacioacuten en un sistema de produccioacuten real
47
Referencias
[1] LA Barroso y U Houmllzle laquoThe Datacenter as a Computer An Introduc-tion to the Design of Warehouse-Scale Machinesraquo En Morgan amp ClaypoolPublishers ()
[2] Systems Research Group ndash NetOS (University of Cambridge) The evolu-tion of cluster scheduler architectures 2016 url httpswwwclcamacukresearchsrgnetoscamsasblog2016-03-09-scheduler-architectureshtml
[3] A Das I Gupta y A Motivala SWIM Scalable Weakly-consistent Infection-style Process Group Membership Protocol Inf teacutec Dept of ComputerScience Cornell University url https www cs cornell edu ~asdasresearchdsn02-swimpdf
[4] D Dubhashi y A Das Mastering Mesos PACKT Publishing mayo de2016
[5] The Apache Software Foundation Apache Mesos documentation urlhttpsmesosapacheorg
[6] David Greenberg Building Applications on Mesos OrsquoReilly Media 2016[7] Armand Grillet Comparison of Container Schedulers Inf teacutec Technische
Universitaumlt Berlin[8] HashiCorp Consul documentation url httpswwwconsulio[9] HashiCorp Nomad documentation url httpsdcosio[10] Dan C Marinescu Cloud computing theory and practice Morgan Kauf-
mann 2013[11] Mesosphere DCOS documentation url httpswwwnomadproject
io[12] Microsoft Azure documentation url httpsazuremicrosoftcom
es-esdocumentation[13] D Ongaro y J Ousterhout In Search of an Understandable Consensus
Algorithm Inf teacutec Stanford University url httpsraftgithubioraftpdf
[14] Fei Teng laquoRessource allocation and schelduling models for cloud compu-tingraquo Tesis de mtriacutea Ecole Centrale Paris 2011
[15] A Williams y col Automation and Orchestration with Docker and Contai-ners A Comprehensive Overview of the Docker and Container Ecosystem3 The New Stack 2016
48
- Resumen
- Summary
- Iacutendice de figuras
- Introduccioacuten y objetivos
-
- Contexto
- Objetivos
- Estructura del documento
-
- Cloud Computing
- Nuevas cargas de trabajo
- Gestioacuten de recursos Planificadores
-
- Sistemas distribuidos
-
- Clasificacioacuten
-
- Herramientas
-
- DCOS
-
- Apache Mesos
- Ejemplos de uso
-
- Nomad
-
- Protocolo de consenso Raft
- Protocolo gossip SWIM
- Planificacioacuten
-
- Casos de uso y despliegue
-
- Aplicacioacuten Web
-
- DCOS
- Nomad
-
- Servicio de integracioacuten continua
-
- DevOps
- Integracioacuten Continua
- Jenkins con Nomad
- Jenkins con DCOS
-
- Escalando la infraestructura
-
- Disentildeo
- Implementacioacuten
-
- Resultados y conclusiones
-
- Comparacioacuten
- Conclusiones
- Objetivos conseguidos
- Liacuteneas de investigacioacuten
-
Los dos uacuteltimos deben ser interfaces alcanzables por otros nodos sin embargo laAPI HTTP por motivos de seguridad deberiacutea ser local ya que en caso contrariocualquier persona con acceso a ella tiene el control sobre la herramienta Eacutestasolo deberiacutea estar accesible en un servidor o gestionarlo mediante una terminalSSH por ejemplo En este trabajo al ser una prueba de concepto se ha abiertoen todos los nodos
Trabajos de Nomad
Las tareas se detallan en ficheros con formato HashiCorp Configuration Lan-guage un derivado del formato JSON creado por la empresa que le da nombrecompatible con eacuteste y que permite comentarios
En estos ficheros se puede definir
La regioacuten y el centro de datos donde se ejecutaraacute (Nomad permite lagestioacuten de centros de datos geograacuteficamente distribuidos en regiones)
La poliacutetica de actualizacioacuten de la tarea
Grupo de tareas esto es que se ejecutaraacuten en el mismo nodo
El nuacutemero de grupos a ejecutarescalar asiacute como los liacutemite que debencumplir los nodos asignados
La poliacutetica de reinicio ante fallo o error
Tareas El controlador su configuracioacuten los paraacutemetros del servicio aso-ciado a registrar en Consul asiacute como los recursos que consume (puertosmemoria)
En nuestro caso usamos sobre todo el controlador Docker esto eso orques-tacioacuten de contenedores en los nodos clientes y tres de sus opciones
Imagen del contenedor Se han subido todas las imaacutegenes del proyecto a Doc-ker Hub donde por defecto se busca la imagen
Puertos Los puertos a usar por el contenedor que pueden ser estaacuteticos asigna-dos por el usuario o dinaacutemicos siendo Nomad el que se encarga de mapearun puerto libre del nodo cliente al expuesto por el contenedor
Servidores DNS Como usamos la interfaz DNS de Consul como descubri-miento de servicio se debe configurar el contenedor para que use cualquiernodo del cluster como servidor DNS
Configuracioacuten Consul
Al ser desarrolladas por la misma empresa los ficheros de configuracioacuten deConsul y Nomad comparten muchas opciones Consul tambieacuten acepta peticionesa traveacutes de una interfaz de red siendo los puertos usados por defecto
36
RPC 8300 8400 Maneja la peticiones del resto de nodos y usuarios
Serf 8301 8302 Protocolo gossip
HTTP API 8500
HTTPS API Desactivada por defecto
Interfaz DNS 8600
Se debe asignar a los protocolos internos del cluster esto es RPC y Serf unainterfaz alcanzable por los nodos y por el contrarioasignar a los dos uacuteltimos ala interfaz de loopback por motivos de seguridad
Cabe destacar que Consul tambieacuten cuenta con una interfaz graacutefica que per-mite ver el estado de los equipos y los servicios registrados y que se encuentra enel mismo puerto que la API HTTP en la direccioacuten httpIP_EQUIPO8500ui
Ejecucioacuten
Tanto Nomad como Consul requieren de la ejecucioacuten de un fichero en todoslos nodos integrantes del cluster Como prueba de concepto se ha decidido usardos servidores para ambos aunque cabe matizar que es un nuacutemero ineficienteya que la caiacuteda de uno de ellos supondriacutea la peacuterdida del cuoacuterum y por tantodel consenso del cluster
En primer lugar se arrancan los servidores que son los encargados de ejecu-tar el protocolo de consenso y gestionar el cluster y a continuacioacuten los clientesque no tienen praacutecticamente estado y dependen de los servidores
En el caso de Consul se debe indicar el directorio donde se guardan losficheros que describen los servicios asiacute como el archivo que especifica el resto delas opciones
1 Se inicia el primer servidor en uno de los equipos
$ consu l agent minuscon f i gminusd i r e t c consu l d s e r v i c e s minuscon f i gminus f i l e consu l_server j son
2 Los siguientes equipos deben unirse al anterior por lo que antildeadimos elargumento join con la direccioacuten del primer servidor Para el caso de otrosservidores
$ consu l agent minuscon f i gminusd i r e t c consu l d s e r v i c e s minuscon f i gminus f i l e consu l_server j son minus j o i n ltIP_servidor1gt
37
Una vez los servidores han alcanzado el consenso y elegido un liacuteder en losclientes
$ consu l agent minuscon f i gminusd i r e t c consu l d s e r v i c e s minuscon f i gminus f i l e c on su l_c l i en t j son minus j o i n ltIP_cualquierServ idorgt
El proceso para iniciar Nomad es igual y los comandos similares sin embargoya no es necesario indicar una direccioacuten IP fija en los equipos sino el nombre dedominio del servicio de Nomad registrado por Consul En el primer servidor
$ nomad agent minusc on f i g nomad_server j son
Y el resto de equipos (con su fichero de configuracioacuten correspondiente)$ nomad agent minusc on f i g nomad_server j son minus j o i n nomad s e r v i c e consu l
Por uacuteltimo para desplegar la aplicacioacuten web se han escrito tres ficherosque detallan las tareas de la interfaz web API y los balanceadores de cargaMediante la CLI
$ nomad run minusaddress=http lt ip_c lus te r gt4646 lt f i l e hclgt
O mediante la API HTTP de Nomad$ cu r l minusX POST minusd ltf i l e hclgthttp lt ip_c lus te r gt4646 jobltjob_namegt
Ansible
Como se puede comprobar con el aumento del nuacutemero de equipos pasa aser inviable manejar todos los nodos a traveacutes de terminal Ademaacutes como seha comentado con anterioridad Nomad requiere que en los nodos clientes es-teacuten instalados las herramientas que soporten las tareas por ejemplo el motorde Docker Por ello para facilitar tanto el arranque como la instalacioacuten de lasdependencias vamos a usar Ansible una herramienta de coacutedigo abierto desarro-llada en Python que permite gestionar configuraciones aprovisionar recursosdespliegue de aplicaciones de forma automaacutetica
A grandes rasgos esta herramienta funciona mediante ficheros en formatoYAML denominados play-books que describen un conjunto de pasos a ejecutaren una lista de equipos remotos Estos pasos son ejecutados por moacutedulos inde-pendientes a traveacutes de SSH es decir en cualquier ordenador con conexioacuten a los
38
hosts dado su contrasentildea o clave puacuteblica puede arrancar el script y realizariacutealos pasos de forma remota gestionando el cluster desde un solo equipo
Se han desarrollado guiones para lo siguiente
Descarga de los binarios de Nomad y Consul en todos los nodos copiade los ficheros de configuracioacuten baacutesicos y modificarlos de acuerdo a cadanodo (nombre del equipo direccioacuten IP)
Instalacioacuten de las dependencias
Arranque de Nomad y Consul
Ansible extiende su funcionalidad a traveacutes de moacutedulos independientes que per-miten por ejemplo instalar paquetes mediante herramientas de gestioacuten de pa-quetes (APT yum) aprovisionar automaacuteticamente maacutequinas virtuales de Ama-zon EC2
Algunas opciones de los ficheros de configuracioacuten de Nomad y Consul sondependientes del nodo particular por ejemplo la interfaz de red Para estetrabajo se ha realizado un moacutedulo para modificar los ficheros de configuracioacutende forma automaacutetica En el repositorio del proyecto se encuentra una carpetadonde se encuentran todos los ficheros necesarios para desplegar un clustertotalmente funcional solo requiere de una liacutenea de terminal con Ansible
$ ans ib l eminusplaybook minus i hos t s minusk ltssh_passgt minusu ltnode_usergt s i t e yml
39
62 Servicio de integracioacuten continua
Se ha implementado un sistema de integracioacuten continua que permite ejecu-tar tareas de compilacioacuten y pruebas de forma distribuida aumentando asiacute elrendimiento de los equipos En primer lugar se detallaraacute los motivos por los quepuede resultar beneficioso para las empresas una implementacioacuten de este tipo alo que seguiraacute los detalles del despliegue
621 DevOps
Metodologiacutea que defiende la comunicacioacuten y colaboracioacuten entre desarrolla-dores de software y los profesionales de operaciones a lo largo de todo el ciclo devida de una aplicacioacuten Estaacute muy relacionado con el desarrollo aacutegil de softwareesto es un enfoque para los proyectos que defiende el desarrollo iterativo e in-cremental donde los requisitos y soluciones evolucionan con el tiempo seguacuten lanecesidad del proyecto DevOps extiende esta filosofiacutea a todas los componentesde un servicio incluyendo sistemas y operaciones
Se trata de un concepto que cada organizacioacuten o empresa adapta a suspropias necesidades y procesos de negocio en este proyecto nos vamos a centraren la integracioacuten continua una praacutectica fundamental tanto del desarrollo aacutegilcomo de esta filosofiacutea
622 Integracioacuten Continua
Se define como una praacutectica de desarrollo software donde los miembros delequipo ponen en comuacuten su trabajo frecuentemente al menos una vez al diacutea21Cada integracioacuten se verifica con una compilacioacuten automaacutetica que incluye laejecucioacuten de pruebas para detectar errores de integracioacuten tan pronto como seaposible
Desde el punto de vista operativo esto supone automatizar la configuracioacutende equipos o el despliegue de maacutequinas virtuales donde compilar el proyecto yejecutar las pruebas y posteriormente eliminarlas Este flujo de trabajo se vebeneficiado en entornos distribuidos ya que el objetivo del desarrollador es com-probar el resultado de las pruebas raacutepidamente sin preocuparse del despliegueo los propios equipos
Para esta prueba de concepto vamos a usar Jenkins un servidor de integra-cioacuten continua escrito en Java que nos permite definir trabajos que contendraacutenla descripcioacuten tanto del entorno como su ejecucioacuten
Este sigue una estructura maestro-esclavo muy similar al de los gestores declusters usados en este proyecto el maestro contiene toda la loacutegica del servicio
21httpmartinfowlercomarticlescontinuousIntegrationhtml
40
trabajos autenticacioacuten y los esclavos son los encargados de la ejecucioacuten ensiacute Jenkins tiene varias viacuteas para aprovisionar los uacuteltimos
Mediante SSH
Interfaz graacutefica
Desarrollar un script propio
Ejecucioacuten de un fichero java
La ventaja de usar planificadores es que el despliegue de esclavos es dinaacutemicoes decir no tener una maacutequina especiacuteficamente configurada para ello DCOS yNomad se encargaraacuten de configurar estos despliegues en sus maacutequinas y poste-riormente eliminarlos Para ello se ha usado la uacuteltima opcioacuten definiendo tareasque descarguen el fichero java Con todo ello se consigue un entorno de inte-gracioacuten continua eficiente que ademaacutes permite la ejecucioacuten de otros servicios deforma independiente
Jenkins permite la creacioacuten de plugins que extienden sus funcionalidadesTanto Nomad22 como Apache Mesos cuentan con uno que permite su integra-cioacuten
Para esta prueba se va a usar el mismo proyecto que para el caso de usode orquestacioacuten de contenedores la aplicacioacuten web al que se le ha antildeadido untest para comprobar que se conecta correctamente a la base de datos medianteMocha un framework de Nodejs Por otro lado se antildeade el plugin de git ya queel coacutedigo se obtiene de GitHub el repositorio remoto de control de versiones delproyecto
El proceso general de ejecucioacuten seriacutea como sigue
1 Se ejecuta el maestro de Jenkins como tarea Docker partiendo de la imagenoficial
2 Al arrancar un trabajo se manda una tarea a los planificadores que laasignaraacuten a un nodo cliente Esta tarea consiste en la descarga del ficherode configuracioacuten Java y arrancarlo configurando el equipo como un clientede Jenkins temporalmente
3 Jenkins ejecuta el trabajo en el nuevo cliente en este caso iniciar la apli-cacioacuten web iniciar las pruebas y generar un informe
4 Se elimina el cliente
A continuacioacuten se detallan los matices de cada herramienta a la hora de imple-mentar este servicio
22Desarrollado por Ivo Verberk httpwwwivoverberknl
41
623 Jenkins con Nomad
El plugin permite la ejecucioacuten del fichero Java mediante dos controladorescontenedores Docker y Java En este proyecto nos hemos decantado por el pri-mero ya que nos ahorra instalar la maacutequina virtual de java en todos los nodoscliente Por ello se ha construido un contenedor base con Java para la ejecucioacutendel fichero de configuracioacuten y Nodejs para lanzar la aplicacioacuten web
El plugin se configura con la direccioacuten IP del cluster y el contenedor queejecuta el esclavo Jenkins Por su parte el trabajo en Jenkins se define conel repositorio en GitHub donde se aloja el coacutedigo del proyecto a probar y loscomandos a ejecutar en este caso npm update y npm test
624 Jenkins con DCOS
En el caso de DCOS su sistema de paquetes incluye Jenkins por lo queal instalarlo ya se tiene la configuracioacuten de Mesos totalmente funcional Sinembargo para ejecutar la aplicacioacuten en particular y las pruebas se requiere deNodejs en los equipos esclavos por ello debemos antildeadir un plugin de Jenkinsque permite instalar este entorno antes de ejecutar el trabajo Una vez hechoesto soacutelo queda definir la tarea igual que en el caso anterior
Cabe destacar que Mesosphere tambieacuten ha desarrollado un plugin que per-mite hacer despliegues en Marathon de tal manera que permitiriacutea con cadacommit del coacutedigo compilar la imagen del contenedor Docker y desplegarlaautomaacuteticamente aunque en este proyecto no se ha hecho pruebas de esta fun-cionalidad
42
7 Escalando la infraestructura
Uno de los factores clave que se busca a la hora de implementar sistemasdistribuidos es el poder escalar la infraestructura de forma maacutes sencilla estoes detectar que las maacutequinas estaacuten alcanzando el liacutemite de su capacidad yaumentar eacutesta ya sea mejorando sus caracteriacutesticas teacutecnicas o antildeadiendo maacutesnodos al cluster
El coacutedigo y todos los ficheros de configuracioacuten de esta seccioacuten tambieacuten sepueden encontrar en el repositorio del proyecto en GitHub23
71 Disentildeo
Microsoft Azure permite organizar los servicios cloud de forma loacutegica a traveacutesde grupos de recursos y asiacute poder crear o eliminar eacutestos en conjunto parauna aplicacioacuten determinada (por ejemplo una aplicacioacuten web suele requerir demaacutequinas virtuales bases de datos almacenamiento) Ademaacutes dispone dela opcioacuten de crear plantillas en formato JSON que permite al desarrolladordefinir los recursos y su interrelacioacuten para desplegar de forma automaacutetica unainfraestructura TI en la nube
Azure tambieacuten ofrece la posibilidad de monitorizar el estado de las maacutequinasvirtuales a traveacutes de extensiones lo que permite configurar el escalado automaacute-tico al alcanzar cierto liacutemite definido por el operador Eacutesta es a priori la formaen que deberiacutea implementarse hablando en teacuterminos de eficiencia sin embargoesta aproximacioacuten es totalmente dependiente de la plataforma es decir no sepuede extrapolar a otro proveedor o sobre recursos propios sin realizar un nue-vo disentildeo En este proyecto las tareas que son ejecutadas por estos equipos notienen estado ya que todo lo relativo a la persistencia lo hemos asignado fueradel cluster esto permite escalar la plataforma a traveacutes de otra aproximaciones
Las plantillas aceptan una serie de variables a indicar por el usuario entreotras los conjuntos de escala para definir los nodos aceptan una variable quedefine el nuacutemero de maacutequinas que los componen Por otro lado Azure ofreceuna API REST y kits de desarrollo software (SDK por sus siglas en ingleacutes) quepermiten su despliegue de forma programaacutetica Aprovechando estas facilidadesen este proyecto se va a aproximar la escalabilidad con el sucesivo desplieguede la infraestructura de forma automaacutetica se monitorizan los equipos y si sedetecta una maacutequina excesivamente cargada se aumenta el nuacutemero de equiposen la plantilla y se vuelve a desplegar
23httpsgithubcomAntonioAlfrzCloud-Orchestrators
43
En este proyecto se han disentildeado las plantillas para desplegar la arquitec-tura necesaria tanto de Nomad como de DCOS En el caso de la primera eldespliegue es maacutes descriptivo ya que incluye maacutequinas virtuales grupos de se-guridad redes En el caso de DCOS Azure cuenta con un servicio especiacuteficopara clusters gobernados por DCOS denominado Azure Container Service queincluye los componentes necesarios y la instalacioacuten ya realizada
72 Implementacioacuten
En primer lugar para monitorizar el estado de los equipos se va a usar laherramienta Nagios un sistema que permite controlar el estado del hardwarey los servicios de un equipo Se trata de una herramienta muy completa de laque se va a usar su capacidad para ejecutar comandos (plugins) en los nodospara detectar picos de carga generar alertas y ejecutar programas para estoseventos
Se ha desplegado una maacutequina virtual con esta herramienta en ambos siste-mas y se ha instalado una extensioacuten de Nagios (Nagios Remote Plugin Executor)en todos los nodos que permite ejecutar comprobaciones remotamente en con-creto para esta prueba de concepto medir el nivel de saturacioacuten de la unidadcentral de procesamiento (CPU por sus siglas del ingleacutes) Cuando sucede uncambio de estado de una maacutequina esto es cuando este paraacutemetro supera el liacutemi-te definido por el operador Nagios permite actuar en consecuencia ejecutandoprogramas por ello se ha desarrollado un script que ejecuta lo siguiente
Un programa desarrollado en Python con el SDK de Azure que modificalas plantillas y despliega los recursos
Un guioacuten de Ansible para instalar todos los componentes necesarios en lasnuevas maacutequinas y arrancar de nuevo el cluster y las aplicaciones
44
8 Resultados y conclusiones
En este uacuteltimo apartado se da una visioacuten global del proyecto asiacute como a lasconclusiones maacutes importantes a las que se ha llegado y posibles temas futurosde desarrollo
81 Comparacioacuten
Ambas herramientas ofrecen las funcionalidades para gestionar los recursoseficientemente ofreciendo a los desarrolladores una plataforma donde desplegarsus aplicaciones de forma distribuida independientemente de los equipos fiacutesicosy el hardware que las soporten
DCOS es una herramienta que en un comienzo fue privativa pero cuyos res-ponsables la empresa Mesosphere decidieron publicar una versioacuten de coacutedigoEacutesta nos permite gestionar un cluster de una forma sencilla y usable ademaacutes decomplementarlo con otras herramientas como el balanceador de carga integradoo la autenticacioacuten de usuarios ademaacutes estaacute basada en Apache Mesos un pro-yecto de relativa madurez y con el soporte de la Apache Software FoundationDe forma resumida DCOS ofrece muchas posibilidades y servicios a cambiode una arquitectura e instalacioacuten maacutes compleja
Por su parte HashiCorp con menor tiempo de desarrollo ha conseguidouna herramienta muy sencilla de desplegar que ademaacutes cumple con todas lasfuncionalidades baacutesicas ejecutando un simple binario en cada nodo se puededesplegar un gestor de clusters totalmente funcional Sin embargo no cuentacon todas las posibilidades de Mesos (Nomad cuenta con menos controladoresque entornos posibles de Mesos) ni con los antildeadidos de DCOS lo que implicael uso de otras herramientas para complementar el servicio (Consul HAProxy)
De entre las dificultades encontradas al usar estas herramientas y desplegaraplicaciones sobre ellas se puede destacar la depuracioacuten en ocasiones se desco-noce si un error viene de la propia herramienta de la aplicacioacuten desplegada o delequipo fiacutesico si no se cuenta con un sistema de procesamiento de registro unose puede encontrar con muacuteltiples terminales abiertas inspeccionando numerososficheros de registro buscando posibles errores Ademaacutes no dejan de ser solucio-nes que para usar eficientemente se debe conocer parte de su funcionamientoy sintaxis a la hora de describir la tareas lo que supone un esfuerzo antildeadido yaque cada una tiene sus particularidades y liacutemites
45
82 Conclusiones
En una sociedad cada vez maacutes digital las empresas deben adaptarse a unmercado cuya demanda de contenido no deja de crecer Las nuevas arquitecturascomo microservicios asiacute como la gran cantidad de datos generada implica queuna mejor gestioacuten de los recursos y la rapidez para desplegar o escalar solucionesdando valor al cliente lo maacutes raacutepido posible es uno de los objetivos de todas lasempresas de base tecnoloacutegica
Las ventajas que ofrecen los planificadores con aplicaciones distribuidas sonnumerosas sin ir maacutes lejos empresas tan punteras como Google llevan maacutesde 10 antildeos orquestando contenedores24 Por un lado permiten aumentar elrendimiento de los equipos propios y por otro implementar un servicio comoplataforma para despliegues distribuidos sobre cualquier conjunto hardware deesta forma se provee un servicio similar al de la nube puacuteblica pero con laprincipal diferencia de que se elimina la independencia con el proveedor (vendorlock-in) esto es las aplicaciones no tienen limitaciones impuestas por eacuteste talescomo lenguaje de programacioacuten o herramientas y permite despliegues hiacutebridosentre recursos propios y la nube
83 Objetivos conseguidos
Implementacioacuten de los planificadores propuestos en la nube Se ha en-tendido y detallado el funcionamiento de estas herramientas y se hanimplementado en el servicio de infraestructura de Microsoft Azure
Despliegue de aplicaciones y servicios distribuidos Servicios que se usanactualmente en la industria del desarrollo software asiacute como una aplica-cioacuten web con una arquitectura moderna han sido desplegados de formadistribuida en los equipos cumpliendo con la funcionalidad esperada ade-maacutes de consiguiendo una alta disponibilidad
Aproximacioacuten de arquitectura escalable Se ha hecho una aproximacioacutende infraestructura escalable de forma que sea parcialmente extrapolable aotros proveedores
24httpwwwnextplatformcom20160322decade-container-control-google
46
84 Liacuteneas de investigacioacuten
Siguiendo con la materia de este proyecto se presentan posibles liacuteneas deinvestigacioacuten
Analizar el despliegue con estas herramientas de aplicaciones de Big Datay comparar la eficiencia con respecto a soluciones especializadas
Analizar el rendimiento de los algoritmos de planificacioacuten antes pruebasde estreacutes y situaciones de alta contienda
Comparar el uso de estas herramientas con las praacutecticas actuales de laindustria o implementacioacuten en un sistema de produccioacuten real
47
Referencias
[1] LA Barroso y U Houmllzle laquoThe Datacenter as a Computer An Introduc-tion to the Design of Warehouse-Scale Machinesraquo En Morgan amp ClaypoolPublishers ()
[2] Systems Research Group ndash NetOS (University of Cambridge) The evolu-tion of cluster scheduler architectures 2016 url httpswwwclcamacukresearchsrgnetoscamsasblog2016-03-09-scheduler-architectureshtml
[3] A Das I Gupta y A Motivala SWIM Scalable Weakly-consistent Infection-style Process Group Membership Protocol Inf teacutec Dept of ComputerScience Cornell University url https www cs cornell edu ~asdasresearchdsn02-swimpdf
[4] D Dubhashi y A Das Mastering Mesos PACKT Publishing mayo de2016
[5] The Apache Software Foundation Apache Mesos documentation urlhttpsmesosapacheorg
[6] David Greenberg Building Applications on Mesos OrsquoReilly Media 2016[7] Armand Grillet Comparison of Container Schedulers Inf teacutec Technische
Universitaumlt Berlin[8] HashiCorp Consul documentation url httpswwwconsulio[9] HashiCorp Nomad documentation url httpsdcosio[10] Dan C Marinescu Cloud computing theory and practice Morgan Kauf-
mann 2013[11] Mesosphere DCOS documentation url httpswwwnomadproject
io[12] Microsoft Azure documentation url httpsazuremicrosoftcom
es-esdocumentation[13] D Ongaro y J Ousterhout In Search of an Understandable Consensus
Algorithm Inf teacutec Stanford University url httpsraftgithubioraftpdf
[14] Fei Teng laquoRessource allocation and schelduling models for cloud compu-tingraquo Tesis de mtriacutea Ecole Centrale Paris 2011
[15] A Williams y col Automation and Orchestration with Docker and Contai-ners A Comprehensive Overview of the Docker and Container Ecosystem3 The New Stack 2016
48
- Resumen
- Summary
- Iacutendice de figuras
- Introduccioacuten y objetivos
-
- Contexto
- Objetivos
- Estructura del documento
-
- Cloud Computing
- Nuevas cargas de trabajo
- Gestioacuten de recursos Planificadores
-
- Sistemas distribuidos
-
- Clasificacioacuten
-
- Herramientas
-
- DCOS
-
- Apache Mesos
- Ejemplos de uso
-
- Nomad
-
- Protocolo de consenso Raft
- Protocolo gossip SWIM
- Planificacioacuten
-
- Casos de uso y despliegue
-
- Aplicacioacuten Web
-
- DCOS
- Nomad
-
- Servicio de integracioacuten continua
-
- DevOps
- Integracioacuten Continua
- Jenkins con Nomad
- Jenkins con DCOS
-
- Escalando la infraestructura
-
- Disentildeo
- Implementacioacuten
-
- Resultados y conclusiones
-
- Comparacioacuten
- Conclusiones
- Objetivos conseguidos
- Liacuteneas de investigacioacuten
-
RPC 8300 8400 Maneja la peticiones del resto de nodos y usuarios
Serf 8301 8302 Protocolo gossip
HTTP API 8500
HTTPS API Desactivada por defecto
Interfaz DNS 8600
Se debe asignar a los protocolos internos del cluster esto es RPC y Serf unainterfaz alcanzable por los nodos y por el contrarioasignar a los dos uacuteltimos ala interfaz de loopback por motivos de seguridad
Cabe destacar que Consul tambieacuten cuenta con una interfaz graacutefica que per-mite ver el estado de los equipos y los servicios registrados y que se encuentra enel mismo puerto que la API HTTP en la direccioacuten httpIP_EQUIPO8500ui
Ejecucioacuten
Tanto Nomad como Consul requieren de la ejecucioacuten de un fichero en todoslos nodos integrantes del cluster Como prueba de concepto se ha decidido usardos servidores para ambos aunque cabe matizar que es un nuacutemero ineficienteya que la caiacuteda de uno de ellos supondriacutea la peacuterdida del cuoacuterum y por tantodel consenso del cluster
En primer lugar se arrancan los servidores que son los encargados de ejecu-tar el protocolo de consenso y gestionar el cluster y a continuacioacuten los clientesque no tienen praacutecticamente estado y dependen de los servidores
En el caso de Consul se debe indicar el directorio donde se guardan losficheros que describen los servicios asiacute como el archivo que especifica el resto delas opciones
1 Se inicia el primer servidor en uno de los equipos
$ consu l agent minuscon f i gminusd i r e t c consu l d s e r v i c e s minuscon f i gminus f i l e consu l_server j son
2 Los siguientes equipos deben unirse al anterior por lo que antildeadimos elargumento join con la direccioacuten del primer servidor Para el caso de otrosservidores
$ consu l agent minuscon f i gminusd i r e t c consu l d s e r v i c e s minuscon f i gminus f i l e consu l_server j son minus j o i n ltIP_servidor1gt
37
Una vez los servidores han alcanzado el consenso y elegido un liacuteder en losclientes
$ consu l agent minuscon f i gminusd i r e t c consu l d s e r v i c e s minuscon f i gminus f i l e c on su l_c l i en t j son minus j o i n ltIP_cualquierServ idorgt
El proceso para iniciar Nomad es igual y los comandos similares sin embargoya no es necesario indicar una direccioacuten IP fija en los equipos sino el nombre dedominio del servicio de Nomad registrado por Consul En el primer servidor
$ nomad agent minusc on f i g nomad_server j son
Y el resto de equipos (con su fichero de configuracioacuten correspondiente)$ nomad agent minusc on f i g nomad_server j son minus j o i n nomad s e r v i c e consu l
Por uacuteltimo para desplegar la aplicacioacuten web se han escrito tres ficherosque detallan las tareas de la interfaz web API y los balanceadores de cargaMediante la CLI
$ nomad run minusaddress=http lt ip_c lus te r gt4646 lt f i l e hclgt
O mediante la API HTTP de Nomad$ cu r l minusX POST minusd ltf i l e hclgthttp lt ip_c lus te r gt4646 jobltjob_namegt
Ansible
Como se puede comprobar con el aumento del nuacutemero de equipos pasa aser inviable manejar todos los nodos a traveacutes de terminal Ademaacutes como seha comentado con anterioridad Nomad requiere que en los nodos clientes es-teacuten instalados las herramientas que soporten las tareas por ejemplo el motorde Docker Por ello para facilitar tanto el arranque como la instalacioacuten de lasdependencias vamos a usar Ansible una herramienta de coacutedigo abierto desarro-llada en Python que permite gestionar configuraciones aprovisionar recursosdespliegue de aplicaciones de forma automaacutetica
A grandes rasgos esta herramienta funciona mediante ficheros en formatoYAML denominados play-books que describen un conjunto de pasos a ejecutaren una lista de equipos remotos Estos pasos son ejecutados por moacutedulos inde-pendientes a traveacutes de SSH es decir en cualquier ordenador con conexioacuten a los
38
hosts dado su contrasentildea o clave puacuteblica puede arrancar el script y realizariacutealos pasos de forma remota gestionando el cluster desde un solo equipo
Se han desarrollado guiones para lo siguiente
Descarga de los binarios de Nomad y Consul en todos los nodos copiade los ficheros de configuracioacuten baacutesicos y modificarlos de acuerdo a cadanodo (nombre del equipo direccioacuten IP)
Instalacioacuten de las dependencias
Arranque de Nomad y Consul
Ansible extiende su funcionalidad a traveacutes de moacutedulos independientes que per-miten por ejemplo instalar paquetes mediante herramientas de gestioacuten de pa-quetes (APT yum) aprovisionar automaacuteticamente maacutequinas virtuales de Ama-zon EC2
Algunas opciones de los ficheros de configuracioacuten de Nomad y Consul sondependientes del nodo particular por ejemplo la interfaz de red Para estetrabajo se ha realizado un moacutedulo para modificar los ficheros de configuracioacutende forma automaacutetica En el repositorio del proyecto se encuentra una carpetadonde se encuentran todos los ficheros necesarios para desplegar un clustertotalmente funcional solo requiere de una liacutenea de terminal con Ansible
$ ans ib l eminusplaybook minus i hos t s minusk ltssh_passgt minusu ltnode_usergt s i t e yml
39
62 Servicio de integracioacuten continua
Se ha implementado un sistema de integracioacuten continua que permite ejecu-tar tareas de compilacioacuten y pruebas de forma distribuida aumentando asiacute elrendimiento de los equipos En primer lugar se detallaraacute los motivos por los quepuede resultar beneficioso para las empresas una implementacioacuten de este tipo alo que seguiraacute los detalles del despliegue
621 DevOps
Metodologiacutea que defiende la comunicacioacuten y colaboracioacuten entre desarrolla-dores de software y los profesionales de operaciones a lo largo de todo el ciclo devida de una aplicacioacuten Estaacute muy relacionado con el desarrollo aacutegil de softwareesto es un enfoque para los proyectos que defiende el desarrollo iterativo e in-cremental donde los requisitos y soluciones evolucionan con el tiempo seguacuten lanecesidad del proyecto DevOps extiende esta filosofiacutea a todas los componentesde un servicio incluyendo sistemas y operaciones
Se trata de un concepto que cada organizacioacuten o empresa adapta a suspropias necesidades y procesos de negocio en este proyecto nos vamos a centraren la integracioacuten continua una praacutectica fundamental tanto del desarrollo aacutegilcomo de esta filosofiacutea
622 Integracioacuten Continua
Se define como una praacutectica de desarrollo software donde los miembros delequipo ponen en comuacuten su trabajo frecuentemente al menos una vez al diacutea21Cada integracioacuten se verifica con una compilacioacuten automaacutetica que incluye laejecucioacuten de pruebas para detectar errores de integracioacuten tan pronto como seaposible
Desde el punto de vista operativo esto supone automatizar la configuracioacutende equipos o el despliegue de maacutequinas virtuales donde compilar el proyecto yejecutar las pruebas y posteriormente eliminarlas Este flujo de trabajo se vebeneficiado en entornos distribuidos ya que el objetivo del desarrollador es com-probar el resultado de las pruebas raacutepidamente sin preocuparse del despliegueo los propios equipos
Para esta prueba de concepto vamos a usar Jenkins un servidor de integra-cioacuten continua escrito en Java que nos permite definir trabajos que contendraacutenla descripcioacuten tanto del entorno como su ejecucioacuten
Este sigue una estructura maestro-esclavo muy similar al de los gestores declusters usados en este proyecto el maestro contiene toda la loacutegica del servicio
21httpmartinfowlercomarticlescontinuousIntegrationhtml
40
trabajos autenticacioacuten y los esclavos son los encargados de la ejecucioacuten ensiacute Jenkins tiene varias viacuteas para aprovisionar los uacuteltimos
Mediante SSH
Interfaz graacutefica
Desarrollar un script propio
Ejecucioacuten de un fichero java
La ventaja de usar planificadores es que el despliegue de esclavos es dinaacutemicoes decir no tener una maacutequina especiacuteficamente configurada para ello DCOS yNomad se encargaraacuten de configurar estos despliegues en sus maacutequinas y poste-riormente eliminarlos Para ello se ha usado la uacuteltima opcioacuten definiendo tareasque descarguen el fichero java Con todo ello se consigue un entorno de inte-gracioacuten continua eficiente que ademaacutes permite la ejecucioacuten de otros servicios deforma independiente
Jenkins permite la creacioacuten de plugins que extienden sus funcionalidadesTanto Nomad22 como Apache Mesos cuentan con uno que permite su integra-cioacuten
Para esta prueba se va a usar el mismo proyecto que para el caso de usode orquestacioacuten de contenedores la aplicacioacuten web al que se le ha antildeadido untest para comprobar que se conecta correctamente a la base de datos medianteMocha un framework de Nodejs Por otro lado se antildeade el plugin de git ya queel coacutedigo se obtiene de GitHub el repositorio remoto de control de versiones delproyecto
El proceso general de ejecucioacuten seriacutea como sigue
1 Se ejecuta el maestro de Jenkins como tarea Docker partiendo de la imagenoficial
2 Al arrancar un trabajo se manda una tarea a los planificadores que laasignaraacuten a un nodo cliente Esta tarea consiste en la descarga del ficherode configuracioacuten Java y arrancarlo configurando el equipo como un clientede Jenkins temporalmente
3 Jenkins ejecuta el trabajo en el nuevo cliente en este caso iniciar la apli-cacioacuten web iniciar las pruebas y generar un informe
4 Se elimina el cliente
A continuacioacuten se detallan los matices de cada herramienta a la hora de imple-mentar este servicio
22Desarrollado por Ivo Verberk httpwwwivoverberknl
41
623 Jenkins con Nomad
El plugin permite la ejecucioacuten del fichero Java mediante dos controladorescontenedores Docker y Java En este proyecto nos hemos decantado por el pri-mero ya que nos ahorra instalar la maacutequina virtual de java en todos los nodoscliente Por ello se ha construido un contenedor base con Java para la ejecucioacutendel fichero de configuracioacuten y Nodejs para lanzar la aplicacioacuten web
El plugin se configura con la direccioacuten IP del cluster y el contenedor queejecuta el esclavo Jenkins Por su parte el trabajo en Jenkins se define conel repositorio en GitHub donde se aloja el coacutedigo del proyecto a probar y loscomandos a ejecutar en este caso npm update y npm test
624 Jenkins con DCOS
En el caso de DCOS su sistema de paquetes incluye Jenkins por lo queal instalarlo ya se tiene la configuracioacuten de Mesos totalmente funcional Sinembargo para ejecutar la aplicacioacuten en particular y las pruebas se requiere deNodejs en los equipos esclavos por ello debemos antildeadir un plugin de Jenkinsque permite instalar este entorno antes de ejecutar el trabajo Una vez hechoesto soacutelo queda definir la tarea igual que en el caso anterior
Cabe destacar que Mesosphere tambieacuten ha desarrollado un plugin que per-mite hacer despliegues en Marathon de tal manera que permitiriacutea con cadacommit del coacutedigo compilar la imagen del contenedor Docker y desplegarlaautomaacuteticamente aunque en este proyecto no se ha hecho pruebas de esta fun-cionalidad
42
7 Escalando la infraestructura
Uno de los factores clave que se busca a la hora de implementar sistemasdistribuidos es el poder escalar la infraestructura de forma maacutes sencilla estoes detectar que las maacutequinas estaacuten alcanzando el liacutemite de su capacidad yaumentar eacutesta ya sea mejorando sus caracteriacutesticas teacutecnicas o antildeadiendo maacutesnodos al cluster
El coacutedigo y todos los ficheros de configuracioacuten de esta seccioacuten tambieacuten sepueden encontrar en el repositorio del proyecto en GitHub23
71 Disentildeo
Microsoft Azure permite organizar los servicios cloud de forma loacutegica a traveacutesde grupos de recursos y asiacute poder crear o eliminar eacutestos en conjunto parauna aplicacioacuten determinada (por ejemplo una aplicacioacuten web suele requerir demaacutequinas virtuales bases de datos almacenamiento) Ademaacutes dispone dela opcioacuten de crear plantillas en formato JSON que permite al desarrolladordefinir los recursos y su interrelacioacuten para desplegar de forma automaacutetica unainfraestructura TI en la nube
Azure tambieacuten ofrece la posibilidad de monitorizar el estado de las maacutequinasvirtuales a traveacutes de extensiones lo que permite configurar el escalado automaacute-tico al alcanzar cierto liacutemite definido por el operador Eacutesta es a priori la formaen que deberiacutea implementarse hablando en teacuterminos de eficiencia sin embargoesta aproximacioacuten es totalmente dependiente de la plataforma es decir no sepuede extrapolar a otro proveedor o sobre recursos propios sin realizar un nue-vo disentildeo En este proyecto las tareas que son ejecutadas por estos equipos notienen estado ya que todo lo relativo a la persistencia lo hemos asignado fueradel cluster esto permite escalar la plataforma a traveacutes de otra aproximaciones
Las plantillas aceptan una serie de variables a indicar por el usuario entreotras los conjuntos de escala para definir los nodos aceptan una variable quedefine el nuacutemero de maacutequinas que los componen Por otro lado Azure ofreceuna API REST y kits de desarrollo software (SDK por sus siglas en ingleacutes) quepermiten su despliegue de forma programaacutetica Aprovechando estas facilidadesen este proyecto se va a aproximar la escalabilidad con el sucesivo desplieguede la infraestructura de forma automaacutetica se monitorizan los equipos y si sedetecta una maacutequina excesivamente cargada se aumenta el nuacutemero de equiposen la plantilla y se vuelve a desplegar
23httpsgithubcomAntonioAlfrzCloud-Orchestrators
43
En este proyecto se han disentildeado las plantillas para desplegar la arquitec-tura necesaria tanto de Nomad como de DCOS En el caso de la primera eldespliegue es maacutes descriptivo ya que incluye maacutequinas virtuales grupos de se-guridad redes En el caso de DCOS Azure cuenta con un servicio especiacuteficopara clusters gobernados por DCOS denominado Azure Container Service queincluye los componentes necesarios y la instalacioacuten ya realizada
72 Implementacioacuten
En primer lugar para monitorizar el estado de los equipos se va a usar laherramienta Nagios un sistema que permite controlar el estado del hardwarey los servicios de un equipo Se trata de una herramienta muy completa de laque se va a usar su capacidad para ejecutar comandos (plugins) en los nodospara detectar picos de carga generar alertas y ejecutar programas para estoseventos
Se ha desplegado una maacutequina virtual con esta herramienta en ambos siste-mas y se ha instalado una extensioacuten de Nagios (Nagios Remote Plugin Executor)en todos los nodos que permite ejecutar comprobaciones remotamente en con-creto para esta prueba de concepto medir el nivel de saturacioacuten de la unidadcentral de procesamiento (CPU por sus siglas del ingleacutes) Cuando sucede uncambio de estado de una maacutequina esto es cuando este paraacutemetro supera el liacutemi-te definido por el operador Nagios permite actuar en consecuencia ejecutandoprogramas por ello se ha desarrollado un script que ejecuta lo siguiente
Un programa desarrollado en Python con el SDK de Azure que modificalas plantillas y despliega los recursos
Un guioacuten de Ansible para instalar todos los componentes necesarios en lasnuevas maacutequinas y arrancar de nuevo el cluster y las aplicaciones
44
8 Resultados y conclusiones
En este uacuteltimo apartado se da una visioacuten global del proyecto asiacute como a lasconclusiones maacutes importantes a las que se ha llegado y posibles temas futurosde desarrollo
81 Comparacioacuten
Ambas herramientas ofrecen las funcionalidades para gestionar los recursoseficientemente ofreciendo a los desarrolladores una plataforma donde desplegarsus aplicaciones de forma distribuida independientemente de los equipos fiacutesicosy el hardware que las soporten
DCOS es una herramienta que en un comienzo fue privativa pero cuyos res-ponsables la empresa Mesosphere decidieron publicar una versioacuten de coacutedigoEacutesta nos permite gestionar un cluster de una forma sencilla y usable ademaacutes decomplementarlo con otras herramientas como el balanceador de carga integradoo la autenticacioacuten de usuarios ademaacutes estaacute basada en Apache Mesos un pro-yecto de relativa madurez y con el soporte de la Apache Software FoundationDe forma resumida DCOS ofrece muchas posibilidades y servicios a cambiode una arquitectura e instalacioacuten maacutes compleja
Por su parte HashiCorp con menor tiempo de desarrollo ha conseguidouna herramienta muy sencilla de desplegar que ademaacutes cumple con todas lasfuncionalidades baacutesicas ejecutando un simple binario en cada nodo se puededesplegar un gestor de clusters totalmente funcional Sin embargo no cuentacon todas las posibilidades de Mesos (Nomad cuenta con menos controladoresque entornos posibles de Mesos) ni con los antildeadidos de DCOS lo que implicael uso de otras herramientas para complementar el servicio (Consul HAProxy)
De entre las dificultades encontradas al usar estas herramientas y desplegaraplicaciones sobre ellas se puede destacar la depuracioacuten en ocasiones se desco-noce si un error viene de la propia herramienta de la aplicacioacuten desplegada o delequipo fiacutesico si no se cuenta con un sistema de procesamiento de registro unose puede encontrar con muacuteltiples terminales abiertas inspeccionando numerososficheros de registro buscando posibles errores Ademaacutes no dejan de ser solucio-nes que para usar eficientemente se debe conocer parte de su funcionamientoy sintaxis a la hora de describir la tareas lo que supone un esfuerzo antildeadido yaque cada una tiene sus particularidades y liacutemites
45
82 Conclusiones
En una sociedad cada vez maacutes digital las empresas deben adaptarse a unmercado cuya demanda de contenido no deja de crecer Las nuevas arquitecturascomo microservicios asiacute como la gran cantidad de datos generada implica queuna mejor gestioacuten de los recursos y la rapidez para desplegar o escalar solucionesdando valor al cliente lo maacutes raacutepido posible es uno de los objetivos de todas lasempresas de base tecnoloacutegica
Las ventajas que ofrecen los planificadores con aplicaciones distribuidas sonnumerosas sin ir maacutes lejos empresas tan punteras como Google llevan maacutesde 10 antildeos orquestando contenedores24 Por un lado permiten aumentar elrendimiento de los equipos propios y por otro implementar un servicio comoplataforma para despliegues distribuidos sobre cualquier conjunto hardware deesta forma se provee un servicio similar al de la nube puacuteblica pero con laprincipal diferencia de que se elimina la independencia con el proveedor (vendorlock-in) esto es las aplicaciones no tienen limitaciones impuestas por eacuteste talescomo lenguaje de programacioacuten o herramientas y permite despliegues hiacutebridosentre recursos propios y la nube
83 Objetivos conseguidos
Implementacioacuten de los planificadores propuestos en la nube Se ha en-tendido y detallado el funcionamiento de estas herramientas y se hanimplementado en el servicio de infraestructura de Microsoft Azure
Despliegue de aplicaciones y servicios distribuidos Servicios que se usanactualmente en la industria del desarrollo software asiacute como una aplica-cioacuten web con una arquitectura moderna han sido desplegados de formadistribuida en los equipos cumpliendo con la funcionalidad esperada ade-maacutes de consiguiendo una alta disponibilidad
Aproximacioacuten de arquitectura escalable Se ha hecho una aproximacioacutende infraestructura escalable de forma que sea parcialmente extrapolable aotros proveedores
24httpwwwnextplatformcom20160322decade-container-control-google
46
84 Liacuteneas de investigacioacuten
Siguiendo con la materia de este proyecto se presentan posibles liacuteneas deinvestigacioacuten
Analizar el despliegue con estas herramientas de aplicaciones de Big Datay comparar la eficiencia con respecto a soluciones especializadas
Analizar el rendimiento de los algoritmos de planificacioacuten antes pruebasde estreacutes y situaciones de alta contienda
Comparar el uso de estas herramientas con las praacutecticas actuales de laindustria o implementacioacuten en un sistema de produccioacuten real
47
Referencias
[1] LA Barroso y U Houmllzle laquoThe Datacenter as a Computer An Introduc-tion to the Design of Warehouse-Scale Machinesraquo En Morgan amp ClaypoolPublishers ()
[2] Systems Research Group ndash NetOS (University of Cambridge) The evolu-tion of cluster scheduler architectures 2016 url httpswwwclcamacukresearchsrgnetoscamsasblog2016-03-09-scheduler-architectureshtml
[3] A Das I Gupta y A Motivala SWIM Scalable Weakly-consistent Infection-style Process Group Membership Protocol Inf teacutec Dept of ComputerScience Cornell University url https www cs cornell edu ~asdasresearchdsn02-swimpdf
[4] D Dubhashi y A Das Mastering Mesos PACKT Publishing mayo de2016
[5] The Apache Software Foundation Apache Mesos documentation urlhttpsmesosapacheorg
[6] David Greenberg Building Applications on Mesos OrsquoReilly Media 2016[7] Armand Grillet Comparison of Container Schedulers Inf teacutec Technische
Universitaumlt Berlin[8] HashiCorp Consul documentation url httpswwwconsulio[9] HashiCorp Nomad documentation url httpsdcosio[10] Dan C Marinescu Cloud computing theory and practice Morgan Kauf-
mann 2013[11] Mesosphere DCOS documentation url httpswwwnomadproject
io[12] Microsoft Azure documentation url httpsazuremicrosoftcom
es-esdocumentation[13] D Ongaro y J Ousterhout In Search of an Understandable Consensus
Algorithm Inf teacutec Stanford University url httpsraftgithubioraftpdf
[14] Fei Teng laquoRessource allocation and schelduling models for cloud compu-tingraquo Tesis de mtriacutea Ecole Centrale Paris 2011
[15] A Williams y col Automation and Orchestration with Docker and Contai-ners A Comprehensive Overview of the Docker and Container Ecosystem3 The New Stack 2016
48
- Resumen
- Summary
- Iacutendice de figuras
- Introduccioacuten y objetivos
-
- Contexto
- Objetivos
- Estructura del documento
-
- Cloud Computing
- Nuevas cargas de trabajo
- Gestioacuten de recursos Planificadores
-
- Sistemas distribuidos
-
- Clasificacioacuten
-
- Herramientas
-
- DCOS
-
- Apache Mesos
- Ejemplos de uso
-
- Nomad
-
- Protocolo de consenso Raft
- Protocolo gossip SWIM
- Planificacioacuten
-
- Casos de uso y despliegue
-
- Aplicacioacuten Web
-
- DCOS
- Nomad
-
- Servicio de integracioacuten continua
-
- DevOps
- Integracioacuten Continua
- Jenkins con Nomad
- Jenkins con DCOS
-
- Escalando la infraestructura
-
- Disentildeo
- Implementacioacuten
-
- Resultados y conclusiones
-
- Comparacioacuten
- Conclusiones
- Objetivos conseguidos
- Liacuteneas de investigacioacuten
-
Una vez los servidores han alcanzado el consenso y elegido un liacuteder en losclientes
$ consu l agent minuscon f i gminusd i r e t c consu l d s e r v i c e s minuscon f i gminus f i l e c on su l_c l i en t j son minus j o i n ltIP_cualquierServ idorgt
El proceso para iniciar Nomad es igual y los comandos similares sin embargoya no es necesario indicar una direccioacuten IP fija en los equipos sino el nombre dedominio del servicio de Nomad registrado por Consul En el primer servidor
$ nomad agent minusc on f i g nomad_server j son
Y el resto de equipos (con su fichero de configuracioacuten correspondiente)$ nomad agent minusc on f i g nomad_server j son minus j o i n nomad s e r v i c e consu l
Por uacuteltimo para desplegar la aplicacioacuten web se han escrito tres ficherosque detallan las tareas de la interfaz web API y los balanceadores de cargaMediante la CLI
$ nomad run minusaddress=http lt ip_c lus te r gt4646 lt f i l e hclgt
O mediante la API HTTP de Nomad$ cu r l minusX POST minusd ltf i l e hclgthttp lt ip_c lus te r gt4646 jobltjob_namegt
Ansible
Como se puede comprobar con el aumento del nuacutemero de equipos pasa aser inviable manejar todos los nodos a traveacutes de terminal Ademaacutes como seha comentado con anterioridad Nomad requiere que en los nodos clientes es-teacuten instalados las herramientas que soporten las tareas por ejemplo el motorde Docker Por ello para facilitar tanto el arranque como la instalacioacuten de lasdependencias vamos a usar Ansible una herramienta de coacutedigo abierto desarro-llada en Python que permite gestionar configuraciones aprovisionar recursosdespliegue de aplicaciones de forma automaacutetica
A grandes rasgos esta herramienta funciona mediante ficheros en formatoYAML denominados play-books que describen un conjunto de pasos a ejecutaren una lista de equipos remotos Estos pasos son ejecutados por moacutedulos inde-pendientes a traveacutes de SSH es decir en cualquier ordenador con conexioacuten a los
38
hosts dado su contrasentildea o clave puacuteblica puede arrancar el script y realizariacutealos pasos de forma remota gestionando el cluster desde un solo equipo
Se han desarrollado guiones para lo siguiente
Descarga de los binarios de Nomad y Consul en todos los nodos copiade los ficheros de configuracioacuten baacutesicos y modificarlos de acuerdo a cadanodo (nombre del equipo direccioacuten IP)
Instalacioacuten de las dependencias
Arranque de Nomad y Consul
Ansible extiende su funcionalidad a traveacutes de moacutedulos independientes que per-miten por ejemplo instalar paquetes mediante herramientas de gestioacuten de pa-quetes (APT yum) aprovisionar automaacuteticamente maacutequinas virtuales de Ama-zon EC2
Algunas opciones de los ficheros de configuracioacuten de Nomad y Consul sondependientes del nodo particular por ejemplo la interfaz de red Para estetrabajo se ha realizado un moacutedulo para modificar los ficheros de configuracioacutende forma automaacutetica En el repositorio del proyecto se encuentra una carpetadonde se encuentran todos los ficheros necesarios para desplegar un clustertotalmente funcional solo requiere de una liacutenea de terminal con Ansible
$ ans ib l eminusplaybook minus i hos t s minusk ltssh_passgt minusu ltnode_usergt s i t e yml
39
62 Servicio de integracioacuten continua
Se ha implementado un sistema de integracioacuten continua que permite ejecu-tar tareas de compilacioacuten y pruebas de forma distribuida aumentando asiacute elrendimiento de los equipos En primer lugar se detallaraacute los motivos por los quepuede resultar beneficioso para las empresas una implementacioacuten de este tipo alo que seguiraacute los detalles del despliegue
621 DevOps
Metodologiacutea que defiende la comunicacioacuten y colaboracioacuten entre desarrolla-dores de software y los profesionales de operaciones a lo largo de todo el ciclo devida de una aplicacioacuten Estaacute muy relacionado con el desarrollo aacutegil de softwareesto es un enfoque para los proyectos que defiende el desarrollo iterativo e in-cremental donde los requisitos y soluciones evolucionan con el tiempo seguacuten lanecesidad del proyecto DevOps extiende esta filosofiacutea a todas los componentesde un servicio incluyendo sistemas y operaciones
Se trata de un concepto que cada organizacioacuten o empresa adapta a suspropias necesidades y procesos de negocio en este proyecto nos vamos a centraren la integracioacuten continua una praacutectica fundamental tanto del desarrollo aacutegilcomo de esta filosofiacutea
622 Integracioacuten Continua
Se define como una praacutectica de desarrollo software donde los miembros delequipo ponen en comuacuten su trabajo frecuentemente al menos una vez al diacutea21Cada integracioacuten se verifica con una compilacioacuten automaacutetica que incluye laejecucioacuten de pruebas para detectar errores de integracioacuten tan pronto como seaposible
Desde el punto de vista operativo esto supone automatizar la configuracioacutende equipos o el despliegue de maacutequinas virtuales donde compilar el proyecto yejecutar las pruebas y posteriormente eliminarlas Este flujo de trabajo se vebeneficiado en entornos distribuidos ya que el objetivo del desarrollador es com-probar el resultado de las pruebas raacutepidamente sin preocuparse del despliegueo los propios equipos
Para esta prueba de concepto vamos a usar Jenkins un servidor de integra-cioacuten continua escrito en Java que nos permite definir trabajos que contendraacutenla descripcioacuten tanto del entorno como su ejecucioacuten
Este sigue una estructura maestro-esclavo muy similar al de los gestores declusters usados en este proyecto el maestro contiene toda la loacutegica del servicio
21httpmartinfowlercomarticlescontinuousIntegrationhtml
40
trabajos autenticacioacuten y los esclavos son los encargados de la ejecucioacuten ensiacute Jenkins tiene varias viacuteas para aprovisionar los uacuteltimos
Mediante SSH
Interfaz graacutefica
Desarrollar un script propio
Ejecucioacuten de un fichero java
La ventaja de usar planificadores es que el despliegue de esclavos es dinaacutemicoes decir no tener una maacutequina especiacuteficamente configurada para ello DCOS yNomad se encargaraacuten de configurar estos despliegues en sus maacutequinas y poste-riormente eliminarlos Para ello se ha usado la uacuteltima opcioacuten definiendo tareasque descarguen el fichero java Con todo ello se consigue un entorno de inte-gracioacuten continua eficiente que ademaacutes permite la ejecucioacuten de otros servicios deforma independiente
Jenkins permite la creacioacuten de plugins que extienden sus funcionalidadesTanto Nomad22 como Apache Mesos cuentan con uno que permite su integra-cioacuten
Para esta prueba se va a usar el mismo proyecto que para el caso de usode orquestacioacuten de contenedores la aplicacioacuten web al que se le ha antildeadido untest para comprobar que se conecta correctamente a la base de datos medianteMocha un framework de Nodejs Por otro lado se antildeade el plugin de git ya queel coacutedigo se obtiene de GitHub el repositorio remoto de control de versiones delproyecto
El proceso general de ejecucioacuten seriacutea como sigue
1 Se ejecuta el maestro de Jenkins como tarea Docker partiendo de la imagenoficial
2 Al arrancar un trabajo se manda una tarea a los planificadores que laasignaraacuten a un nodo cliente Esta tarea consiste en la descarga del ficherode configuracioacuten Java y arrancarlo configurando el equipo como un clientede Jenkins temporalmente
3 Jenkins ejecuta el trabajo en el nuevo cliente en este caso iniciar la apli-cacioacuten web iniciar las pruebas y generar un informe
4 Se elimina el cliente
A continuacioacuten se detallan los matices de cada herramienta a la hora de imple-mentar este servicio
22Desarrollado por Ivo Verberk httpwwwivoverberknl
41
623 Jenkins con Nomad
El plugin permite la ejecucioacuten del fichero Java mediante dos controladorescontenedores Docker y Java En este proyecto nos hemos decantado por el pri-mero ya que nos ahorra instalar la maacutequina virtual de java en todos los nodoscliente Por ello se ha construido un contenedor base con Java para la ejecucioacutendel fichero de configuracioacuten y Nodejs para lanzar la aplicacioacuten web
El plugin se configura con la direccioacuten IP del cluster y el contenedor queejecuta el esclavo Jenkins Por su parte el trabajo en Jenkins se define conel repositorio en GitHub donde se aloja el coacutedigo del proyecto a probar y loscomandos a ejecutar en este caso npm update y npm test
624 Jenkins con DCOS
En el caso de DCOS su sistema de paquetes incluye Jenkins por lo queal instalarlo ya se tiene la configuracioacuten de Mesos totalmente funcional Sinembargo para ejecutar la aplicacioacuten en particular y las pruebas se requiere deNodejs en los equipos esclavos por ello debemos antildeadir un plugin de Jenkinsque permite instalar este entorno antes de ejecutar el trabajo Una vez hechoesto soacutelo queda definir la tarea igual que en el caso anterior
Cabe destacar que Mesosphere tambieacuten ha desarrollado un plugin que per-mite hacer despliegues en Marathon de tal manera que permitiriacutea con cadacommit del coacutedigo compilar la imagen del contenedor Docker y desplegarlaautomaacuteticamente aunque en este proyecto no se ha hecho pruebas de esta fun-cionalidad
42
7 Escalando la infraestructura
Uno de los factores clave que se busca a la hora de implementar sistemasdistribuidos es el poder escalar la infraestructura de forma maacutes sencilla estoes detectar que las maacutequinas estaacuten alcanzando el liacutemite de su capacidad yaumentar eacutesta ya sea mejorando sus caracteriacutesticas teacutecnicas o antildeadiendo maacutesnodos al cluster
El coacutedigo y todos los ficheros de configuracioacuten de esta seccioacuten tambieacuten sepueden encontrar en el repositorio del proyecto en GitHub23
71 Disentildeo
Microsoft Azure permite organizar los servicios cloud de forma loacutegica a traveacutesde grupos de recursos y asiacute poder crear o eliminar eacutestos en conjunto parauna aplicacioacuten determinada (por ejemplo una aplicacioacuten web suele requerir demaacutequinas virtuales bases de datos almacenamiento) Ademaacutes dispone dela opcioacuten de crear plantillas en formato JSON que permite al desarrolladordefinir los recursos y su interrelacioacuten para desplegar de forma automaacutetica unainfraestructura TI en la nube
Azure tambieacuten ofrece la posibilidad de monitorizar el estado de las maacutequinasvirtuales a traveacutes de extensiones lo que permite configurar el escalado automaacute-tico al alcanzar cierto liacutemite definido por el operador Eacutesta es a priori la formaen que deberiacutea implementarse hablando en teacuterminos de eficiencia sin embargoesta aproximacioacuten es totalmente dependiente de la plataforma es decir no sepuede extrapolar a otro proveedor o sobre recursos propios sin realizar un nue-vo disentildeo En este proyecto las tareas que son ejecutadas por estos equipos notienen estado ya que todo lo relativo a la persistencia lo hemos asignado fueradel cluster esto permite escalar la plataforma a traveacutes de otra aproximaciones
Las plantillas aceptan una serie de variables a indicar por el usuario entreotras los conjuntos de escala para definir los nodos aceptan una variable quedefine el nuacutemero de maacutequinas que los componen Por otro lado Azure ofreceuna API REST y kits de desarrollo software (SDK por sus siglas en ingleacutes) quepermiten su despliegue de forma programaacutetica Aprovechando estas facilidadesen este proyecto se va a aproximar la escalabilidad con el sucesivo desplieguede la infraestructura de forma automaacutetica se monitorizan los equipos y si sedetecta una maacutequina excesivamente cargada se aumenta el nuacutemero de equiposen la plantilla y se vuelve a desplegar
23httpsgithubcomAntonioAlfrzCloud-Orchestrators
43
En este proyecto se han disentildeado las plantillas para desplegar la arquitec-tura necesaria tanto de Nomad como de DCOS En el caso de la primera eldespliegue es maacutes descriptivo ya que incluye maacutequinas virtuales grupos de se-guridad redes En el caso de DCOS Azure cuenta con un servicio especiacuteficopara clusters gobernados por DCOS denominado Azure Container Service queincluye los componentes necesarios y la instalacioacuten ya realizada
72 Implementacioacuten
En primer lugar para monitorizar el estado de los equipos se va a usar laherramienta Nagios un sistema que permite controlar el estado del hardwarey los servicios de un equipo Se trata de una herramienta muy completa de laque se va a usar su capacidad para ejecutar comandos (plugins) en los nodospara detectar picos de carga generar alertas y ejecutar programas para estoseventos
Se ha desplegado una maacutequina virtual con esta herramienta en ambos siste-mas y se ha instalado una extensioacuten de Nagios (Nagios Remote Plugin Executor)en todos los nodos que permite ejecutar comprobaciones remotamente en con-creto para esta prueba de concepto medir el nivel de saturacioacuten de la unidadcentral de procesamiento (CPU por sus siglas del ingleacutes) Cuando sucede uncambio de estado de una maacutequina esto es cuando este paraacutemetro supera el liacutemi-te definido por el operador Nagios permite actuar en consecuencia ejecutandoprogramas por ello se ha desarrollado un script que ejecuta lo siguiente
Un programa desarrollado en Python con el SDK de Azure que modificalas plantillas y despliega los recursos
Un guioacuten de Ansible para instalar todos los componentes necesarios en lasnuevas maacutequinas y arrancar de nuevo el cluster y las aplicaciones
44
8 Resultados y conclusiones
En este uacuteltimo apartado se da una visioacuten global del proyecto asiacute como a lasconclusiones maacutes importantes a las que se ha llegado y posibles temas futurosde desarrollo
81 Comparacioacuten
Ambas herramientas ofrecen las funcionalidades para gestionar los recursoseficientemente ofreciendo a los desarrolladores una plataforma donde desplegarsus aplicaciones de forma distribuida independientemente de los equipos fiacutesicosy el hardware que las soporten
DCOS es una herramienta que en un comienzo fue privativa pero cuyos res-ponsables la empresa Mesosphere decidieron publicar una versioacuten de coacutedigoEacutesta nos permite gestionar un cluster de una forma sencilla y usable ademaacutes decomplementarlo con otras herramientas como el balanceador de carga integradoo la autenticacioacuten de usuarios ademaacutes estaacute basada en Apache Mesos un pro-yecto de relativa madurez y con el soporte de la Apache Software FoundationDe forma resumida DCOS ofrece muchas posibilidades y servicios a cambiode una arquitectura e instalacioacuten maacutes compleja
Por su parte HashiCorp con menor tiempo de desarrollo ha conseguidouna herramienta muy sencilla de desplegar que ademaacutes cumple con todas lasfuncionalidades baacutesicas ejecutando un simple binario en cada nodo se puededesplegar un gestor de clusters totalmente funcional Sin embargo no cuentacon todas las posibilidades de Mesos (Nomad cuenta con menos controladoresque entornos posibles de Mesos) ni con los antildeadidos de DCOS lo que implicael uso de otras herramientas para complementar el servicio (Consul HAProxy)
De entre las dificultades encontradas al usar estas herramientas y desplegaraplicaciones sobre ellas se puede destacar la depuracioacuten en ocasiones se desco-noce si un error viene de la propia herramienta de la aplicacioacuten desplegada o delequipo fiacutesico si no se cuenta con un sistema de procesamiento de registro unose puede encontrar con muacuteltiples terminales abiertas inspeccionando numerososficheros de registro buscando posibles errores Ademaacutes no dejan de ser solucio-nes que para usar eficientemente se debe conocer parte de su funcionamientoy sintaxis a la hora de describir la tareas lo que supone un esfuerzo antildeadido yaque cada una tiene sus particularidades y liacutemites
45
82 Conclusiones
En una sociedad cada vez maacutes digital las empresas deben adaptarse a unmercado cuya demanda de contenido no deja de crecer Las nuevas arquitecturascomo microservicios asiacute como la gran cantidad de datos generada implica queuna mejor gestioacuten de los recursos y la rapidez para desplegar o escalar solucionesdando valor al cliente lo maacutes raacutepido posible es uno de los objetivos de todas lasempresas de base tecnoloacutegica
Las ventajas que ofrecen los planificadores con aplicaciones distribuidas sonnumerosas sin ir maacutes lejos empresas tan punteras como Google llevan maacutesde 10 antildeos orquestando contenedores24 Por un lado permiten aumentar elrendimiento de los equipos propios y por otro implementar un servicio comoplataforma para despliegues distribuidos sobre cualquier conjunto hardware deesta forma se provee un servicio similar al de la nube puacuteblica pero con laprincipal diferencia de que se elimina la independencia con el proveedor (vendorlock-in) esto es las aplicaciones no tienen limitaciones impuestas por eacuteste talescomo lenguaje de programacioacuten o herramientas y permite despliegues hiacutebridosentre recursos propios y la nube
83 Objetivos conseguidos
Implementacioacuten de los planificadores propuestos en la nube Se ha en-tendido y detallado el funcionamiento de estas herramientas y se hanimplementado en el servicio de infraestructura de Microsoft Azure
Despliegue de aplicaciones y servicios distribuidos Servicios que se usanactualmente en la industria del desarrollo software asiacute como una aplica-cioacuten web con una arquitectura moderna han sido desplegados de formadistribuida en los equipos cumpliendo con la funcionalidad esperada ade-maacutes de consiguiendo una alta disponibilidad
Aproximacioacuten de arquitectura escalable Se ha hecho una aproximacioacutende infraestructura escalable de forma que sea parcialmente extrapolable aotros proveedores
24httpwwwnextplatformcom20160322decade-container-control-google
46
84 Liacuteneas de investigacioacuten
Siguiendo con la materia de este proyecto se presentan posibles liacuteneas deinvestigacioacuten
Analizar el despliegue con estas herramientas de aplicaciones de Big Datay comparar la eficiencia con respecto a soluciones especializadas
Analizar el rendimiento de los algoritmos de planificacioacuten antes pruebasde estreacutes y situaciones de alta contienda
Comparar el uso de estas herramientas con las praacutecticas actuales de laindustria o implementacioacuten en un sistema de produccioacuten real
47
Referencias
[1] LA Barroso y U Houmllzle laquoThe Datacenter as a Computer An Introduc-tion to the Design of Warehouse-Scale Machinesraquo En Morgan amp ClaypoolPublishers ()
[2] Systems Research Group ndash NetOS (University of Cambridge) The evolu-tion of cluster scheduler architectures 2016 url httpswwwclcamacukresearchsrgnetoscamsasblog2016-03-09-scheduler-architectureshtml
[3] A Das I Gupta y A Motivala SWIM Scalable Weakly-consistent Infection-style Process Group Membership Protocol Inf teacutec Dept of ComputerScience Cornell University url https www cs cornell edu ~asdasresearchdsn02-swimpdf
[4] D Dubhashi y A Das Mastering Mesos PACKT Publishing mayo de2016
[5] The Apache Software Foundation Apache Mesos documentation urlhttpsmesosapacheorg
[6] David Greenberg Building Applications on Mesos OrsquoReilly Media 2016[7] Armand Grillet Comparison of Container Schedulers Inf teacutec Technische
Universitaumlt Berlin[8] HashiCorp Consul documentation url httpswwwconsulio[9] HashiCorp Nomad documentation url httpsdcosio[10] Dan C Marinescu Cloud computing theory and practice Morgan Kauf-
mann 2013[11] Mesosphere DCOS documentation url httpswwwnomadproject
io[12] Microsoft Azure documentation url httpsazuremicrosoftcom
es-esdocumentation[13] D Ongaro y J Ousterhout In Search of an Understandable Consensus
Algorithm Inf teacutec Stanford University url httpsraftgithubioraftpdf
[14] Fei Teng laquoRessource allocation and schelduling models for cloud compu-tingraquo Tesis de mtriacutea Ecole Centrale Paris 2011
[15] A Williams y col Automation and Orchestration with Docker and Contai-ners A Comprehensive Overview of the Docker and Container Ecosystem3 The New Stack 2016
48
- Resumen
- Summary
- Iacutendice de figuras
- Introduccioacuten y objetivos
-
- Contexto
- Objetivos
- Estructura del documento
-
- Cloud Computing
- Nuevas cargas de trabajo
- Gestioacuten de recursos Planificadores
-
- Sistemas distribuidos
-
- Clasificacioacuten
-
- Herramientas
-
- DCOS
-
- Apache Mesos
- Ejemplos de uso
-
- Nomad
-
- Protocolo de consenso Raft
- Protocolo gossip SWIM
- Planificacioacuten
-
- Casos de uso y despliegue
-
- Aplicacioacuten Web
-
- DCOS
- Nomad
-
- Servicio de integracioacuten continua
-
- DevOps
- Integracioacuten Continua
- Jenkins con Nomad
- Jenkins con DCOS
-
- Escalando la infraestructura
-
- Disentildeo
- Implementacioacuten
-
- Resultados y conclusiones
-
- Comparacioacuten
- Conclusiones
- Objetivos conseguidos
- Liacuteneas de investigacioacuten
-
hosts dado su contrasentildea o clave puacuteblica puede arrancar el script y realizariacutealos pasos de forma remota gestionando el cluster desde un solo equipo
Se han desarrollado guiones para lo siguiente
Descarga de los binarios de Nomad y Consul en todos los nodos copiade los ficheros de configuracioacuten baacutesicos y modificarlos de acuerdo a cadanodo (nombre del equipo direccioacuten IP)
Instalacioacuten de las dependencias
Arranque de Nomad y Consul
Ansible extiende su funcionalidad a traveacutes de moacutedulos independientes que per-miten por ejemplo instalar paquetes mediante herramientas de gestioacuten de pa-quetes (APT yum) aprovisionar automaacuteticamente maacutequinas virtuales de Ama-zon EC2
Algunas opciones de los ficheros de configuracioacuten de Nomad y Consul sondependientes del nodo particular por ejemplo la interfaz de red Para estetrabajo se ha realizado un moacutedulo para modificar los ficheros de configuracioacutende forma automaacutetica En el repositorio del proyecto se encuentra una carpetadonde se encuentran todos los ficheros necesarios para desplegar un clustertotalmente funcional solo requiere de una liacutenea de terminal con Ansible
$ ans ib l eminusplaybook minus i hos t s minusk ltssh_passgt minusu ltnode_usergt s i t e yml
39
62 Servicio de integracioacuten continua
Se ha implementado un sistema de integracioacuten continua que permite ejecu-tar tareas de compilacioacuten y pruebas de forma distribuida aumentando asiacute elrendimiento de los equipos En primer lugar se detallaraacute los motivos por los quepuede resultar beneficioso para las empresas una implementacioacuten de este tipo alo que seguiraacute los detalles del despliegue
621 DevOps
Metodologiacutea que defiende la comunicacioacuten y colaboracioacuten entre desarrolla-dores de software y los profesionales de operaciones a lo largo de todo el ciclo devida de una aplicacioacuten Estaacute muy relacionado con el desarrollo aacutegil de softwareesto es un enfoque para los proyectos que defiende el desarrollo iterativo e in-cremental donde los requisitos y soluciones evolucionan con el tiempo seguacuten lanecesidad del proyecto DevOps extiende esta filosofiacutea a todas los componentesde un servicio incluyendo sistemas y operaciones
Se trata de un concepto que cada organizacioacuten o empresa adapta a suspropias necesidades y procesos de negocio en este proyecto nos vamos a centraren la integracioacuten continua una praacutectica fundamental tanto del desarrollo aacutegilcomo de esta filosofiacutea
622 Integracioacuten Continua
Se define como una praacutectica de desarrollo software donde los miembros delequipo ponen en comuacuten su trabajo frecuentemente al menos una vez al diacutea21Cada integracioacuten se verifica con una compilacioacuten automaacutetica que incluye laejecucioacuten de pruebas para detectar errores de integracioacuten tan pronto como seaposible
Desde el punto de vista operativo esto supone automatizar la configuracioacutende equipos o el despliegue de maacutequinas virtuales donde compilar el proyecto yejecutar las pruebas y posteriormente eliminarlas Este flujo de trabajo se vebeneficiado en entornos distribuidos ya que el objetivo del desarrollador es com-probar el resultado de las pruebas raacutepidamente sin preocuparse del despliegueo los propios equipos
Para esta prueba de concepto vamos a usar Jenkins un servidor de integra-cioacuten continua escrito en Java que nos permite definir trabajos que contendraacutenla descripcioacuten tanto del entorno como su ejecucioacuten
Este sigue una estructura maestro-esclavo muy similar al de los gestores declusters usados en este proyecto el maestro contiene toda la loacutegica del servicio
21httpmartinfowlercomarticlescontinuousIntegrationhtml
40
trabajos autenticacioacuten y los esclavos son los encargados de la ejecucioacuten ensiacute Jenkins tiene varias viacuteas para aprovisionar los uacuteltimos
Mediante SSH
Interfaz graacutefica
Desarrollar un script propio
Ejecucioacuten de un fichero java
La ventaja de usar planificadores es que el despliegue de esclavos es dinaacutemicoes decir no tener una maacutequina especiacuteficamente configurada para ello DCOS yNomad se encargaraacuten de configurar estos despliegues en sus maacutequinas y poste-riormente eliminarlos Para ello se ha usado la uacuteltima opcioacuten definiendo tareasque descarguen el fichero java Con todo ello se consigue un entorno de inte-gracioacuten continua eficiente que ademaacutes permite la ejecucioacuten de otros servicios deforma independiente
Jenkins permite la creacioacuten de plugins que extienden sus funcionalidadesTanto Nomad22 como Apache Mesos cuentan con uno que permite su integra-cioacuten
Para esta prueba se va a usar el mismo proyecto que para el caso de usode orquestacioacuten de contenedores la aplicacioacuten web al que se le ha antildeadido untest para comprobar que se conecta correctamente a la base de datos medianteMocha un framework de Nodejs Por otro lado se antildeade el plugin de git ya queel coacutedigo se obtiene de GitHub el repositorio remoto de control de versiones delproyecto
El proceso general de ejecucioacuten seriacutea como sigue
1 Se ejecuta el maestro de Jenkins como tarea Docker partiendo de la imagenoficial
2 Al arrancar un trabajo se manda una tarea a los planificadores que laasignaraacuten a un nodo cliente Esta tarea consiste en la descarga del ficherode configuracioacuten Java y arrancarlo configurando el equipo como un clientede Jenkins temporalmente
3 Jenkins ejecuta el trabajo en el nuevo cliente en este caso iniciar la apli-cacioacuten web iniciar las pruebas y generar un informe
4 Se elimina el cliente
A continuacioacuten se detallan los matices de cada herramienta a la hora de imple-mentar este servicio
22Desarrollado por Ivo Verberk httpwwwivoverberknl
41
623 Jenkins con Nomad
El plugin permite la ejecucioacuten del fichero Java mediante dos controladorescontenedores Docker y Java En este proyecto nos hemos decantado por el pri-mero ya que nos ahorra instalar la maacutequina virtual de java en todos los nodoscliente Por ello se ha construido un contenedor base con Java para la ejecucioacutendel fichero de configuracioacuten y Nodejs para lanzar la aplicacioacuten web
El plugin se configura con la direccioacuten IP del cluster y el contenedor queejecuta el esclavo Jenkins Por su parte el trabajo en Jenkins se define conel repositorio en GitHub donde se aloja el coacutedigo del proyecto a probar y loscomandos a ejecutar en este caso npm update y npm test
624 Jenkins con DCOS
En el caso de DCOS su sistema de paquetes incluye Jenkins por lo queal instalarlo ya se tiene la configuracioacuten de Mesos totalmente funcional Sinembargo para ejecutar la aplicacioacuten en particular y las pruebas se requiere deNodejs en los equipos esclavos por ello debemos antildeadir un plugin de Jenkinsque permite instalar este entorno antes de ejecutar el trabajo Una vez hechoesto soacutelo queda definir la tarea igual que en el caso anterior
Cabe destacar que Mesosphere tambieacuten ha desarrollado un plugin que per-mite hacer despliegues en Marathon de tal manera que permitiriacutea con cadacommit del coacutedigo compilar la imagen del contenedor Docker y desplegarlaautomaacuteticamente aunque en este proyecto no se ha hecho pruebas de esta fun-cionalidad
42
7 Escalando la infraestructura
Uno de los factores clave que se busca a la hora de implementar sistemasdistribuidos es el poder escalar la infraestructura de forma maacutes sencilla estoes detectar que las maacutequinas estaacuten alcanzando el liacutemite de su capacidad yaumentar eacutesta ya sea mejorando sus caracteriacutesticas teacutecnicas o antildeadiendo maacutesnodos al cluster
El coacutedigo y todos los ficheros de configuracioacuten de esta seccioacuten tambieacuten sepueden encontrar en el repositorio del proyecto en GitHub23
71 Disentildeo
Microsoft Azure permite organizar los servicios cloud de forma loacutegica a traveacutesde grupos de recursos y asiacute poder crear o eliminar eacutestos en conjunto parauna aplicacioacuten determinada (por ejemplo una aplicacioacuten web suele requerir demaacutequinas virtuales bases de datos almacenamiento) Ademaacutes dispone dela opcioacuten de crear plantillas en formato JSON que permite al desarrolladordefinir los recursos y su interrelacioacuten para desplegar de forma automaacutetica unainfraestructura TI en la nube
Azure tambieacuten ofrece la posibilidad de monitorizar el estado de las maacutequinasvirtuales a traveacutes de extensiones lo que permite configurar el escalado automaacute-tico al alcanzar cierto liacutemite definido por el operador Eacutesta es a priori la formaen que deberiacutea implementarse hablando en teacuterminos de eficiencia sin embargoesta aproximacioacuten es totalmente dependiente de la plataforma es decir no sepuede extrapolar a otro proveedor o sobre recursos propios sin realizar un nue-vo disentildeo En este proyecto las tareas que son ejecutadas por estos equipos notienen estado ya que todo lo relativo a la persistencia lo hemos asignado fueradel cluster esto permite escalar la plataforma a traveacutes de otra aproximaciones
Las plantillas aceptan una serie de variables a indicar por el usuario entreotras los conjuntos de escala para definir los nodos aceptan una variable quedefine el nuacutemero de maacutequinas que los componen Por otro lado Azure ofreceuna API REST y kits de desarrollo software (SDK por sus siglas en ingleacutes) quepermiten su despliegue de forma programaacutetica Aprovechando estas facilidadesen este proyecto se va a aproximar la escalabilidad con el sucesivo desplieguede la infraestructura de forma automaacutetica se monitorizan los equipos y si sedetecta una maacutequina excesivamente cargada se aumenta el nuacutemero de equiposen la plantilla y se vuelve a desplegar
23httpsgithubcomAntonioAlfrzCloud-Orchestrators
43
En este proyecto se han disentildeado las plantillas para desplegar la arquitec-tura necesaria tanto de Nomad como de DCOS En el caso de la primera eldespliegue es maacutes descriptivo ya que incluye maacutequinas virtuales grupos de se-guridad redes En el caso de DCOS Azure cuenta con un servicio especiacuteficopara clusters gobernados por DCOS denominado Azure Container Service queincluye los componentes necesarios y la instalacioacuten ya realizada
72 Implementacioacuten
En primer lugar para monitorizar el estado de los equipos se va a usar laherramienta Nagios un sistema que permite controlar el estado del hardwarey los servicios de un equipo Se trata de una herramienta muy completa de laque se va a usar su capacidad para ejecutar comandos (plugins) en los nodospara detectar picos de carga generar alertas y ejecutar programas para estoseventos
Se ha desplegado una maacutequina virtual con esta herramienta en ambos siste-mas y se ha instalado una extensioacuten de Nagios (Nagios Remote Plugin Executor)en todos los nodos que permite ejecutar comprobaciones remotamente en con-creto para esta prueba de concepto medir el nivel de saturacioacuten de la unidadcentral de procesamiento (CPU por sus siglas del ingleacutes) Cuando sucede uncambio de estado de una maacutequina esto es cuando este paraacutemetro supera el liacutemi-te definido por el operador Nagios permite actuar en consecuencia ejecutandoprogramas por ello se ha desarrollado un script que ejecuta lo siguiente
Un programa desarrollado en Python con el SDK de Azure que modificalas plantillas y despliega los recursos
Un guioacuten de Ansible para instalar todos los componentes necesarios en lasnuevas maacutequinas y arrancar de nuevo el cluster y las aplicaciones
44
8 Resultados y conclusiones
En este uacuteltimo apartado se da una visioacuten global del proyecto asiacute como a lasconclusiones maacutes importantes a las que se ha llegado y posibles temas futurosde desarrollo
81 Comparacioacuten
Ambas herramientas ofrecen las funcionalidades para gestionar los recursoseficientemente ofreciendo a los desarrolladores una plataforma donde desplegarsus aplicaciones de forma distribuida independientemente de los equipos fiacutesicosy el hardware que las soporten
DCOS es una herramienta que en un comienzo fue privativa pero cuyos res-ponsables la empresa Mesosphere decidieron publicar una versioacuten de coacutedigoEacutesta nos permite gestionar un cluster de una forma sencilla y usable ademaacutes decomplementarlo con otras herramientas como el balanceador de carga integradoo la autenticacioacuten de usuarios ademaacutes estaacute basada en Apache Mesos un pro-yecto de relativa madurez y con el soporte de la Apache Software FoundationDe forma resumida DCOS ofrece muchas posibilidades y servicios a cambiode una arquitectura e instalacioacuten maacutes compleja
Por su parte HashiCorp con menor tiempo de desarrollo ha conseguidouna herramienta muy sencilla de desplegar que ademaacutes cumple con todas lasfuncionalidades baacutesicas ejecutando un simple binario en cada nodo se puededesplegar un gestor de clusters totalmente funcional Sin embargo no cuentacon todas las posibilidades de Mesos (Nomad cuenta con menos controladoresque entornos posibles de Mesos) ni con los antildeadidos de DCOS lo que implicael uso de otras herramientas para complementar el servicio (Consul HAProxy)
De entre las dificultades encontradas al usar estas herramientas y desplegaraplicaciones sobre ellas se puede destacar la depuracioacuten en ocasiones se desco-noce si un error viene de la propia herramienta de la aplicacioacuten desplegada o delequipo fiacutesico si no se cuenta con un sistema de procesamiento de registro unose puede encontrar con muacuteltiples terminales abiertas inspeccionando numerososficheros de registro buscando posibles errores Ademaacutes no dejan de ser solucio-nes que para usar eficientemente se debe conocer parte de su funcionamientoy sintaxis a la hora de describir la tareas lo que supone un esfuerzo antildeadido yaque cada una tiene sus particularidades y liacutemites
45
82 Conclusiones
En una sociedad cada vez maacutes digital las empresas deben adaptarse a unmercado cuya demanda de contenido no deja de crecer Las nuevas arquitecturascomo microservicios asiacute como la gran cantidad de datos generada implica queuna mejor gestioacuten de los recursos y la rapidez para desplegar o escalar solucionesdando valor al cliente lo maacutes raacutepido posible es uno de los objetivos de todas lasempresas de base tecnoloacutegica
Las ventajas que ofrecen los planificadores con aplicaciones distribuidas sonnumerosas sin ir maacutes lejos empresas tan punteras como Google llevan maacutesde 10 antildeos orquestando contenedores24 Por un lado permiten aumentar elrendimiento de los equipos propios y por otro implementar un servicio comoplataforma para despliegues distribuidos sobre cualquier conjunto hardware deesta forma se provee un servicio similar al de la nube puacuteblica pero con laprincipal diferencia de que se elimina la independencia con el proveedor (vendorlock-in) esto es las aplicaciones no tienen limitaciones impuestas por eacuteste talescomo lenguaje de programacioacuten o herramientas y permite despliegues hiacutebridosentre recursos propios y la nube
83 Objetivos conseguidos
Implementacioacuten de los planificadores propuestos en la nube Se ha en-tendido y detallado el funcionamiento de estas herramientas y se hanimplementado en el servicio de infraestructura de Microsoft Azure
Despliegue de aplicaciones y servicios distribuidos Servicios que se usanactualmente en la industria del desarrollo software asiacute como una aplica-cioacuten web con una arquitectura moderna han sido desplegados de formadistribuida en los equipos cumpliendo con la funcionalidad esperada ade-maacutes de consiguiendo una alta disponibilidad
Aproximacioacuten de arquitectura escalable Se ha hecho una aproximacioacutende infraestructura escalable de forma que sea parcialmente extrapolable aotros proveedores
24httpwwwnextplatformcom20160322decade-container-control-google
46
84 Liacuteneas de investigacioacuten
Siguiendo con la materia de este proyecto se presentan posibles liacuteneas deinvestigacioacuten
Analizar el despliegue con estas herramientas de aplicaciones de Big Datay comparar la eficiencia con respecto a soluciones especializadas
Analizar el rendimiento de los algoritmos de planificacioacuten antes pruebasde estreacutes y situaciones de alta contienda
Comparar el uso de estas herramientas con las praacutecticas actuales de laindustria o implementacioacuten en un sistema de produccioacuten real
47
Referencias
[1] LA Barroso y U Houmllzle laquoThe Datacenter as a Computer An Introduc-tion to the Design of Warehouse-Scale Machinesraquo En Morgan amp ClaypoolPublishers ()
[2] Systems Research Group ndash NetOS (University of Cambridge) The evolu-tion of cluster scheduler architectures 2016 url httpswwwclcamacukresearchsrgnetoscamsasblog2016-03-09-scheduler-architectureshtml
[3] A Das I Gupta y A Motivala SWIM Scalable Weakly-consistent Infection-style Process Group Membership Protocol Inf teacutec Dept of ComputerScience Cornell University url https www cs cornell edu ~asdasresearchdsn02-swimpdf
[4] D Dubhashi y A Das Mastering Mesos PACKT Publishing mayo de2016
[5] The Apache Software Foundation Apache Mesos documentation urlhttpsmesosapacheorg
[6] David Greenberg Building Applications on Mesos OrsquoReilly Media 2016[7] Armand Grillet Comparison of Container Schedulers Inf teacutec Technische
Universitaumlt Berlin[8] HashiCorp Consul documentation url httpswwwconsulio[9] HashiCorp Nomad documentation url httpsdcosio[10] Dan C Marinescu Cloud computing theory and practice Morgan Kauf-
mann 2013[11] Mesosphere DCOS documentation url httpswwwnomadproject
io[12] Microsoft Azure documentation url httpsazuremicrosoftcom
es-esdocumentation[13] D Ongaro y J Ousterhout In Search of an Understandable Consensus
Algorithm Inf teacutec Stanford University url httpsraftgithubioraftpdf
[14] Fei Teng laquoRessource allocation and schelduling models for cloud compu-tingraquo Tesis de mtriacutea Ecole Centrale Paris 2011
[15] A Williams y col Automation and Orchestration with Docker and Contai-ners A Comprehensive Overview of the Docker and Container Ecosystem3 The New Stack 2016
48
- Resumen
- Summary
- Iacutendice de figuras
- Introduccioacuten y objetivos
-
- Contexto
- Objetivos
- Estructura del documento
-
- Cloud Computing
- Nuevas cargas de trabajo
- Gestioacuten de recursos Planificadores
-
- Sistemas distribuidos
-
- Clasificacioacuten
-
- Herramientas
-
- DCOS
-
- Apache Mesos
- Ejemplos de uso
-
- Nomad
-
- Protocolo de consenso Raft
- Protocolo gossip SWIM
- Planificacioacuten
-
- Casos de uso y despliegue
-
- Aplicacioacuten Web
-
- DCOS
- Nomad
-
- Servicio de integracioacuten continua
-
- DevOps
- Integracioacuten Continua
- Jenkins con Nomad
- Jenkins con DCOS
-
- Escalando la infraestructura
-
- Disentildeo
- Implementacioacuten
-
- Resultados y conclusiones
-
- Comparacioacuten
- Conclusiones
- Objetivos conseguidos
- Liacuteneas de investigacioacuten
-
62 Servicio de integracioacuten continua
Se ha implementado un sistema de integracioacuten continua que permite ejecu-tar tareas de compilacioacuten y pruebas de forma distribuida aumentando asiacute elrendimiento de los equipos En primer lugar se detallaraacute los motivos por los quepuede resultar beneficioso para las empresas una implementacioacuten de este tipo alo que seguiraacute los detalles del despliegue
621 DevOps
Metodologiacutea que defiende la comunicacioacuten y colaboracioacuten entre desarrolla-dores de software y los profesionales de operaciones a lo largo de todo el ciclo devida de una aplicacioacuten Estaacute muy relacionado con el desarrollo aacutegil de softwareesto es un enfoque para los proyectos que defiende el desarrollo iterativo e in-cremental donde los requisitos y soluciones evolucionan con el tiempo seguacuten lanecesidad del proyecto DevOps extiende esta filosofiacutea a todas los componentesde un servicio incluyendo sistemas y operaciones
Se trata de un concepto que cada organizacioacuten o empresa adapta a suspropias necesidades y procesos de negocio en este proyecto nos vamos a centraren la integracioacuten continua una praacutectica fundamental tanto del desarrollo aacutegilcomo de esta filosofiacutea
622 Integracioacuten Continua
Se define como una praacutectica de desarrollo software donde los miembros delequipo ponen en comuacuten su trabajo frecuentemente al menos una vez al diacutea21Cada integracioacuten se verifica con una compilacioacuten automaacutetica que incluye laejecucioacuten de pruebas para detectar errores de integracioacuten tan pronto como seaposible
Desde el punto de vista operativo esto supone automatizar la configuracioacutende equipos o el despliegue de maacutequinas virtuales donde compilar el proyecto yejecutar las pruebas y posteriormente eliminarlas Este flujo de trabajo se vebeneficiado en entornos distribuidos ya que el objetivo del desarrollador es com-probar el resultado de las pruebas raacutepidamente sin preocuparse del despliegueo los propios equipos
Para esta prueba de concepto vamos a usar Jenkins un servidor de integra-cioacuten continua escrito en Java que nos permite definir trabajos que contendraacutenla descripcioacuten tanto del entorno como su ejecucioacuten
Este sigue una estructura maestro-esclavo muy similar al de los gestores declusters usados en este proyecto el maestro contiene toda la loacutegica del servicio
21httpmartinfowlercomarticlescontinuousIntegrationhtml
40
trabajos autenticacioacuten y los esclavos son los encargados de la ejecucioacuten ensiacute Jenkins tiene varias viacuteas para aprovisionar los uacuteltimos
Mediante SSH
Interfaz graacutefica
Desarrollar un script propio
Ejecucioacuten de un fichero java
La ventaja de usar planificadores es que el despliegue de esclavos es dinaacutemicoes decir no tener una maacutequina especiacuteficamente configurada para ello DCOS yNomad se encargaraacuten de configurar estos despliegues en sus maacutequinas y poste-riormente eliminarlos Para ello se ha usado la uacuteltima opcioacuten definiendo tareasque descarguen el fichero java Con todo ello se consigue un entorno de inte-gracioacuten continua eficiente que ademaacutes permite la ejecucioacuten de otros servicios deforma independiente
Jenkins permite la creacioacuten de plugins que extienden sus funcionalidadesTanto Nomad22 como Apache Mesos cuentan con uno que permite su integra-cioacuten
Para esta prueba se va a usar el mismo proyecto que para el caso de usode orquestacioacuten de contenedores la aplicacioacuten web al que se le ha antildeadido untest para comprobar que se conecta correctamente a la base de datos medianteMocha un framework de Nodejs Por otro lado se antildeade el plugin de git ya queel coacutedigo se obtiene de GitHub el repositorio remoto de control de versiones delproyecto
El proceso general de ejecucioacuten seriacutea como sigue
1 Se ejecuta el maestro de Jenkins como tarea Docker partiendo de la imagenoficial
2 Al arrancar un trabajo se manda una tarea a los planificadores que laasignaraacuten a un nodo cliente Esta tarea consiste en la descarga del ficherode configuracioacuten Java y arrancarlo configurando el equipo como un clientede Jenkins temporalmente
3 Jenkins ejecuta el trabajo en el nuevo cliente en este caso iniciar la apli-cacioacuten web iniciar las pruebas y generar un informe
4 Se elimina el cliente
A continuacioacuten se detallan los matices de cada herramienta a la hora de imple-mentar este servicio
22Desarrollado por Ivo Verberk httpwwwivoverberknl
41
623 Jenkins con Nomad
El plugin permite la ejecucioacuten del fichero Java mediante dos controladorescontenedores Docker y Java En este proyecto nos hemos decantado por el pri-mero ya que nos ahorra instalar la maacutequina virtual de java en todos los nodoscliente Por ello se ha construido un contenedor base con Java para la ejecucioacutendel fichero de configuracioacuten y Nodejs para lanzar la aplicacioacuten web
El plugin se configura con la direccioacuten IP del cluster y el contenedor queejecuta el esclavo Jenkins Por su parte el trabajo en Jenkins se define conel repositorio en GitHub donde se aloja el coacutedigo del proyecto a probar y loscomandos a ejecutar en este caso npm update y npm test
624 Jenkins con DCOS
En el caso de DCOS su sistema de paquetes incluye Jenkins por lo queal instalarlo ya se tiene la configuracioacuten de Mesos totalmente funcional Sinembargo para ejecutar la aplicacioacuten en particular y las pruebas se requiere deNodejs en los equipos esclavos por ello debemos antildeadir un plugin de Jenkinsque permite instalar este entorno antes de ejecutar el trabajo Una vez hechoesto soacutelo queda definir la tarea igual que en el caso anterior
Cabe destacar que Mesosphere tambieacuten ha desarrollado un plugin que per-mite hacer despliegues en Marathon de tal manera que permitiriacutea con cadacommit del coacutedigo compilar la imagen del contenedor Docker y desplegarlaautomaacuteticamente aunque en este proyecto no se ha hecho pruebas de esta fun-cionalidad
42
7 Escalando la infraestructura
Uno de los factores clave que se busca a la hora de implementar sistemasdistribuidos es el poder escalar la infraestructura de forma maacutes sencilla estoes detectar que las maacutequinas estaacuten alcanzando el liacutemite de su capacidad yaumentar eacutesta ya sea mejorando sus caracteriacutesticas teacutecnicas o antildeadiendo maacutesnodos al cluster
El coacutedigo y todos los ficheros de configuracioacuten de esta seccioacuten tambieacuten sepueden encontrar en el repositorio del proyecto en GitHub23
71 Disentildeo
Microsoft Azure permite organizar los servicios cloud de forma loacutegica a traveacutesde grupos de recursos y asiacute poder crear o eliminar eacutestos en conjunto parauna aplicacioacuten determinada (por ejemplo una aplicacioacuten web suele requerir demaacutequinas virtuales bases de datos almacenamiento) Ademaacutes dispone dela opcioacuten de crear plantillas en formato JSON que permite al desarrolladordefinir los recursos y su interrelacioacuten para desplegar de forma automaacutetica unainfraestructura TI en la nube
Azure tambieacuten ofrece la posibilidad de monitorizar el estado de las maacutequinasvirtuales a traveacutes de extensiones lo que permite configurar el escalado automaacute-tico al alcanzar cierto liacutemite definido por el operador Eacutesta es a priori la formaen que deberiacutea implementarse hablando en teacuterminos de eficiencia sin embargoesta aproximacioacuten es totalmente dependiente de la plataforma es decir no sepuede extrapolar a otro proveedor o sobre recursos propios sin realizar un nue-vo disentildeo En este proyecto las tareas que son ejecutadas por estos equipos notienen estado ya que todo lo relativo a la persistencia lo hemos asignado fueradel cluster esto permite escalar la plataforma a traveacutes de otra aproximaciones
Las plantillas aceptan una serie de variables a indicar por el usuario entreotras los conjuntos de escala para definir los nodos aceptan una variable quedefine el nuacutemero de maacutequinas que los componen Por otro lado Azure ofreceuna API REST y kits de desarrollo software (SDK por sus siglas en ingleacutes) quepermiten su despliegue de forma programaacutetica Aprovechando estas facilidadesen este proyecto se va a aproximar la escalabilidad con el sucesivo desplieguede la infraestructura de forma automaacutetica se monitorizan los equipos y si sedetecta una maacutequina excesivamente cargada se aumenta el nuacutemero de equiposen la plantilla y se vuelve a desplegar
23httpsgithubcomAntonioAlfrzCloud-Orchestrators
43
En este proyecto se han disentildeado las plantillas para desplegar la arquitec-tura necesaria tanto de Nomad como de DCOS En el caso de la primera eldespliegue es maacutes descriptivo ya que incluye maacutequinas virtuales grupos de se-guridad redes En el caso de DCOS Azure cuenta con un servicio especiacuteficopara clusters gobernados por DCOS denominado Azure Container Service queincluye los componentes necesarios y la instalacioacuten ya realizada
72 Implementacioacuten
En primer lugar para monitorizar el estado de los equipos se va a usar laherramienta Nagios un sistema que permite controlar el estado del hardwarey los servicios de un equipo Se trata de una herramienta muy completa de laque se va a usar su capacidad para ejecutar comandos (plugins) en los nodospara detectar picos de carga generar alertas y ejecutar programas para estoseventos
Se ha desplegado una maacutequina virtual con esta herramienta en ambos siste-mas y se ha instalado una extensioacuten de Nagios (Nagios Remote Plugin Executor)en todos los nodos que permite ejecutar comprobaciones remotamente en con-creto para esta prueba de concepto medir el nivel de saturacioacuten de la unidadcentral de procesamiento (CPU por sus siglas del ingleacutes) Cuando sucede uncambio de estado de una maacutequina esto es cuando este paraacutemetro supera el liacutemi-te definido por el operador Nagios permite actuar en consecuencia ejecutandoprogramas por ello se ha desarrollado un script que ejecuta lo siguiente
Un programa desarrollado en Python con el SDK de Azure que modificalas plantillas y despliega los recursos
Un guioacuten de Ansible para instalar todos los componentes necesarios en lasnuevas maacutequinas y arrancar de nuevo el cluster y las aplicaciones
44
8 Resultados y conclusiones
En este uacuteltimo apartado se da una visioacuten global del proyecto asiacute como a lasconclusiones maacutes importantes a las que se ha llegado y posibles temas futurosde desarrollo
81 Comparacioacuten
Ambas herramientas ofrecen las funcionalidades para gestionar los recursoseficientemente ofreciendo a los desarrolladores una plataforma donde desplegarsus aplicaciones de forma distribuida independientemente de los equipos fiacutesicosy el hardware que las soporten
DCOS es una herramienta que en un comienzo fue privativa pero cuyos res-ponsables la empresa Mesosphere decidieron publicar una versioacuten de coacutedigoEacutesta nos permite gestionar un cluster de una forma sencilla y usable ademaacutes decomplementarlo con otras herramientas como el balanceador de carga integradoo la autenticacioacuten de usuarios ademaacutes estaacute basada en Apache Mesos un pro-yecto de relativa madurez y con el soporte de la Apache Software FoundationDe forma resumida DCOS ofrece muchas posibilidades y servicios a cambiode una arquitectura e instalacioacuten maacutes compleja
Por su parte HashiCorp con menor tiempo de desarrollo ha conseguidouna herramienta muy sencilla de desplegar que ademaacutes cumple con todas lasfuncionalidades baacutesicas ejecutando un simple binario en cada nodo se puededesplegar un gestor de clusters totalmente funcional Sin embargo no cuentacon todas las posibilidades de Mesos (Nomad cuenta con menos controladoresque entornos posibles de Mesos) ni con los antildeadidos de DCOS lo que implicael uso de otras herramientas para complementar el servicio (Consul HAProxy)
De entre las dificultades encontradas al usar estas herramientas y desplegaraplicaciones sobre ellas se puede destacar la depuracioacuten en ocasiones se desco-noce si un error viene de la propia herramienta de la aplicacioacuten desplegada o delequipo fiacutesico si no se cuenta con un sistema de procesamiento de registro unose puede encontrar con muacuteltiples terminales abiertas inspeccionando numerososficheros de registro buscando posibles errores Ademaacutes no dejan de ser solucio-nes que para usar eficientemente se debe conocer parte de su funcionamientoy sintaxis a la hora de describir la tareas lo que supone un esfuerzo antildeadido yaque cada una tiene sus particularidades y liacutemites
45
82 Conclusiones
En una sociedad cada vez maacutes digital las empresas deben adaptarse a unmercado cuya demanda de contenido no deja de crecer Las nuevas arquitecturascomo microservicios asiacute como la gran cantidad de datos generada implica queuna mejor gestioacuten de los recursos y la rapidez para desplegar o escalar solucionesdando valor al cliente lo maacutes raacutepido posible es uno de los objetivos de todas lasempresas de base tecnoloacutegica
Las ventajas que ofrecen los planificadores con aplicaciones distribuidas sonnumerosas sin ir maacutes lejos empresas tan punteras como Google llevan maacutesde 10 antildeos orquestando contenedores24 Por un lado permiten aumentar elrendimiento de los equipos propios y por otro implementar un servicio comoplataforma para despliegues distribuidos sobre cualquier conjunto hardware deesta forma se provee un servicio similar al de la nube puacuteblica pero con laprincipal diferencia de que se elimina la independencia con el proveedor (vendorlock-in) esto es las aplicaciones no tienen limitaciones impuestas por eacuteste talescomo lenguaje de programacioacuten o herramientas y permite despliegues hiacutebridosentre recursos propios y la nube
83 Objetivos conseguidos
Implementacioacuten de los planificadores propuestos en la nube Se ha en-tendido y detallado el funcionamiento de estas herramientas y se hanimplementado en el servicio de infraestructura de Microsoft Azure
Despliegue de aplicaciones y servicios distribuidos Servicios que se usanactualmente en la industria del desarrollo software asiacute como una aplica-cioacuten web con una arquitectura moderna han sido desplegados de formadistribuida en los equipos cumpliendo con la funcionalidad esperada ade-maacutes de consiguiendo una alta disponibilidad
Aproximacioacuten de arquitectura escalable Se ha hecho una aproximacioacutende infraestructura escalable de forma que sea parcialmente extrapolable aotros proveedores
24httpwwwnextplatformcom20160322decade-container-control-google
46
84 Liacuteneas de investigacioacuten
Siguiendo con la materia de este proyecto se presentan posibles liacuteneas deinvestigacioacuten
Analizar el despliegue con estas herramientas de aplicaciones de Big Datay comparar la eficiencia con respecto a soluciones especializadas
Analizar el rendimiento de los algoritmos de planificacioacuten antes pruebasde estreacutes y situaciones de alta contienda
Comparar el uso de estas herramientas con las praacutecticas actuales de laindustria o implementacioacuten en un sistema de produccioacuten real
47
Referencias
[1] LA Barroso y U Houmllzle laquoThe Datacenter as a Computer An Introduc-tion to the Design of Warehouse-Scale Machinesraquo En Morgan amp ClaypoolPublishers ()
[2] Systems Research Group ndash NetOS (University of Cambridge) The evolu-tion of cluster scheduler architectures 2016 url httpswwwclcamacukresearchsrgnetoscamsasblog2016-03-09-scheduler-architectureshtml
[3] A Das I Gupta y A Motivala SWIM Scalable Weakly-consistent Infection-style Process Group Membership Protocol Inf teacutec Dept of ComputerScience Cornell University url https www cs cornell edu ~asdasresearchdsn02-swimpdf
[4] D Dubhashi y A Das Mastering Mesos PACKT Publishing mayo de2016
[5] The Apache Software Foundation Apache Mesos documentation urlhttpsmesosapacheorg
[6] David Greenberg Building Applications on Mesos OrsquoReilly Media 2016[7] Armand Grillet Comparison of Container Schedulers Inf teacutec Technische
Universitaumlt Berlin[8] HashiCorp Consul documentation url httpswwwconsulio[9] HashiCorp Nomad documentation url httpsdcosio[10] Dan C Marinescu Cloud computing theory and practice Morgan Kauf-
mann 2013[11] Mesosphere DCOS documentation url httpswwwnomadproject
io[12] Microsoft Azure documentation url httpsazuremicrosoftcom
es-esdocumentation[13] D Ongaro y J Ousterhout In Search of an Understandable Consensus
Algorithm Inf teacutec Stanford University url httpsraftgithubioraftpdf
[14] Fei Teng laquoRessource allocation and schelduling models for cloud compu-tingraquo Tesis de mtriacutea Ecole Centrale Paris 2011
[15] A Williams y col Automation and Orchestration with Docker and Contai-ners A Comprehensive Overview of the Docker and Container Ecosystem3 The New Stack 2016
48
- Resumen
- Summary
- Iacutendice de figuras
- Introduccioacuten y objetivos
-
- Contexto
- Objetivos
- Estructura del documento
-
- Cloud Computing
- Nuevas cargas de trabajo
- Gestioacuten de recursos Planificadores
-
- Sistemas distribuidos
-
- Clasificacioacuten
-
- Herramientas
-
- DCOS
-
- Apache Mesos
- Ejemplos de uso
-
- Nomad
-
- Protocolo de consenso Raft
- Protocolo gossip SWIM
- Planificacioacuten
-
- Casos de uso y despliegue
-
- Aplicacioacuten Web
-
- DCOS
- Nomad
-
- Servicio de integracioacuten continua
-
- DevOps
- Integracioacuten Continua
- Jenkins con Nomad
- Jenkins con DCOS
-
- Escalando la infraestructura
-
- Disentildeo
- Implementacioacuten
-
- Resultados y conclusiones
-
- Comparacioacuten
- Conclusiones
- Objetivos conseguidos
- Liacuteneas de investigacioacuten
-
trabajos autenticacioacuten y los esclavos son los encargados de la ejecucioacuten ensiacute Jenkins tiene varias viacuteas para aprovisionar los uacuteltimos
Mediante SSH
Interfaz graacutefica
Desarrollar un script propio
Ejecucioacuten de un fichero java
La ventaja de usar planificadores es que el despliegue de esclavos es dinaacutemicoes decir no tener una maacutequina especiacuteficamente configurada para ello DCOS yNomad se encargaraacuten de configurar estos despliegues en sus maacutequinas y poste-riormente eliminarlos Para ello se ha usado la uacuteltima opcioacuten definiendo tareasque descarguen el fichero java Con todo ello se consigue un entorno de inte-gracioacuten continua eficiente que ademaacutes permite la ejecucioacuten de otros servicios deforma independiente
Jenkins permite la creacioacuten de plugins que extienden sus funcionalidadesTanto Nomad22 como Apache Mesos cuentan con uno que permite su integra-cioacuten
Para esta prueba se va a usar el mismo proyecto que para el caso de usode orquestacioacuten de contenedores la aplicacioacuten web al que se le ha antildeadido untest para comprobar que se conecta correctamente a la base de datos medianteMocha un framework de Nodejs Por otro lado se antildeade el plugin de git ya queel coacutedigo se obtiene de GitHub el repositorio remoto de control de versiones delproyecto
El proceso general de ejecucioacuten seriacutea como sigue
1 Se ejecuta el maestro de Jenkins como tarea Docker partiendo de la imagenoficial
2 Al arrancar un trabajo se manda una tarea a los planificadores que laasignaraacuten a un nodo cliente Esta tarea consiste en la descarga del ficherode configuracioacuten Java y arrancarlo configurando el equipo como un clientede Jenkins temporalmente
3 Jenkins ejecuta el trabajo en el nuevo cliente en este caso iniciar la apli-cacioacuten web iniciar las pruebas y generar un informe
4 Se elimina el cliente
A continuacioacuten se detallan los matices de cada herramienta a la hora de imple-mentar este servicio
22Desarrollado por Ivo Verberk httpwwwivoverberknl
41
623 Jenkins con Nomad
El plugin permite la ejecucioacuten del fichero Java mediante dos controladorescontenedores Docker y Java En este proyecto nos hemos decantado por el pri-mero ya que nos ahorra instalar la maacutequina virtual de java en todos los nodoscliente Por ello se ha construido un contenedor base con Java para la ejecucioacutendel fichero de configuracioacuten y Nodejs para lanzar la aplicacioacuten web
El plugin se configura con la direccioacuten IP del cluster y el contenedor queejecuta el esclavo Jenkins Por su parte el trabajo en Jenkins se define conel repositorio en GitHub donde se aloja el coacutedigo del proyecto a probar y loscomandos a ejecutar en este caso npm update y npm test
624 Jenkins con DCOS
En el caso de DCOS su sistema de paquetes incluye Jenkins por lo queal instalarlo ya se tiene la configuracioacuten de Mesos totalmente funcional Sinembargo para ejecutar la aplicacioacuten en particular y las pruebas se requiere deNodejs en los equipos esclavos por ello debemos antildeadir un plugin de Jenkinsque permite instalar este entorno antes de ejecutar el trabajo Una vez hechoesto soacutelo queda definir la tarea igual que en el caso anterior
Cabe destacar que Mesosphere tambieacuten ha desarrollado un plugin que per-mite hacer despliegues en Marathon de tal manera que permitiriacutea con cadacommit del coacutedigo compilar la imagen del contenedor Docker y desplegarlaautomaacuteticamente aunque en este proyecto no se ha hecho pruebas de esta fun-cionalidad
42
7 Escalando la infraestructura
Uno de los factores clave que se busca a la hora de implementar sistemasdistribuidos es el poder escalar la infraestructura de forma maacutes sencilla estoes detectar que las maacutequinas estaacuten alcanzando el liacutemite de su capacidad yaumentar eacutesta ya sea mejorando sus caracteriacutesticas teacutecnicas o antildeadiendo maacutesnodos al cluster
El coacutedigo y todos los ficheros de configuracioacuten de esta seccioacuten tambieacuten sepueden encontrar en el repositorio del proyecto en GitHub23
71 Disentildeo
Microsoft Azure permite organizar los servicios cloud de forma loacutegica a traveacutesde grupos de recursos y asiacute poder crear o eliminar eacutestos en conjunto parauna aplicacioacuten determinada (por ejemplo una aplicacioacuten web suele requerir demaacutequinas virtuales bases de datos almacenamiento) Ademaacutes dispone dela opcioacuten de crear plantillas en formato JSON que permite al desarrolladordefinir los recursos y su interrelacioacuten para desplegar de forma automaacutetica unainfraestructura TI en la nube
Azure tambieacuten ofrece la posibilidad de monitorizar el estado de las maacutequinasvirtuales a traveacutes de extensiones lo que permite configurar el escalado automaacute-tico al alcanzar cierto liacutemite definido por el operador Eacutesta es a priori la formaen que deberiacutea implementarse hablando en teacuterminos de eficiencia sin embargoesta aproximacioacuten es totalmente dependiente de la plataforma es decir no sepuede extrapolar a otro proveedor o sobre recursos propios sin realizar un nue-vo disentildeo En este proyecto las tareas que son ejecutadas por estos equipos notienen estado ya que todo lo relativo a la persistencia lo hemos asignado fueradel cluster esto permite escalar la plataforma a traveacutes de otra aproximaciones
Las plantillas aceptan una serie de variables a indicar por el usuario entreotras los conjuntos de escala para definir los nodos aceptan una variable quedefine el nuacutemero de maacutequinas que los componen Por otro lado Azure ofreceuna API REST y kits de desarrollo software (SDK por sus siglas en ingleacutes) quepermiten su despliegue de forma programaacutetica Aprovechando estas facilidadesen este proyecto se va a aproximar la escalabilidad con el sucesivo desplieguede la infraestructura de forma automaacutetica se monitorizan los equipos y si sedetecta una maacutequina excesivamente cargada se aumenta el nuacutemero de equiposen la plantilla y se vuelve a desplegar
23httpsgithubcomAntonioAlfrzCloud-Orchestrators
43
En este proyecto se han disentildeado las plantillas para desplegar la arquitec-tura necesaria tanto de Nomad como de DCOS En el caso de la primera eldespliegue es maacutes descriptivo ya que incluye maacutequinas virtuales grupos de se-guridad redes En el caso de DCOS Azure cuenta con un servicio especiacuteficopara clusters gobernados por DCOS denominado Azure Container Service queincluye los componentes necesarios y la instalacioacuten ya realizada
72 Implementacioacuten
En primer lugar para monitorizar el estado de los equipos se va a usar laherramienta Nagios un sistema que permite controlar el estado del hardwarey los servicios de un equipo Se trata de una herramienta muy completa de laque se va a usar su capacidad para ejecutar comandos (plugins) en los nodospara detectar picos de carga generar alertas y ejecutar programas para estoseventos
Se ha desplegado una maacutequina virtual con esta herramienta en ambos siste-mas y se ha instalado una extensioacuten de Nagios (Nagios Remote Plugin Executor)en todos los nodos que permite ejecutar comprobaciones remotamente en con-creto para esta prueba de concepto medir el nivel de saturacioacuten de la unidadcentral de procesamiento (CPU por sus siglas del ingleacutes) Cuando sucede uncambio de estado de una maacutequina esto es cuando este paraacutemetro supera el liacutemi-te definido por el operador Nagios permite actuar en consecuencia ejecutandoprogramas por ello se ha desarrollado un script que ejecuta lo siguiente
Un programa desarrollado en Python con el SDK de Azure que modificalas plantillas y despliega los recursos
Un guioacuten de Ansible para instalar todos los componentes necesarios en lasnuevas maacutequinas y arrancar de nuevo el cluster y las aplicaciones
44
8 Resultados y conclusiones
En este uacuteltimo apartado se da una visioacuten global del proyecto asiacute como a lasconclusiones maacutes importantes a las que se ha llegado y posibles temas futurosde desarrollo
81 Comparacioacuten
Ambas herramientas ofrecen las funcionalidades para gestionar los recursoseficientemente ofreciendo a los desarrolladores una plataforma donde desplegarsus aplicaciones de forma distribuida independientemente de los equipos fiacutesicosy el hardware que las soporten
DCOS es una herramienta que en un comienzo fue privativa pero cuyos res-ponsables la empresa Mesosphere decidieron publicar una versioacuten de coacutedigoEacutesta nos permite gestionar un cluster de una forma sencilla y usable ademaacutes decomplementarlo con otras herramientas como el balanceador de carga integradoo la autenticacioacuten de usuarios ademaacutes estaacute basada en Apache Mesos un pro-yecto de relativa madurez y con el soporte de la Apache Software FoundationDe forma resumida DCOS ofrece muchas posibilidades y servicios a cambiode una arquitectura e instalacioacuten maacutes compleja
Por su parte HashiCorp con menor tiempo de desarrollo ha conseguidouna herramienta muy sencilla de desplegar que ademaacutes cumple con todas lasfuncionalidades baacutesicas ejecutando un simple binario en cada nodo se puededesplegar un gestor de clusters totalmente funcional Sin embargo no cuentacon todas las posibilidades de Mesos (Nomad cuenta con menos controladoresque entornos posibles de Mesos) ni con los antildeadidos de DCOS lo que implicael uso de otras herramientas para complementar el servicio (Consul HAProxy)
De entre las dificultades encontradas al usar estas herramientas y desplegaraplicaciones sobre ellas se puede destacar la depuracioacuten en ocasiones se desco-noce si un error viene de la propia herramienta de la aplicacioacuten desplegada o delequipo fiacutesico si no se cuenta con un sistema de procesamiento de registro unose puede encontrar con muacuteltiples terminales abiertas inspeccionando numerososficheros de registro buscando posibles errores Ademaacutes no dejan de ser solucio-nes que para usar eficientemente se debe conocer parte de su funcionamientoy sintaxis a la hora de describir la tareas lo que supone un esfuerzo antildeadido yaque cada una tiene sus particularidades y liacutemites
45
82 Conclusiones
En una sociedad cada vez maacutes digital las empresas deben adaptarse a unmercado cuya demanda de contenido no deja de crecer Las nuevas arquitecturascomo microservicios asiacute como la gran cantidad de datos generada implica queuna mejor gestioacuten de los recursos y la rapidez para desplegar o escalar solucionesdando valor al cliente lo maacutes raacutepido posible es uno de los objetivos de todas lasempresas de base tecnoloacutegica
Las ventajas que ofrecen los planificadores con aplicaciones distribuidas sonnumerosas sin ir maacutes lejos empresas tan punteras como Google llevan maacutesde 10 antildeos orquestando contenedores24 Por un lado permiten aumentar elrendimiento de los equipos propios y por otro implementar un servicio comoplataforma para despliegues distribuidos sobre cualquier conjunto hardware deesta forma se provee un servicio similar al de la nube puacuteblica pero con laprincipal diferencia de que se elimina la independencia con el proveedor (vendorlock-in) esto es las aplicaciones no tienen limitaciones impuestas por eacuteste talescomo lenguaje de programacioacuten o herramientas y permite despliegues hiacutebridosentre recursos propios y la nube
83 Objetivos conseguidos
Implementacioacuten de los planificadores propuestos en la nube Se ha en-tendido y detallado el funcionamiento de estas herramientas y se hanimplementado en el servicio de infraestructura de Microsoft Azure
Despliegue de aplicaciones y servicios distribuidos Servicios que se usanactualmente en la industria del desarrollo software asiacute como una aplica-cioacuten web con una arquitectura moderna han sido desplegados de formadistribuida en los equipos cumpliendo con la funcionalidad esperada ade-maacutes de consiguiendo una alta disponibilidad
Aproximacioacuten de arquitectura escalable Se ha hecho una aproximacioacutende infraestructura escalable de forma que sea parcialmente extrapolable aotros proveedores
24httpwwwnextplatformcom20160322decade-container-control-google
46
84 Liacuteneas de investigacioacuten
Siguiendo con la materia de este proyecto se presentan posibles liacuteneas deinvestigacioacuten
Analizar el despliegue con estas herramientas de aplicaciones de Big Datay comparar la eficiencia con respecto a soluciones especializadas
Analizar el rendimiento de los algoritmos de planificacioacuten antes pruebasde estreacutes y situaciones de alta contienda
Comparar el uso de estas herramientas con las praacutecticas actuales de laindustria o implementacioacuten en un sistema de produccioacuten real
47
Referencias
[1] LA Barroso y U Houmllzle laquoThe Datacenter as a Computer An Introduc-tion to the Design of Warehouse-Scale Machinesraquo En Morgan amp ClaypoolPublishers ()
[2] Systems Research Group ndash NetOS (University of Cambridge) The evolu-tion of cluster scheduler architectures 2016 url httpswwwclcamacukresearchsrgnetoscamsasblog2016-03-09-scheduler-architectureshtml
[3] A Das I Gupta y A Motivala SWIM Scalable Weakly-consistent Infection-style Process Group Membership Protocol Inf teacutec Dept of ComputerScience Cornell University url https www cs cornell edu ~asdasresearchdsn02-swimpdf
[4] D Dubhashi y A Das Mastering Mesos PACKT Publishing mayo de2016
[5] The Apache Software Foundation Apache Mesos documentation urlhttpsmesosapacheorg
[6] David Greenberg Building Applications on Mesos OrsquoReilly Media 2016[7] Armand Grillet Comparison of Container Schedulers Inf teacutec Technische
Universitaumlt Berlin[8] HashiCorp Consul documentation url httpswwwconsulio[9] HashiCorp Nomad documentation url httpsdcosio[10] Dan C Marinescu Cloud computing theory and practice Morgan Kauf-
mann 2013[11] Mesosphere DCOS documentation url httpswwwnomadproject
io[12] Microsoft Azure documentation url httpsazuremicrosoftcom
es-esdocumentation[13] D Ongaro y J Ousterhout In Search of an Understandable Consensus
Algorithm Inf teacutec Stanford University url httpsraftgithubioraftpdf
[14] Fei Teng laquoRessource allocation and schelduling models for cloud compu-tingraquo Tesis de mtriacutea Ecole Centrale Paris 2011
[15] A Williams y col Automation and Orchestration with Docker and Contai-ners A Comprehensive Overview of the Docker and Container Ecosystem3 The New Stack 2016
48
- Resumen
- Summary
- Iacutendice de figuras
- Introduccioacuten y objetivos
-
- Contexto
- Objetivos
- Estructura del documento
-
- Cloud Computing
- Nuevas cargas de trabajo
- Gestioacuten de recursos Planificadores
-
- Sistemas distribuidos
-
- Clasificacioacuten
-
- Herramientas
-
- DCOS
-
- Apache Mesos
- Ejemplos de uso
-
- Nomad
-
- Protocolo de consenso Raft
- Protocolo gossip SWIM
- Planificacioacuten
-
- Casos de uso y despliegue
-
- Aplicacioacuten Web
-
- DCOS
- Nomad
-
- Servicio de integracioacuten continua
-
- DevOps
- Integracioacuten Continua
- Jenkins con Nomad
- Jenkins con DCOS
-
- Escalando la infraestructura
-
- Disentildeo
- Implementacioacuten
-
- Resultados y conclusiones
-
- Comparacioacuten
- Conclusiones
- Objetivos conseguidos
- Liacuteneas de investigacioacuten
-
623 Jenkins con Nomad
El plugin permite la ejecucioacuten del fichero Java mediante dos controladorescontenedores Docker y Java En este proyecto nos hemos decantado por el pri-mero ya que nos ahorra instalar la maacutequina virtual de java en todos los nodoscliente Por ello se ha construido un contenedor base con Java para la ejecucioacutendel fichero de configuracioacuten y Nodejs para lanzar la aplicacioacuten web
El plugin se configura con la direccioacuten IP del cluster y el contenedor queejecuta el esclavo Jenkins Por su parte el trabajo en Jenkins se define conel repositorio en GitHub donde se aloja el coacutedigo del proyecto a probar y loscomandos a ejecutar en este caso npm update y npm test
624 Jenkins con DCOS
En el caso de DCOS su sistema de paquetes incluye Jenkins por lo queal instalarlo ya se tiene la configuracioacuten de Mesos totalmente funcional Sinembargo para ejecutar la aplicacioacuten en particular y las pruebas se requiere deNodejs en los equipos esclavos por ello debemos antildeadir un plugin de Jenkinsque permite instalar este entorno antes de ejecutar el trabajo Una vez hechoesto soacutelo queda definir la tarea igual que en el caso anterior
Cabe destacar que Mesosphere tambieacuten ha desarrollado un plugin que per-mite hacer despliegues en Marathon de tal manera que permitiriacutea con cadacommit del coacutedigo compilar la imagen del contenedor Docker y desplegarlaautomaacuteticamente aunque en este proyecto no se ha hecho pruebas de esta fun-cionalidad
42
7 Escalando la infraestructura
Uno de los factores clave que se busca a la hora de implementar sistemasdistribuidos es el poder escalar la infraestructura de forma maacutes sencilla estoes detectar que las maacutequinas estaacuten alcanzando el liacutemite de su capacidad yaumentar eacutesta ya sea mejorando sus caracteriacutesticas teacutecnicas o antildeadiendo maacutesnodos al cluster
El coacutedigo y todos los ficheros de configuracioacuten de esta seccioacuten tambieacuten sepueden encontrar en el repositorio del proyecto en GitHub23
71 Disentildeo
Microsoft Azure permite organizar los servicios cloud de forma loacutegica a traveacutesde grupos de recursos y asiacute poder crear o eliminar eacutestos en conjunto parauna aplicacioacuten determinada (por ejemplo una aplicacioacuten web suele requerir demaacutequinas virtuales bases de datos almacenamiento) Ademaacutes dispone dela opcioacuten de crear plantillas en formato JSON que permite al desarrolladordefinir los recursos y su interrelacioacuten para desplegar de forma automaacutetica unainfraestructura TI en la nube
Azure tambieacuten ofrece la posibilidad de monitorizar el estado de las maacutequinasvirtuales a traveacutes de extensiones lo que permite configurar el escalado automaacute-tico al alcanzar cierto liacutemite definido por el operador Eacutesta es a priori la formaen que deberiacutea implementarse hablando en teacuterminos de eficiencia sin embargoesta aproximacioacuten es totalmente dependiente de la plataforma es decir no sepuede extrapolar a otro proveedor o sobre recursos propios sin realizar un nue-vo disentildeo En este proyecto las tareas que son ejecutadas por estos equipos notienen estado ya que todo lo relativo a la persistencia lo hemos asignado fueradel cluster esto permite escalar la plataforma a traveacutes de otra aproximaciones
Las plantillas aceptan una serie de variables a indicar por el usuario entreotras los conjuntos de escala para definir los nodos aceptan una variable quedefine el nuacutemero de maacutequinas que los componen Por otro lado Azure ofreceuna API REST y kits de desarrollo software (SDK por sus siglas en ingleacutes) quepermiten su despliegue de forma programaacutetica Aprovechando estas facilidadesen este proyecto se va a aproximar la escalabilidad con el sucesivo desplieguede la infraestructura de forma automaacutetica se monitorizan los equipos y si sedetecta una maacutequina excesivamente cargada se aumenta el nuacutemero de equiposen la plantilla y se vuelve a desplegar
23httpsgithubcomAntonioAlfrzCloud-Orchestrators
43
En este proyecto se han disentildeado las plantillas para desplegar la arquitec-tura necesaria tanto de Nomad como de DCOS En el caso de la primera eldespliegue es maacutes descriptivo ya que incluye maacutequinas virtuales grupos de se-guridad redes En el caso de DCOS Azure cuenta con un servicio especiacuteficopara clusters gobernados por DCOS denominado Azure Container Service queincluye los componentes necesarios y la instalacioacuten ya realizada
72 Implementacioacuten
En primer lugar para monitorizar el estado de los equipos se va a usar laherramienta Nagios un sistema que permite controlar el estado del hardwarey los servicios de un equipo Se trata de una herramienta muy completa de laque se va a usar su capacidad para ejecutar comandos (plugins) en los nodospara detectar picos de carga generar alertas y ejecutar programas para estoseventos
Se ha desplegado una maacutequina virtual con esta herramienta en ambos siste-mas y se ha instalado una extensioacuten de Nagios (Nagios Remote Plugin Executor)en todos los nodos que permite ejecutar comprobaciones remotamente en con-creto para esta prueba de concepto medir el nivel de saturacioacuten de la unidadcentral de procesamiento (CPU por sus siglas del ingleacutes) Cuando sucede uncambio de estado de una maacutequina esto es cuando este paraacutemetro supera el liacutemi-te definido por el operador Nagios permite actuar en consecuencia ejecutandoprogramas por ello se ha desarrollado un script que ejecuta lo siguiente
Un programa desarrollado en Python con el SDK de Azure que modificalas plantillas y despliega los recursos
Un guioacuten de Ansible para instalar todos los componentes necesarios en lasnuevas maacutequinas y arrancar de nuevo el cluster y las aplicaciones
44
8 Resultados y conclusiones
En este uacuteltimo apartado se da una visioacuten global del proyecto asiacute como a lasconclusiones maacutes importantes a las que se ha llegado y posibles temas futurosde desarrollo
81 Comparacioacuten
Ambas herramientas ofrecen las funcionalidades para gestionar los recursoseficientemente ofreciendo a los desarrolladores una plataforma donde desplegarsus aplicaciones de forma distribuida independientemente de los equipos fiacutesicosy el hardware que las soporten
DCOS es una herramienta que en un comienzo fue privativa pero cuyos res-ponsables la empresa Mesosphere decidieron publicar una versioacuten de coacutedigoEacutesta nos permite gestionar un cluster de una forma sencilla y usable ademaacutes decomplementarlo con otras herramientas como el balanceador de carga integradoo la autenticacioacuten de usuarios ademaacutes estaacute basada en Apache Mesos un pro-yecto de relativa madurez y con el soporte de la Apache Software FoundationDe forma resumida DCOS ofrece muchas posibilidades y servicios a cambiode una arquitectura e instalacioacuten maacutes compleja
Por su parte HashiCorp con menor tiempo de desarrollo ha conseguidouna herramienta muy sencilla de desplegar que ademaacutes cumple con todas lasfuncionalidades baacutesicas ejecutando un simple binario en cada nodo se puededesplegar un gestor de clusters totalmente funcional Sin embargo no cuentacon todas las posibilidades de Mesos (Nomad cuenta con menos controladoresque entornos posibles de Mesos) ni con los antildeadidos de DCOS lo que implicael uso de otras herramientas para complementar el servicio (Consul HAProxy)
De entre las dificultades encontradas al usar estas herramientas y desplegaraplicaciones sobre ellas se puede destacar la depuracioacuten en ocasiones se desco-noce si un error viene de la propia herramienta de la aplicacioacuten desplegada o delequipo fiacutesico si no se cuenta con un sistema de procesamiento de registro unose puede encontrar con muacuteltiples terminales abiertas inspeccionando numerososficheros de registro buscando posibles errores Ademaacutes no dejan de ser solucio-nes que para usar eficientemente se debe conocer parte de su funcionamientoy sintaxis a la hora de describir la tareas lo que supone un esfuerzo antildeadido yaque cada una tiene sus particularidades y liacutemites
45
82 Conclusiones
En una sociedad cada vez maacutes digital las empresas deben adaptarse a unmercado cuya demanda de contenido no deja de crecer Las nuevas arquitecturascomo microservicios asiacute como la gran cantidad de datos generada implica queuna mejor gestioacuten de los recursos y la rapidez para desplegar o escalar solucionesdando valor al cliente lo maacutes raacutepido posible es uno de los objetivos de todas lasempresas de base tecnoloacutegica
Las ventajas que ofrecen los planificadores con aplicaciones distribuidas sonnumerosas sin ir maacutes lejos empresas tan punteras como Google llevan maacutesde 10 antildeos orquestando contenedores24 Por un lado permiten aumentar elrendimiento de los equipos propios y por otro implementar un servicio comoplataforma para despliegues distribuidos sobre cualquier conjunto hardware deesta forma se provee un servicio similar al de la nube puacuteblica pero con laprincipal diferencia de que se elimina la independencia con el proveedor (vendorlock-in) esto es las aplicaciones no tienen limitaciones impuestas por eacuteste talescomo lenguaje de programacioacuten o herramientas y permite despliegues hiacutebridosentre recursos propios y la nube
83 Objetivos conseguidos
Implementacioacuten de los planificadores propuestos en la nube Se ha en-tendido y detallado el funcionamiento de estas herramientas y se hanimplementado en el servicio de infraestructura de Microsoft Azure
Despliegue de aplicaciones y servicios distribuidos Servicios que se usanactualmente en la industria del desarrollo software asiacute como una aplica-cioacuten web con una arquitectura moderna han sido desplegados de formadistribuida en los equipos cumpliendo con la funcionalidad esperada ade-maacutes de consiguiendo una alta disponibilidad
Aproximacioacuten de arquitectura escalable Se ha hecho una aproximacioacutende infraestructura escalable de forma que sea parcialmente extrapolable aotros proveedores
24httpwwwnextplatformcom20160322decade-container-control-google
46
84 Liacuteneas de investigacioacuten
Siguiendo con la materia de este proyecto se presentan posibles liacuteneas deinvestigacioacuten
Analizar el despliegue con estas herramientas de aplicaciones de Big Datay comparar la eficiencia con respecto a soluciones especializadas
Analizar el rendimiento de los algoritmos de planificacioacuten antes pruebasde estreacutes y situaciones de alta contienda
Comparar el uso de estas herramientas con las praacutecticas actuales de laindustria o implementacioacuten en un sistema de produccioacuten real
47
Referencias
[1] LA Barroso y U Houmllzle laquoThe Datacenter as a Computer An Introduc-tion to the Design of Warehouse-Scale Machinesraquo En Morgan amp ClaypoolPublishers ()
[2] Systems Research Group ndash NetOS (University of Cambridge) The evolu-tion of cluster scheduler architectures 2016 url httpswwwclcamacukresearchsrgnetoscamsasblog2016-03-09-scheduler-architectureshtml
[3] A Das I Gupta y A Motivala SWIM Scalable Weakly-consistent Infection-style Process Group Membership Protocol Inf teacutec Dept of ComputerScience Cornell University url https www cs cornell edu ~asdasresearchdsn02-swimpdf
[4] D Dubhashi y A Das Mastering Mesos PACKT Publishing mayo de2016
[5] The Apache Software Foundation Apache Mesos documentation urlhttpsmesosapacheorg
[6] David Greenberg Building Applications on Mesos OrsquoReilly Media 2016[7] Armand Grillet Comparison of Container Schedulers Inf teacutec Technische
Universitaumlt Berlin[8] HashiCorp Consul documentation url httpswwwconsulio[9] HashiCorp Nomad documentation url httpsdcosio[10] Dan C Marinescu Cloud computing theory and practice Morgan Kauf-
mann 2013[11] Mesosphere DCOS documentation url httpswwwnomadproject
io[12] Microsoft Azure documentation url httpsazuremicrosoftcom
es-esdocumentation[13] D Ongaro y J Ousterhout In Search of an Understandable Consensus
Algorithm Inf teacutec Stanford University url httpsraftgithubioraftpdf
[14] Fei Teng laquoRessource allocation and schelduling models for cloud compu-tingraquo Tesis de mtriacutea Ecole Centrale Paris 2011
[15] A Williams y col Automation and Orchestration with Docker and Contai-ners A Comprehensive Overview of the Docker and Container Ecosystem3 The New Stack 2016
48
- Resumen
- Summary
- Iacutendice de figuras
- Introduccioacuten y objetivos
-
- Contexto
- Objetivos
- Estructura del documento
-
- Cloud Computing
- Nuevas cargas de trabajo
- Gestioacuten de recursos Planificadores
-
- Sistemas distribuidos
-
- Clasificacioacuten
-
- Herramientas
-
- DCOS
-
- Apache Mesos
- Ejemplos de uso
-
- Nomad
-
- Protocolo de consenso Raft
- Protocolo gossip SWIM
- Planificacioacuten
-
- Casos de uso y despliegue
-
- Aplicacioacuten Web
-
- DCOS
- Nomad
-
- Servicio de integracioacuten continua
-
- DevOps
- Integracioacuten Continua
- Jenkins con Nomad
- Jenkins con DCOS
-
- Escalando la infraestructura
-
- Disentildeo
- Implementacioacuten
-
- Resultados y conclusiones
-
- Comparacioacuten
- Conclusiones
- Objetivos conseguidos
- Liacuteneas de investigacioacuten
-
7 Escalando la infraestructura
Uno de los factores clave que se busca a la hora de implementar sistemasdistribuidos es el poder escalar la infraestructura de forma maacutes sencilla estoes detectar que las maacutequinas estaacuten alcanzando el liacutemite de su capacidad yaumentar eacutesta ya sea mejorando sus caracteriacutesticas teacutecnicas o antildeadiendo maacutesnodos al cluster
El coacutedigo y todos los ficheros de configuracioacuten de esta seccioacuten tambieacuten sepueden encontrar en el repositorio del proyecto en GitHub23
71 Disentildeo
Microsoft Azure permite organizar los servicios cloud de forma loacutegica a traveacutesde grupos de recursos y asiacute poder crear o eliminar eacutestos en conjunto parauna aplicacioacuten determinada (por ejemplo una aplicacioacuten web suele requerir demaacutequinas virtuales bases de datos almacenamiento) Ademaacutes dispone dela opcioacuten de crear plantillas en formato JSON que permite al desarrolladordefinir los recursos y su interrelacioacuten para desplegar de forma automaacutetica unainfraestructura TI en la nube
Azure tambieacuten ofrece la posibilidad de monitorizar el estado de las maacutequinasvirtuales a traveacutes de extensiones lo que permite configurar el escalado automaacute-tico al alcanzar cierto liacutemite definido por el operador Eacutesta es a priori la formaen que deberiacutea implementarse hablando en teacuterminos de eficiencia sin embargoesta aproximacioacuten es totalmente dependiente de la plataforma es decir no sepuede extrapolar a otro proveedor o sobre recursos propios sin realizar un nue-vo disentildeo En este proyecto las tareas que son ejecutadas por estos equipos notienen estado ya que todo lo relativo a la persistencia lo hemos asignado fueradel cluster esto permite escalar la plataforma a traveacutes de otra aproximaciones
Las plantillas aceptan una serie de variables a indicar por el usuario entreotras los conjuntos de escala para definir los nodos aceptan una variable quedefine el nuacutemero de maacutequinas que los componen Por otro lado Azure ofreceuna API REST y kits de desarrollo software (SDK por sus siglas en ingleacutes) quepermiten su despliegue de forma programaacutetica Aprovechando estas facilidadesen este proyecto se va a aproximar la escalabilidad con el sucesivo desplieguede la infraestructura de forma automaacutetica se monitorizan los equipos y si sedetecta una maacutequina excesivamente cargada se aumenta el nuacutemero de equiposen la plantilla y se vuelve a desplegar
23httpsgithubcomAntonioAlfrzCloud-Orchestrators
43
En este proyecto se han disentildeado las plantillas para desplegar la arquitec-tura necesaria tanto de Nomad como de DCOS En el caso de la primera eldespliegue es maacutes descriptivo ya que incluye maacutequinas virtuales grupos de se-guridad redes En el caso de DCOS Azure cuenta con un servicio especiacuteficopara clusters gobernados por DCOS denominado Azure Container Service queincluye los componentes necesarios y la instalacioacuten ya realizada
72 Implementacioacuten
En primer lugar para monitorizar el estado de los equipos se va a usar laherramienta Nagios un sistema que permite controlar el estado del hardwarey los servicios de un equipo Se trata de una herramienta muy completa de laque se va a usar su capacidad para ejecutar comandos (plugins) en los nodospara detectar picos de carga generar alertas y ejecutar programas para estoseventos
Se ha desplegado una maacutequina virtual con esta herramienta en ambos siste-mas y se ha instalado una extensioacuten de Nagios (Nagios Remote Plugin Executor)en todos los nodos que permite ejecutar comprobaciones remotamente en con-creto para esta prueba de concepto medir el nivel de saturacioacuten de la unidadcentral de procesamiento (CPU por sus siglas del ingleacutes) Cuando sucede uncambio de estado de una maacutequina esto es cuando este paraacutemetro supera el liacutemi-te definido por el operador Nagios permite actuar en consecuencia ejecutandoprogramas por ello se ha desarrollado un script que ejecuta lo siguiente
Un programa desarrollado en Python con el SDK de Azure que modificalas plantillas y despliega los recursos
Un guioacuten de Ansible para instalar todos los componentes necesarios en lasnuevas maacutequinas y arrancar de nuevo el cluster y las aplicaciones
44
8 Resultados y conclusiones
En este uacuteltimo apartado se da una visioacuten global del proyecto asiacute como a lasconclusiones maacutes importantes a las que se ha llegado y posibles temas futurosde desarrollo
81 Comparacioacuten
Ambas herramientas ofrecen las funcionalidades para gestionar los recursoseficientemente ofreciendo a los desarrolladores una plataforma donde desplegarsus aplicaciones de forma distribuida independientemente de los equipos fiacutesicosy el hardware que las soporten
DCOS es una herramienta que en un comienzo fue privativa pero cuyos res-ponsables la empresa Mesosphere decidieron publicar una versioacuten de coacutedigoEacutesta nos permite gestionar un cluster de una forma sencilla y usable ademaacutes decomplementarlo con otras herramientas como el balanceador de carga integradoo la autenticacioacuten de usuarios ademaacutes estaacute basada en Apache Mesos un pro-yecto de relativa madurez y con el soporte de la Apache Software FoundationDe forma resumida DCOS ofrece muchas posibilidades y servicios a cambiode una arquitectura e instalacioacuten maacutes compleja
Por su parte HashiCorp con menor tiempo de desarrollo ha conseguidouna herramienta muy sencilla de desplegar que ademaacutes cumple con todas lasfuncionalidades baacutesicas ejecutando un simple binario en cada nodo se puededesplegar un gestor de clusters totalmente funcional Sin embargo no cuentacon todas las posibilidades de Mesos (Nomad cuenta con menos controladoresque entornos posibles de Mesos) ni con los antildeadidos de DCOS lo que implicael uso de otras herramientas para complementar el servicio (Consul HAProxy)
De entre las dificultades encontradas al usar estas herramientas y desplegaraplicaciones sobre ellas se puede destacar la depuracioacuten en ocasiones se desco-noce si un error viene de la propia herramienta de la aplicacioacuten desplegada o delequipo fiacutesico si no se cuenta con un sistema de procesamiento de registro unose puede encontrar con muacuteltiples terminales abiertas inspeccionando numerososficheros de registro buscando posibles errores Ademaacutes no dejan de ser solucio-nes que para usar eficientemente se debe conocer parte de su funcionamientoy sintaxis a la hora de describir la tareas lo que supone un esfuerzo antildeadido yaque cada una tiene sus particularidades y liacutemites
45
82 Conclusiones
En una sociedad cada vez maacutes digital las empresas deben adaptarse a unmercado cuya demanda de contenido no deja de crecer Las nuevas arquitecturascomo microservicios asiacute como la gran cantidad de datos generada implica queuna mejor gestioacuten de los recursos y la rapidez para desplegar o escalar solucionesdando valor al cliente lo maacutes raacutepido posible es uno de los objetivos de todas lasempresas de base tecnoloacutegica
Las ventajas que ofrecen los planificadores con aplicaciones distribuidas sonnumerosas sin ir maacutes lejos empresas tan punteras como Google llevan maacutesde 10 antildeos orquestando contenedores24 Por un lado permiten aumentar elrendimiento de los equipos propios y por otro implementar un servicio comoplataforma para despliegues distribuidos sobre cualquier conjunto hardware deesta forma se provee un servicio similar al de la nube puacuteblica pero con laprincipal diferencia de que se elimina la independencia con el proveedor (vendorlock-in) esto es las aplicaciones no tienen limitaciones impuestas por eacuteste talescomo lenguaje de programacioacuten o herramientas y permite despliegues hiacutebridosentre recursos propios y la nube
83 Objetivos conseguidos
Implementacioacuten de los planificadores propuestos en la nube Se ha en-tendido y detallado el funcionamiento de estas herramientas y se hanimplementado en el servicio de infraestructura de Microsoft Azure
Despliegue de aplicaciones y servicios distribuidos Servicios que se usanactualmente en la industria del desarrollo software asiacute como una aplica-cioacuten web con una arquitectura moderna han sido desplegados de formadistribuida en los equipos cumpliendo con la funcionalidad esperada ade-maacutes de consiguiendo una alta disponibilidad
Aproximacioacuten de arquitectura escalable Se ha hecho una aproximacioacutende infraestructura escalable de forma que sea parcialmente extrapolable aotros proveedores
24httpwwwnextplatformcom20160322decade-container-control-google
46
84 Liacuteneas de investigacioacuten
Siguiendo con la materia de este proyecto se presentan posibles liacuteneas deinvestigacioacuten
Analizar el despliegue con estas herramientas de aplicaciones de Big Datay comparar la eficiencia con respecto a soluciones especializadas
Analizar el rendimiento de los algoritmos de planificacioacuten antes pruebasde estreacutes y situaciones de alta contienda
Comparar el uso de estas herramientas con las praacutecticas actuales de laindustria o implementacioacuten en un sistema de produccioacuten real
47
Referencias
[1] LA Barroso y U Houmllzle laquoThe Datacenter as a Computer An Introduc-tion to the Design of Warehouse-Scale Machinesraquo En Morgan amp ClaypoolPublishers ()
[2] Systems Research Group ndash NetOS (University of Cambridge) The evolu-tion of cluster scheduler architectures 2016 url httpswwwclcamacukresearchsrgnetoscamsasblog2016-03-09-scheduler-architectureshtml
[3] A Das I Gupta y A Motivala SWIM Scalable Weakly-consistent Infection-style Process Group Membership Protocol Inf teacutec Dept of ComputerScience Cornell University url https www cs cornell edu ~asdasresearchdsn02-swimpdf
[4] D Dubhashi y A Das Mastering Mesos PACKT Publishing mayo de2016
[5] The Apache Software Foundation Apache Mesos documentation urlhttpsmesosapacheorg
[6] David Greenberg Building Applications on Mesos OrsquoReilly Media 2016[7] Armand Grillet Comparison of Container Schedulers Inf teacutec Technische
Universitaumlt Berlin[8] HashiCorp Consul documentation url httpswwwconsulio[9] HashiCorp Nomad documentation url httpsdcosio[10] Dan C Marinescu Cloud computing theory and practice Morgan Kauf-
mann 2013[11] Mesosphere DCOS documentation url httpswwwnomadproject
io[12] Microsoft Azure documentation url httpsazuremicrosoftcom
es-esdocumentation[13] D Ongaro y J Ousterhout In Search of an Understandable Consensus
Algorithm Inf teacutec Stanford University url httpsraftgithubioraftpdf
[14] Fei Teng laquoRessource allocation and schelduling models for cloud compu-tingraquo Tesis de mtriacutea Ecole Centrale Paris 2011
[15] A Williams y col Automation and Orchestration with Docker and Contai-ners A Comprehensive Overview of the Docker and Container Ecosystem3 The New Stack 2016
48
- Resumen
- Summary
- Iacutendice de figuras
- Introduccioacuten y objetivos
-
- Contexto
- Objetivos
- Estructura del documento
-
- Cloud Computing
- Nuevas cargas de trabajo
- Gestioacuten de recursos Planificadores
-
- Sistemas distribuidos
-
- Clasificacioacuten
-
- Herramientas
-
- DCOS
-
- Apache Mesos
- Ejemplos de uso
-
- Nomad
-
- Protocolo de consenso Raft
- Protocolo gossip SWIM
- Planificacioacuten
-
- Casos de uso y despliegue
-
- Aplicacioacuten Web
-
- DCOS
- Nomad
-
- Servicio de integracioacuten continua
-
- DevOps
- Integracioacuten Continua
- Jenkins con Nomad
- Jenkins con DCOS
-
- Escalando la infraestructura
-
- Disentildeo
- Implementacioacuten
-
- Resultados y conclusiones
-
- Comparacioacuten
- Conclusiones
- Objetivos conseguidos
- Liacuteneas de investigacioacuten
-
En este proyecto se han disentildeado las plantillas para desplegar la arquitec-tura necesaria tanto de Nomad como de DCOS En el caso de la primera eldespliegue es maacutes descriptivo ya que incluye maacutequinas virtuales grupos de se-guridad redes En el caso de DCOS Azure cuenta con un servicio especiacuteficopara clusters gobernados por DCOS denominado Azure Container Service queincluye los componentes necesarios y la instalacioacuten ya realizada
72 Implementacioacuten
En primer lugar para monitorizar el estado de los equipos se va a usar laherramienta Nagios un sistema que permite controlar el estado del hardwarey los servicios de un equipo Se trata de una herramienta muy completa de laque se va a usar su capacidad para ejecutar comandos (plugins) en los nodospara detectar picos de carga generar alertas y ejecutar programas para estoseventos
Se ha desplegado una maacutequina virtual con esta herramienta en ambos siste-mas y se ha instalado una extensioacuten de Nagios (Nagios Remote Plugin Executor)en todos los nodos que permite ejecutar comprobaciones remotamente en con-creto para esta prueba de concepto medir el nivel de saturacioacuten de la unidadcentral de procesamiento (CPU por sus siglas del ingleacutes) Cuando sucede uncambio de estado de una maacutequina esto es cuando este paraacutemetro supera el liacutemi-te definido por el operador Nagios permite actuar en consecuencia ejecutandoprogramas por ello se ha desarrollado un script que ejecuta lo siguiente
Un programa desarrollado en Python con el SDK de Azure que modificalas plantillas y despliega los recursos
Un guioacuten de Ansible para instalar todos los componentes necesarios en lasnuevas maacutequinas y arrancar de nuevo el cluster y las aplicaciones
44
8 Resultados y conclusiones
En este uacuteltimo apartado se da una visioacuten global del proyecto asiacute como a lasconclusiones maacutes importantes a las que se ha llegado y posibles temas futurosde desarrollo
81 Comparacioacuten
Ambas herramientas ofrecen las funcionalidades para gestionar los recursoseficientemente ofreciendo a los desarrolladores una plataforma donde desplegarsus aplicaciones de forma distribuida independientemente de los equipos fiacutesicosy el hardware que las soporten
DCOS es una herramienta que en un comienzo fue privativa pero cuyos res-ponsables la empresa Mesosphere decidieron publicar una versioacuten de coacutedigoEacutesta nos permite gestionar un cluster de una forma sencilla y usable ademaacutes decomplementarlo con otras herramientas como el balanceador de carga integradoo la autenticacioacuten de usuarios ademaacutes estaacute basada en Apache Mesos un pro-yecto de relativa madurez y con el soporte de la Apache Software FoundationDe forma resumida DCOS ofrece muchas posibilidades y servicios a cambiode una arquitectura e instalacioacuten maacutes compleja
Por su parte HashiCorp con menor tiempo de desarrollo ha conseguidouna herramienta muy sencilla de desplegar que ademaacutes cumple con todas lasfuncionalidades baacutesicas ejecutando un simple binario en cada nodo se puededesplegar un gestor de clusters totalmente funcional Sin embargo no cuentacon todas las posibilidades de Mesos (Nomad cuenta con menos controladoresque entornos posibles de Mesos) ni con los antildeadidos de DCOS lo que implicael uso de otras herramientas para complementar el servicio (Consul HAProxy)
De entre las dificultades encontradas al usar estas herramientas y desplegaraplicaciones sobre ellas se puede destacar la depuracioacuten en ocasiones se desco-noce si un error viene de la propia herramienta de la aplicacioacuten desplegada o delequipo fiacutesico si no se cuenta con un sistema de procesamiento de registro unose puede encontrar con muacuteltiples terminales abiertas inspeccionando numerososficheros de registro buscando posibles errores Ademaacutes no dejan de ser solucio-nes que para usar eficientemente se debe conocer parte de su funcionamientoy sintaxis a la hora de describir la tareas lo que supone un esfuerzo antildeadido yaque cada una tiene sus particularidades y liacutemites
45
82 Conclusiones
En una sociedad cada vez maacutes digital las empresas deben adaptarse a unmercado cuya demanda de contenido no deja de crecer Las nuevas arquitecturascomo microservicios asiacute como la gran cantidad de datos generada implica queuna mejor gestioacuten de los recursos y la rapidez para desplegar o escalar solucionesdando valor al cliente lo maacutes raacutepido posible es uno de los objetivos de todas lasempresas de base tecnoloacutegica
Las ventajas que ofrecen los planificadores con aplicaciones distribuidas sonnumerosas sin ir maacutes lejos empresas tan punteras como Google llevan maacutesde 10 antildeos orquestando contenedores24 Por un lado permiten aumentar elrendimiento de los equipos propios y por otro implementar un servicio comoplataforma para despliegues distribuidos sobre cualquier conjunto hardware deesta forma se provee un servicio similar al de la nube puacuteblica pero con laprincipal diferencia de que se elimina la independencia con el proveedor (vendorlock-in) esto es las aplicaciones no tienen limitaciones impuestas por eacuteste talescomo lenguaje de programacioacuten o herramientas y permite despliegues hiacutebridosentre recursos propios y la nube
83 Objetivos conseguidos
Implementacioacuten de los planificadores propuestos en la nube Se ha en-tendido y detallado el funcionamiento de estas herramientas y se hanimplementado en el servicio de infraestructura de Microsoft Azure
Despliegue de aplicaciones y servicios distribuidos Servicios que se usanactualmente en la industria del desarrollo software asiacute como una aplica-cioacuten web con una arquitectura moderna han sido desplegados de formadistribuida en los equipos cumpliendo con la funcionalidad esperada ade-maacutes de consiguiendo una alta disponibilidad
Aproximacioacuten de arquitectura escalable Se ha hecho una aproximacioacutende infraestructura escalable de forma que sea parcialmente extrapolable aotros proveedores
24httpwwwnextplatformcom20160322decade-container-control-google
46
84 Liacuteneas de investigacioacuten
Siguiendo con la materia de este proyecto se presentan posibles liacuteneas deinvestigacioacuten
Analizar el despliegue con estas herramientas de aplicaciones de Big Datay comparar la eficiencia con respecto a soluciones especializadas
Analizar el rendimiento de los algoritmos de planificacioacuten antes pruebasde estreacutes y situaciones de alta contienda
Comparar el uso de estas herramientas con las praacutecticas actuales de laindustria o implementacioacuten en un sistema de produccioacuten real
47
Referencias
[1] LA Barroso y U Houmllzle laquoThe Datacenter as a Computer An Introduc-tion to the Design of Warehouse-Scale Machinesraquo En Morgan amp ClaypoolPublishers ()
[2] Systems Research Group ndash NetOS (University of Cambridge) The evolu-tion of cluster scheduler architectures 2016 url httpswwwclcamacukresearchsrgnetoscamsasblog2016-03-09-scheduler-architectureshtml
[3] A Das I Gupta y A Motivala SWIM Scalable Weakly-consistent Infection-style Process Group Membership Protocol Inf teacutec Dept of ComputerScience Cornell University url https www cs cornell edu ~asdasresearchdsn02-swimpdf
[4] D Dubhashi y A Das Mastering Mesos PACKT Publishing mayo de2016
[5] The Apache Software Foundation Apache Mesos documentation urlhttpsmesosapacheorg
[6] David Greenberg Building Applications on Mesos OrsquoReilly Media 2016[7] Armand Grillet Comparison of Container Schedulers Inf teacutec Technische
Universitaumlt Berlin[8] HashiCorp Consul documentation url httpswwwconsulio[9] HashiCorp Nomad documentation url httpsdcosio[10] Dan C Marinescu Cloud computing theory and practice Morgan Kauf-
mann 2013[11] Mesosphere DCOS documentation url httpswwwnomadproject
io[12] Microsoft Azure documentation url httpsazuremicrosoftcom
es-esdocumentation[13] D Ongaro y J Ousterhout In Search of an Understandable Consensus
Algorithm Inf teacutec Stanford University url httpsraftgithubioraftpdf
[14] Fei Teng laquoRessource allocation and schelduling models for cloud compu-tingraquo Tesis de mtriacutea Ecole Centrale Paris 2011
[15] A Williams y col Automation and Orchestration with Docker and Contai-ners A Comprehensive Overview of the Docker and Container Ecosystem3 The New Stack 2016
48
- Resumen
- Summary
- Iacutendice de figuras
- Introduccioacuten y objetivos
-
- Contexto
- Objetivos
- Estructura del documento
-
- Cloud Computing
- Nuevas cargas de trabajo
- Gestioacuten de recursos Planificadores
-
- Sistemas distribuidos
-
- Clasificacioacuten
-
- Herramientas
-
- DCOS
-
- Apache Mesos
- Ejemplos de uso
-
- Nomad
-
- Protocolo de consenso Raft
- Protocolo gossip SWIM
- Planificacioacuten
-
- Casos de uso y despliegue
-
- Aplicacioacuten Web
-
- DCOS
- Nomad
-
- Servicio de integracioacuten continua
-
- DevOps
- Integracioacuten Continua
- Jenkins con Nomad
- Jenkins con DCOS
-
- Escalando la infraestructura
-
- Disentildeo
- Implementacioacuten
-
- Resultados y conclusiones
-
- Comparacioacuten
- Conclusiones
- Objetivos conseguidos
- Liacuteneas de investigacioacuten
-
8 Resultados y conclusiones
En este uacuteltimo apartado se da una visioacuten global del proyecto asiacute como a lasconclusiones maacutes importantes a las que se ha llegado y posibles temas futurosde desarrollo
81 Comparacioacuten
Ambas herramientas ofrecen las funcionalidades para gestionar los recursoseficientemente ofreciendo a los desarrolladores una plataforma donde desplegarsus aplicaciones de forma distribuida independientemente de los equipos fiacutesicosy el hardware que las soporten
DCOS es una herramienta que en un comienzo fue privativa pero cuyos res-ponsables la empresa Mesosphere decidieron publicar una versioacuten de coacutedigoEacutesta nos permite gestionar un cluster de una forma sencilla y usable ademaacutes decomplementarlo con otras herramientas como el balanceador de carga integradoo la autenticacioacuten de usuarios ademaacutes estaacute basada en Apache Mesos un pro-yecto de relativa madurez y con el soporte de la Apache Software FoundationDe forma resumida DCOS ofrece muchas posibilidades y servicios a cambiode una arquitectura e instalacioacuten maacutes compleja
Por su parte HashiCorp con menor tiempo de desarrollo ha conseguidouna herramienta muy sencilla de desplegar que ademaacutes cumple con todas lasfuncionalidades baacutesicas ejecutando un simple binario en cada nodo se puededesplegar un gestor de clusters totalmente funcional Sin embargo no cuentacon todas las posibilidades de Mesos (Nomad cuenta con menos controladoresque entornos posibles de Mesos) ni con los antildeadidos de DCOS lo que implicael uso de otras herramientas para complementar el servicio (Consul HAProxy)
De entre las dificultades encontradas al usar estas herramientas y desplegaraplicaciones sobre ellas se puede destacar la depuracioacuten en ocasiones se desco-noce si un error viene de la propia herramienta de la aplicacioacuten desplegada o delequipo fiacutesico si no se cuenta con un sistema de procesamiento de registro unose puede encontrar con muacuteltiples terminales abiertas inspeccionando numerososficheros de registro buscando posibles errores Ademaacutes no dejan de ser solucio-nes que para usar eficientemente se debe conocer parte de su funcionamientoy sintaxis a la hora de describir la tareas lo que supone un esfuerzo antildeadido yaque cada una tiene sus particularidades y liacutemites
45
82 Conclusiones
En una sociedad cada vez maacutes digital las empresas deben adaptarse a unmercado cuya demanda de contenido no deja de crecer Las nuevas arquitecturascomo microservicios asiacute como la gran cantidad de datos generada implica queuna mejor gestioacuten de los recursos y la rapidez para desplegar o escalar solucionesdando valor al cliente lo maacutes raacutepido posible es uno de los objetivos de todas lasempresas de base tecnoloacutegica
Las ventajas que ofrecen los planificadores con aplicaciones distribuidas sonnumerosas sin ir maacutes lejos empresas tan punteras como Google llevan maacutesde 10 antildeos orquestando contenedores24 Por un lado permiten aumentar elrendimiento de los equipos propios y por otro implementar un servicio comoplataforma para despliegues distribuidos sobre cualquier conjunto hardware deesta forma se provee un servicio similar al de la nube puacuteblica pero con laprincipal diferencia de que se elimina la independencia con el proveedor (vendorlock-in) esto es las aplicaciones no tienen limitaciones impuestas por eacuteste talescomo lenguaje de programacioacuten o herramientas y permite despliegues hiacutebridosentre recursos propios y la nube
83 Objetivos conseguidos
Implementacioacuten de los planificadores propuestos en la nube Se ha en-tendido y detallado el funcionamiento de estas herramientas y se hanimplementado en el servicio de infraestructura de Microsoft Azure
Despliegue de aplicaciones y servicios distribuidos Servicios que se usanactualmente en la industria del desarrollo software asiacute como una aplica-cioacuten web con una arquitectura moderna han sido desplegados de formadistribuida en los equipos cumpliendo con la funcionalidad esperada ade-maacutes de consiguiendo una alta disponibilidad
Aproximacioacuten de arquitectura escalable Se ha hecho una aproximacioacutende infraestructura escalable de forma que sea parcialmente extrapolable aotros proveedores
24httpwwwnextplatformcom20160322decade-container-control-google
46
84 Liacuteneas de investigacioacuten
Siguiendo con la materia de este proyecto se presentan posibles liacuteneas deinvestigacioacuten
Analizar el despliegue con estas herramientas de aplicaciones de Big Datay comparar la eficiencia con respecto a soluciones especializadas
Analizar el rendimiento de los algoritmos de planificacioacuten antes pruebasde estreacutes y situaciones de alta contienda
Comparar el uso de estas herramientas con las praacutecticas actuales de laindustria o implementacioacuten en un sistema de produccioacuten real
47
Referencias
[1] LA Barroso y U Houmllzle laquoThe Datacenter as a Computer An Introduc-tion to the Design of Warehouse-Scale Machinesraquo En Morgan amp ClaypoolPublishers ()
[2] Systems Research Group ndash NetOS (University of Cambridge) The evolu-tion of cluster scheduler architectures 2016 url httpswwwclcamacukresearchsrgnetoscamsasblog2016-03-09-scheduler-architectureshtml
[3] A Das I Gupta y A Motivala SWIM Scalable Weakly-consistent Infection-style Process Group Membership Protocol Inf teacutec Dept of ComputerScience Cornell University url https www cs cornell edu ~asdasresearchdsn02-swimpdf
[4] D Dubhashi y A Das Mastering Mesos PACKT Publishing mayo de2016
[5] The Apache Software Foundation Apache Mesos documentation urlhttpsmesosapacheorg
[6] David Greenberg Building Applications on Mesos OrsquoReilly Media 2016[7] Armand Grillet Comparison of Container Schedulers Inf teacutec Technische
Universitaumlt Berlin[8] HashiCorp Consul documentation url httpswwwconsulio[9] HashiCorp Nomad documentation url httpsdcosio[10] Dan C Marinescu Cloud computing theory and practice Morgan Kauf-
mann 2013[11] Mesosphere DCOS documentation url httpswwwnomadproject
io[12] Microsoft Azure documentation url httpsazuremicrosoftcom
es-esdocumentation[13] D Ongaro y J Ousterhout In Search of an Understandable Consensus
Algorithm Inf teacutec Stanford University url httpsraftgithubioraftpdf
[14] Fei Teng laquoRessource allocation and schelduling models for cloud compu-tingraquo Tesis de mtriacutea Ecole Centrale Paris 2011
[15] A Williams y col Automation and Orchestration with Docker and Contai-ners A Comprehensive Overview of the Docker and Container Ecosystem3 The New Stack 2016
48
- Resumen
- Summary
- Iacutendice de figuras
- Introduccioacuten y objetivos
-
- Contexto
- Objetivos
- Estructura del documento
-
- Cloud Computing
- Nuevas cargas de trabajo
- Gestioacuten de recursos Planificadores
-
- Sistemas distribuidos
-
- Clasificacioacuten
-
- Herramientas
-
- DCOS
-
- Apache Mesos
- Ejemplos de uso
-
- Nomad
-
- Protocolo de consenso Raft
- Protocolo gossip SWIM
- Planificacioacuten
-
- Casos de uso y despliegue
-
- Aplicacioacuten Web
-
- DCOS
- Nomad
-
- Servicio de integracioacuten continua
-
- DevOps
- Integracioacuten Continua
- Jenkins con Nomad
- Jenkins con DCOS
-
- Escalando la infraestructura
-
- Disentildeo
- Implementacioacuten
-
- Resultados y conclusiones
-
- Comparacioacuten
- Conclusiones
- Objetivos conseguidos
- Liacuteneas de investigacioacuten
-
82 Conclusiones
En una sociedad cada vez maacutes digital las empresas deben adaptarse a unmercado cuya demanda de contenido no deja de crecer Las nuevas arquitecturascomo microservicios asiacute como la gran cantidad de datos generada implica queuna mejor gestioacuten de los recursos y la rapidez para desplegar o escalar solucionesdando valor al cliente lo maacutes raacutepido posible es uno de los objetivos de todas lasempresas de base tecnoloacutegica
Las ventajas que ofrecen los planificadores con aplicaciones distribuidas sonnumerosas sin ir maacutes lejos empresas tan punteras como Google llevan maacutesde 10 antildeos orquestando contenedores24 Por un lado permiten aumentar elrendimiento de los equipos propios y por otro implementar un servicio comoplataforma para despliegues distribuidos sobre cualquier conjunto hardware deesta forma se provee un servicio similar al de la nube puacuteblica pero con laprincipal diferencia de que se elimina la independencia con el proveedor (vendorlock-in) esto es las aplicaciones no tienen limitaciones impuestas por eacuteste talescomo lenguaje de programacioacuten o herramientas y permite despliegues hiacutebridosentre recursos propios y la nube
83 Objetivos conseguidos
Implementacioacuten de los planificadores propuestos en la nube Se ha en-tendido y detallado el funcionamiento de estas herramientas y se hanimplementado en el servicio de infraestructura de Microsoft Azure
Despliegue de aplicaciones y servicios distribuidos Servicios que se usanactualmente en la industria del desarrollo software asiacute como una aplica-cioacuten web con una arquitectura moderna han sido desplegados de formadistribuida en los equipos cumpliendo con la funcionalidad esperada ade-maacutes de consiguiendo una alta disponibilidad
Aproximacioacuten de arquitectura escalable Se ha hecho una aproximacioacutende infraestructura escalable de forma que sea parcialmente extrapolable aotros proveedores
24httpwwwnextplatformcom20160322decade-container-control-google
46
84 Liacuteneas de investigacioacuten
Siguiendo con la materia de este proyecto se presentan posibles liacuteneas deinvestigacioacuten
Analizar el despliegue con estas herramientas de aplicaciones de Big Datay comparar la eficiencia con respecto a soluciones especializadas
Analizar el rendimiento de los algoritmos de planificacioacuten antes pruebasde estreacutes y situaciones de alta contienda
Comparar el uso de estas herramientas con las praacutecticas actuales de laindustria o implementacioacuten en un sistema de produccioacuten real
47
Referencias
[1] LA Barroso y U Houmllzle laquoThe Datacenter as a Computer An Introduc-tion to the Design of Warehouse-Scale Machinesraquo En Morgan amp ClaypoolPublishers ()
[2] Systems Research Group ndash NetOS (University of Cambridge) The evolu-tion of cluster scheduler architectures 2016 url httpswwwclcamacukresearchsrgnetoscamsasblog2016-03-09-scheduler-architectureshtml
[3] A Das I Gupta y A Motivala SWIM Scalable Weakly-consistent Infection-style Process Group Membership Protocol Inf teacutec Dept of ComputerScience Cornell University url https www cs cornell edu ~asdasresearchdsn02-swimpdf
[4] D Dubhashi y A Das Mastering Mesos PACKT Publishing mayo de2016
[5] The Apache Software Foundation Apache Mesos documentation urlhttpsmesosapacheorg
[6] David Greenberg Building Applications on Mesos OrsquoReilly Media 2016[7] Armand Grillet Comparison of Container Schedulers Inf teacutec Technische
Universitaumlt Berlin[8] HashiCorp Consul documentation url httpswwwconsulio[9] HashiCorp Nomad documentation url httpsdcosio[10] Dan C Marinescu Cloud computing theory and practice Morgan Kauf-
mann 2013[11] Mesosphere DCOS documentation url httpswwwnomadproject
io[12] Microsoft Azure documentation url httpsazuremicrosoftcom
es-esdocumentation[13] D Ongaro y J Ousterhout In Search of an Understandable Consensus
Algorithm Inf teacutec Stanford University url httpsraftgithubioraftpdf
[14] Fei Teng laquoRessource allocation and schelduling models for cloud compu-tingraquo Tesis de mtriacutea Ecole Centrale Paris 2011
[15] A Williams y col Automation and Orchestration with Docker and Contai-ners A Comprehensive Overview of the Docker and Container Ecosystem3 The New Stack 2016
48
- Resumen
- Summary
- Iacutendice de figuras
- Introduccioacuten y objetivos
-
- Contexto
- Objetivos
- Estructura del documento
-
- Cloud Computing
- Nuevas cargas de trabajo
- Gestioacuten de recursos Planificadores
-
- Sistemas distribuidos
-
- Clasificacioacuten
-
- Herramientas
-
- DCOS
-
- Apache Mesos
- Ejemplos de uso
-
- Nomad
-
- Protocolo de consenso Raft
- Protocolo gossip SWIM
- Planificacioacuten
-
- Casos de uso y despliegue
-
- Aplicacioacuten Web
-
- DCOS
- Nomad
-
- Servicio de integracioacuten continua
-
- DevOps
- Integracioacuten Continua
- Jenkins con Nomad
- Jenkins con DCOS
-
- Escalando la infraestructura
-
- Disentildeo
- Implementacioacuten
-
- Resultados y conclusiones
-
- Comparacioacuten
- Conclusiones
- Objetivos conseguidos
- Liacuteneas de investigacioacuten
-
84 Liacuteneas de investigacioacuten
Siguiendo con la materia de este proyecto se presentan posibles liacuteneas deinvestigacioacuten
Analizar el despliegue con estas herramientas de aplicaciones de Big Datay comparar la eficiencia con respecto a soluciones especializadas
Analizar el rendimiento de los algoritmos de planificacioacuten antes pruebasde estreacutes y situaciones de alta contienda
Comparar el uso de estas herramientas con las praacutecticas actuales de laindustria o implementacioacuten en un sistema de produccioacuten real
47
Referencias
[1] LA Barroso y U Houmllzle laquoThe Datacenter as a Computer An Introduc-tion to the Design of Warehouse-Scale Machinesraquo En Morgan amp ClaypoolPublishers ()
[2] Systems Research Group ndash NetOS (University of Cambridge) The evolu-tion of cluster scheduler architectures 2016 url httpswwwclcamacukresearchsrgnetoscamsasblog2016-03-09-scheduler-architectureshtml
[3] A Das I Gupta y A Motivala SWIM Scalable Weakly-consistent Infection-style Process Group Membership Protocol Inf teacutec Dept of ComputerScience Cornell University url https www cs cornell edu ~asdasresearchdsn02-swimpdf
[4] D Dubhashi y A Das Mastering Mesos PACKT Publishing mayo de2016
[5] The Apache Software Foundation Apache Mesos documentation urlhttpsmesosapacheorg
[6] David Greenberg Building Applications on Mesos OrsquoReilly Media 2016[7] Armand Grillet Comparison of Container Schedulers Inf teacutec Technische
Universitaumlt Berlin[8] HashiCorp Consul documentation url httpswwwconsulio[9] HashiCorp Nomad documentation url httpsdcosio[10] Dan C Marinescu Cloud computing theory and practice Morgan Kauf-
mann 2013[11] Mesosphere DCOS documentation url httpswwwnomadproject
io[12] Microsoft Azure documentation url httpsazuremicrosoftcom
es-esdocumentation[13] D Ongaro y J Ousterhout In Search of an Understandable Consensus
Algorithm Inf teacutec Stanford University url httpsraftgithubioraftpdf
[14] Fei Teng laquoRessource allocation and schelduling models for cloud compu-tingraquo Tesis de mtriacutea Ecole Centrale Paris 2011
[15] A Williams y col Automation and Orchestration with Docker and Contai-ners A Comprehensive Overview of the Docker and Container Ecosystem3 The New Stack 2016
48
- Resumen
- Summary
- Iacutendice de figuras
- Introduccioacuten y objetivos
-
- Contexto
- Objetivos
- Estructura del documento
-
- Cloud Computing
- Nuevas cargas de trabajo
- Gestioacuten de recursos Planificadores
-
- Sistemas distribuidos
-
- Clasificacioacuten
-
- Herramientas
-
- DCOS
-
- Apache Mesos
- Ejemplos de uso
-
- Nomad
-
- Protocolo de consenso Raft
- Protocolo gossip SWIM
- Planificacioacuten
-
- Casos de uso y despliegue
-
- Aplicacioacuten Web
-
- DCOS
- Nomad
-
- Servicio de integracioacuten continua
-
- DevOps
- Integracioacuten Continua
- Jenkins con Nomad
- Jenkins con DCOS
-
- Escalando la infraestructura
-
- Disentildeo
- Implementacioacuten
-
- Resultados y conclusiones
-
- Comparacioacuten
- Conclusiones
- Objetivos conseguidos
- Liacuteneas de investigacioacuten
-
Referencias
[1] LA Barroso y U Houmllzle laquoThe Datacenter as a Computer An Introduc-tion to the Design of Warehouse-Scale Machinesraquo En Morgan amp ClaypoolPublishers ()
[2] Systems Research Group ndash NetOS (University of Cambridge) The evolu-tion of cluster scheduler architectures 2016 url httpswwwclcamacukresearchsrgnetoscamsasblog2016-03-09-scheduler-architectureshtml
[3] A Das I Gupta y A Motivala SWIM Scalable Weakly-consistent Infection-style Process Group Membership Protocol Inf teacutec Dept of ComputerScience Cornell University url https www cs cornell edu ~asdasresearchdsn02-swimpdf
[4] D Dubhashi y A Das Mastering Mesos PACKT Publishing mayo de2016
[5] The Apache Software Foundation Apache Mesos documentation urlhttpsmesosapacheorg
[6] David Greenberg Building Applications on Mesos OrsquoReilly Media 2016[7] Armand Grillet Comparison of Container Schedulers Inf teacutec Technische
Universitaumlt Berlin[8] HashiCorp Consul documentation url httpswwwconsulio[9] HashiCorp Nomad documentation url httpsdcosio[10] Dan C Marinescu Cloud computing theory and practice Morgan Kauf-
mann 2013[11] Mesosphere DCOS documentation url httpswwwnomadproject
io[12] Microsoft Azure documentation url httpsazuremicrosoftcom
es-esdocumentation[13] D Ongaro y J Ousterhout In Search of an Understandable Consensus
Algorithm Inf teacutec Stanford University url httpsraftgithubioraftpdf
[14] Fei Teng laquoRessource allocation and schelduling models for cloud compu-tingraquo Tesis de mtriacutea Ecole Centrale Paris 2011
[15] A Williams y col Automation and Orchestration with Docker and Contai-ners A Comprehensive Overview of the Docker and Container Ecosystem3 The New Stack 2016
48
- Resumen
- Summary
- Iacutendice de figuras
- Introduccioacuten y objetivos
-
- Contexto
- Objetivos
- Estructura del documento
-
- Cloud Computing
- Nuevas cargas de trabajo
- Gestioacuten de recursos Planificadores
-
- Sistemas distribuidos
-
- Clasificacioacuten
-
- Herramientas
-
- DCOS
-
- Apache Mesos
- Ejemplos de uso
-
- Nomad
-
- Protocolo de consenso Raft
- Protocolo gossip SWIM
- Planificacioacuten
-
- Casos de uso y despliegue
-
- Aplicacioacuten Web
-
- DCOS
- Nomad
-
- Servicio de integracioacuten continua
-
- DevOps
- Integracioacuten Continua
- Jenkins con Nomad
- Jenkins con DCOS
-
- Escalando la infraestructura
-
- Disentildeo
- Implementacioacuten
-
- Resultados y conclusiones
-
- Comparacioacuten
- Conclusiones
- Objetivos conseguidos
- Liacuteneas de investigacioacuten
-