universidad central del ecuador … central del ecuador facultad de ingenierÍa, ciencias fÍsicas y...
TRANSCRIPT
UNIVERSIDAD CENTRAL DEL ECUADOR
FACULTAD DE INGENIERÍA, CIENCIAS FÍSICAS Y MATEMÁTICA
CARRERA DE INGENIERÍA INFORMÁTICA
IMPLEMENTACIÓN DE SERVIDOR DE APLICACIONES JBOSS MODO
DOMAIN PARA EL MINISTERIO DE EDUCACIÓN DEL ECUADOR
TRABAJO DE GRADUACIÓN, PREVIO A LA OBTENCIÓN DEL
TÍTULO DE INGENIERÍA INFORMÁTICA
AUTOR: PARRA AGUIRRE VERÓNICA RAFAELA
TUTOR: ING. MONCAYO UNDA MILTON GIOVANNY
QUITO, 25 DE JULIO
2016
II
DEDICATORIA
A mi madre ejemplo de lucha y constancia,
gracias a su apoyo dedicación y entera
confianza.
III
AGRADECIMIENTOS
La autora expresa sus agradecimientos a:
Elizabeth Varela Bolaños, Directora Nacional del Tecnología de la
Información y Comunicación del Ministerio de Educación del Ecuador, por su
apoyo y colaboración para el desarrollo de este proyecto.
Javier Alexander Chamorro, Ingeniero Informático y Coordinador del Área de
Infraestructura del Ministerio de Educación del Ecuador, por sus valiosas
orientaciones.
Milton Giovanny Moncayo Unda, Ingeniero Informático, Profesor de la
facultad de Ingeniería, Ciencias Físicas y Matemática, por su constante
motivación hacia este trabajo.
IV
AUTORIZACIÓN DE LA AUTORÍA INTELECTUAL
Yo, Verónica Rafaela Parra Aguirre en calidad de autor del trabajo de
investigación: IMPLEMENTACIÓN DE SERVIDOR DE APLICACIONES
JBOSS MODO DOMAIN PARA EL MINISTERIO DE EDUCACIÓN DEL
ECUADOR, por la presente autorizo a la UNIVERSIDAD CENTRAL DEL
ECUADOR hacer uso de todos los contenidos que me pertenecen o parte de
los que contiene esta obra, con fines estrictamente académicos o de
investigación.
Los derechos que como autor me corresponden, con excepción de la
presente autorización, seguirán vigentes a mi/nuestro favor, de conformidad
con lo establecido en los artículos 5, 6, 8; 19 y demás pertinentes de la Ley
de Propiedad Intelectual y su Reglamento.
Quito, 25 de julio del 2016.
Verónica Rafaela Parra Aguirre CI: 1719308775 Telf. : 0979036535 E-mail: [email protected]
II
CERTIFICACIÓN DEL TUTOR
Yo, Ing. Milton Giovanny Moncayo Unda en calidad de tutor del trabajo de
titulación Implementación de Servidor de Aplicaciones Jboss Modo Domain
para el Ministerio de Educación del Ecuador, elaborado por la estudiante
Verónica Rafaela Parra Aguirre de la Carrera de Ingeniería Informática,
Facultad de Ingeniería Ciencias Física y Matemáticas de la Universidad
Central del Ecuador, considero que el mismo reúne los requisitos y méritos
necesarios en el campo metodológico y en el campo epistemológico, para
ser sometido a la evaluación por parte del jurado examinador que se
designe, por lo que lo APRUEBO, a fin de que trabajo investigativo sea
habilitado para continuar con el proceso de titulación determinado por la
Universidad Central del Ecuador.
En la ciudad de Quito, 25 de julio de 2016.
Ing. MONCAYO UNDA MILTON GIOVANNY CI: 1718933383 Telf. : 0981869725 E-mail: [email protected]
III
IV
V
CONTENIDO
DEDICATORIA ........................................................................................................ II
AGRADECIMIENTOS ............................................................................................ III
AUTORIZACIÓN DE LA AUTORÍA INTELECTUAL ............................................... IV
CERTIFICACIÓN DEL TUTOR .............................................................................. II
LISTA DE ANEXOS ............................................................................................. VIII
LISTA DE FIGURAS............................................................................................... IX
LISTA DE TABLAS .................................................................................................. X
RESUMEN ............................................................................................................. XI
ABSTRACT ........................................................................................................... XII
INTRODUCCIÓN .................................................................................................... 1
OBJETIVOS ............................................................................................................ 2
Objetivo General ............................................................................................... 2
Objetivos Específicos........................................................................................ 2
ALCANCE ............................................................................................................... 2
LIMITACIONES ....................................................................................................... 3
1. MARCO TEÓRICO ........................................................................................... 4
1.1. Servidor de aplicaciones ............................................................................... 4
1.1.1. Servidor de Aplicaciones J2EE .................................................................. 5
1.1.2. JBOSS EAP (Enterprise Application Platform) ........................................... 7
1.2. Balanceador de Cargas ................................................................................. 8
1.2.1. Balanceo de Carga en Hardware: .............................................................. 8
1.2.2. Balanceo de Carga en Software:................................................................ 8
1.3. Servidores Web ............................................................................................. 9
1.4. Herramientas usadas en la implantación .................................................... 10
VI
1.4.1. Servidor de aplicaciones Jboss 6.4 .......................................................... 10
1.4.2. Servidor Web Apache .............................................................................. 14
1.4.3. Módulo de Balanceo Mod cluster ............................................................. 14
2. CASO DE ESTUDIO MINISTERIO DE EDUCACIÓN DEL ECUADOR .......... 16
2.1. Historia ........................................................................................................ 16
2.2. Organigrama del Ministerio de Educación del Ecuador Planta Central ....... 20
2.3. Necesidad de Diseño e implementación de nueva arquitectura para las
aplicaciones que maneja el Área de Infraestructura Tecnológica del Ministerio de
Educación del Ecuador.......................................................................................... 21
3. METODOLOGÍA DE IMPLEMENTACIÓN ...................................................... 26
3.1. Iniciación...................................................................................................... 26
3.2. Planificación ................................................................................................ 26
3.3. Cronograma................................................................................................. 26
3.4. Ejecución ..................................................................................................... 27
3.5. Control ......................................................................................................... 27
3.6. Cierre ........................................................................................................... 28
4. DISEÑO DE ARQUITECTURA E IMPLEMENTACIÓN DE SERVIDOR DE
APLICACIONES JBOSS MODO DOMAIN ............................................................ 29
4.1. Arquitectura de Aplicaciones ....................................................................... 29
4.1.1. Despliegue de Aplicaciones ..................................................................... 30
4.1.2. Balanceo de Carga ................................................................................... 31
4.2. Etapas de la Instalación y trabajos realizados ............................................. 31
4.2.1. Primera Etapa .......................................................................................... 31
4.2.2. Segunda etapa ......................................................................................... 37
4.2.3. Tercera etapa ........................................................................................... 44
5. RESULTADOS ............................................................................................... 46
5.1. Versionamiento de las aplicaciones ............................................................ 47
5.2. Disponibilidad de las aplicaciones .............................................................. 47
5.3. Independencia de log .................................................................................. 48
VII
5.4. Arquitectura Final ........................................................................................ 48
6. CONCLUSIONES Y RECOMENDACIONES .................................................. 50
6.1. CONCLUSIONES ........................................................................................ 50
6.2. RECOMENDACIONES ............................................................................... 51
BIBLIOGRAFÌA ..................................................................................................... 52
ANEXOS ............................................................................................................... 54
VIII
LISTA DE ANEXOS
ANEXO A. CARTA DE SOLICITUD DE IMPLEMENTACIÓN DE PROYECTO
MINISTERIO DE
EDUCACIÓN……………………………………….…………………………………….54
ANEXO B. Acta de constitución de
proyecto……………………………………………….………………..………………...55
ANEXO C. RACI usada para la implementación de servidor de aplicaciones jboss
modo
domain……………………………………………….……………………………………60
ANEXO D. Certificación de satisfacción de entrega de proyecto Ministerio
de………………………………………………………………………………..……..….63
ANEXO E. Manual de
instalación……………………………………………………………………….………..64
ANEXO F. Listado de asistencia a la capacitación - acta de
reunión…………………………………………………………………………………….83
IX
LISTA DE FIGURAS
Figura 1 Diagrama Jboss modo domain (INCLAMSOFT, 2012) ......................... 11
Figura 2 Organigrama Ministerio de Educación Planta Central ........................... 20
Figura 3 Antigua Arquitectura Ministerio de Educación y Cultura (MINEDUC,
2015) ..................................................................................................................... 23
Figura 4 Cronograma de actividades................................................................... 27
Figura 5 Arquitectura de Aplicaciones Ministerio de Educación .......................... 29
Figura 6 Repositorio RELV7 MINEDUC ............................................................. 32
Figura 7 Configuración Domain Controller ........................................................... 33
Figura 8 Perfil Domain Controller ........................................................................ 34
Figura 9 Perfil ha Domain Controller .................................................................. 34
Figura 10 Archivo pom.xml ................................................................................. 37
Figura 11 Monitoreo de aplicaciones PRTG ....................................................... 47
Figura 12 Arquitectura Ministerio de Educación y Cultura (MINEDUC, 2016) .... 49
X
LISTA DE TABLAS
Tabla 1 Archivos y directorios a nivel superior Jboss 6 …………………...……….12
Tabla 2 Directorios dentro del directorio domain ………………………………13
Tabla 3 Directorios dentro del directorio standalone………………………….……14
Tabla 4 Distribución de aplicaciones MINEDUC…………………………..…….......35
Tabla 5 Comparación de resultados………………………………………………….46
XI
RESUMEN
“IMPLEMENTACIÓN DE SERVIDOR DE APLICACIONES JBOSS MODO MANAGED
DOMAIN PARA EL MINISTERIO DE EDUCACIÓN DEL ECUADOR, MODALIDAD
PROYECTO INTEGRADOR”
Autor: Parra Aguirre Verónica Rafaela Tutor: Ing. Moncayo Unda Milton Giovanny
El Ministerio de Educación del Ecuador ha implementado varios sistemas que permiten
agilizar los trámites que la población ecuatoriana realiza en dicha cartera de estado, por
lo que garantizar la estabilidad y disponibilidad de estos sistemas es una de las
prioridades de la Dirección Nacional de Tecnología, Información y Comunicación del
Ministerio de Educación (DNTIC).
El principal problema que posee dicha Dirección, se encuentra en la administración de los
servidores de aplicaciones, ya que ésta se realiza de forma descentralizada, lo que
repercute en un alto tiempo de versionamiento y a su vez ha generado tiempos de
indisponibilidad en los sistemas durante los últimos años.
Al implementar una arquitectura de aplicaciones con la instalación de un servidor de
aplicaciones jboss en modo domain, se brinda al Ministerio de Educación del Ecuador un
medio viable, alcanzable y efectivo en cuanto al manejo de las aplicaciones, garantizando
la uniformidad de las versiones de las aplicaciones que se encuentran desplegadas en
sus servidores, además de facilitar la lectura de logs por medio de la independencia de
mismos, reduce el tiempo empleado al versionar una aplicación de dos horas a treinta
minutos, el aumento de porcentaje de disponibilidad de las aplicaciones de un sesenta por
ciento a noventa y ocho por ciento y la resolución de incidentes por medio de lectura de
logs se ha reducido de un día a treinta minutos, gracias a la independencia de log por
aplicación.
PALABRAS CLAVES: / ARQUITECTURA DE APLICACIONES/ ADMINISTRACIÓN DE
SERVIDORES/ APLICACIONES INFORMÁTICAS / SERVIDOR DE APLICACIONES / JBOSS MODO DOMAIN/ VERSIONES DE LAS APLICACIONES
XII
ABSTRACT
“IMPLEMENTATION OF APPLICATION SERVER JBOSS MANAGED DOMAIN MODE
FOR THE MINISTRY OF EDUCATION OF ECUADOR, INTEGRATOR PROJECT
CATEGORY”
Author: Parra Aguirre Verónica Rafaela Tutor: Ing. Moncayo Unda Milton Giovanny
The Educational Ministry of Ecuador has implemented several systems that allow
expediting the formalities of the Ecuadorian population that carries in the portfolio of the
state; to guarantee the stability and availability of these systems is one of the priorities of
the National Directorate of Technology, Information and Communication of the Ministry of
Education (DNTIC).
The main problem that has that Directorate, is in the management of application servers,
due to it is done in a decentralized manner, which results in a high time versioning and in
turn has led to downtimes in the systems that have been present in the last years.
At the moment of implementing an architecture of applications with the installation of a
server of applications JBOSS in DOMAIN mode, it is provided to the Ministry of Education
of Ecuador a viable, effective and achievable means in the management of applications
which will guarantee the uniformity of the versions of the applications that are deployed in
their servers and reducing the answer times, as well to facilitate the reading of logs
through the independence of the reduced time spent to versioning an application two
hours to thirty minutes, increasing percentage of availability of applications sixty percent to
ninety eight percent and incident resolution through reading logs has been reduced from
one day to thirty minutes, thanks to the independence of log per application.
KEY WORDS: /ARCHITECTURE APPLICATIONS / MANAGEMENT SERVERS /
COMPUTER APPLICATIONS / APPLICATION SERVER / DOMAIN MODE JBOSS/
VERSION OF APPLICATIONS.
1
INTRODUCCIÓN
“La educación es primordial, no sólo como uno de los instrumentos de la cultura que
permite al hombre desarrollarse en el proceso de la socialización, sino también se lo
consideraba como un proceso vital, complejo, dinámico y unitario que debe descubrir,
desarrollar y cultivar las cualidades del estudiante, formar integralmente su personalidad
para que se baste a sí mismo y sirva a su familia, el Estado, y la sociedad.” (Emilio, 1975)
La educación en Ecuador está reglamentada por el Ministerio de Educación, dicha
cartera de Estado ha implementado varios sistemas que facilitan la realización de trámites
y consultas sobre los servicios que esta ofrece a la población ecuatoriana.
Los sistemas que se encuentran bajo el cargo del Ministerio de Educación se ven
comprometidos por su alta transaccionalidad, número de usuarios y alto impacto político.
De ahí la importancia de garantizar su funcionamiento y disponibilidad.
La problemática que tiene el Ministerio de Educación, específicamente la DNTIC, está
relacionada con la administración de los sistemas informáticos, ya que en los últimos años
durante los periodos de inscripción de estudiantes, así como de postulación de docentes,
dichos sistemas han presentado altos tiempos de indisponibilidad y falla en su
funcionamiento, creando un ambiente de malestar en los usuarios. Una de las principales
causas de esta problemática es la arquitectura en la cual están levantadas las
aplicaciones, ya que posee una administración disgregada y sin discriminación de log por
aplicación, lo que ocasiona un versionamiento inadecuado y tiempos excesivos en la
resolución de incidentes, alcanzando periodos de resolución de dos horas hasta un día en
el mejor de los casos, provocando el retraso en los procesos de negocio que lleva la
institución.
En base a lo expuesto, se propone la implementación de un balanceador de carga con
descubrimiento automático de nodos, donde los nodos pueden levantarse dinámicamente
en base a la demanda y adicionalmente configurar un conjunto de servidores, cada uno
siendo referido como un miembro de un dominio con único proceso de controlador de
dominio, actuando como punto de administración central mediante jboss modo domain.
2
Adicionalmente, se definirá una política de administración, la cual será replicada
automáticamente a todas las instancias de jboss, facilitando la administración de los
servidores de aplicaciones (Epidata, 2014). Al independizar los logs por aplicación se
apoya directamente al proceso de mejoras de la DNTIC del Ministerio de Educación,
disminuyendo los tiempos de respuesta ante incidentes presentados. Consecuentemente
esta es una solución viable para el Ministerio de Educación que va acorde a la
infraestructura tecnología.
OBJETIVOS
Objetivo General
Implementar en el Ministerio de Educación del Ecuador una arquitectura usando un
servidor de aplicaciones jboss en modo domain, que permita disminuir el tiempo de
indisponibilidad de los sistemas y facilite la administración de los servidores de
aplicaciones de la institución.
Objetivos Específicos
1. Disminuir el tiempo usado en el control de versiones de las aplicaciones
informáticas.
2. Facilitar la administración de las aplicaciones informáticas.
3. Independizar los log de las aplicaciones informáticas.
ALCANCE
Implementar un servidor de aplicaciones jboss en modo domain en el ambiente de pre-
producción, desde el cual se administrará a treinta servidores de aplicaciones que
funcionaran como host controller, es decir siguiendo las políticas establecidas por el
3
controlador de dominio. Estos servidores se encontrarán en el centro de datos virtual del
Ministerio de Educación. Durante esta implementación se realizarán pruebas de
funcionamiento de los aplicativos, transferencia de conocimiento y entrega de
documentación técnica al personal de infraestructura de la DNTIC de Ministerio de
Educación.
LIMITACIONES
Esta implementación se realiza en el ambiente de pre-producción, usando herramientas
de Software libre como la versión comunitaria del servidor de aplicaciones jboss, y no se
contara con subscripciones al canal de Red Hat, por lo que la solución o soporte sobre la
plataforma se realizará a base de las soluciones encontradas en los foros.
4
1. MARCO TEÓRICO
1.1. Servidor de aplicaciones
Un servidor de aplicaciones proporciona servicios que soportan la ejecución y
disponibilidad de las aplicaciones desplegadas, es decir, se lo puede llamar también como
un contenedor de aplicaciones (Universidad de Alicante, 2003).
La mayor ventaja de utilizar Servidores de Aplicaciones es tener una configuración
centralizada, pues con esto se obtiene una disminución de tiempo en el desarrollo de
aplicaciones, ya que el grupo de desarrolladores se preocupa solamente en el desarrollo
de la aplicación más no en su despliegue. La tarea de administración del servidor donde
se aloja la aplicación se deja al grupo encargado del despliegue de la infraestructura
necesaria, sobre la cual se levantarán las aplicaciones, es decir, el desarrollador no se
preocupa por las interfaces, las conexiones a la base de datos y de mantener la seguridad
y control de usuarios.
Los servidores de aplicaciones están incluidos en capa media o middleware, que está
encargado de poner todo el conjunto de aplicaciones en un solo sitio. Los servidores de
aplicaciones proporcionan una Interfaz de Programación de Aplicaciones (API) a los
desarrolladores.
Unas de las características principales de los servidores de aplicaciones son:
Alta Disponibilidad: Se refiere a que el sistema debe funcionar las 24 horas al día, los
365 días del año.
Escalabilidad: La capacidad de poder crecer con nuevos sistemas que se agreguen al
conjunto del clúster (conjunto de ordenadores unidos por una red de alta velocidad que se
comporta como una única computadora), cuando la carga de trabajo aumenta.
5
Mantenimiento: Es la facilidad en el momento de actualizar, depurar fallos y poder
mantener el sistema de la forma más sencilla.
Un servidor de aplicaciones funciona en tres capas, lo cual permite estructurar al sistema
de una forma más simple y eficiente. A continuación se detallan las tres capas:
Capa 1: El navegador en el ordenador del usuario debe ser capaz de traducir el código
del lado del cliente (HTML, JavaScript, CSS, Flash).
Capa 2: La compone el servidor de aplicaciones, en la cual se debe traducir el código del
lado del servidor y convertirlo a un formato que pueda ser entendible por el navegador del
cliente.
Capa 3: Están todos los servicios que accede el servidor de aplicaciones para poder
realizar el trabajo que le ordenan (como por ejemplo el de acceso a la base de datos).
1.1.1. Servidor de Aplicaciones J2EE
Estos servidores de Aplicaciones utilizan la tecnología Java. El estándar J2EE permite el
desarrollo de aplicaciones de empresa de una manera sencilla y eficiente. Una aplicación
desarrollada con las tecnologías J2EE permite ser desplegada en cualquier servidor de
aplicaciones o servidor web que cumpla con el estándar. El objetivo principal de la
tecnología J2EE es la utilización de un modelo simple de desarrollo para aplicaciones
empresariales. Java J2EE provee estándares que permiten a un servidor de aplicaciones
actuar como un contenedor de todos los componentes de tales aplicaciones. (Oracle
Corporation, 2013)
En este modelo los componentes utilizan servicios que son proporcionados por el
contenedor, que de no ser así tendrían que estar dentro del código fuente de las
aplicaciones Los componentes son desarrollados en código Java y se les conoce como
Servlets, JSPs (Java Server Pages) y EJBs (Enterprise JavaBeans). Estos permiten
implementar las capas de las aplicaciones para la interfaz de usuario, la lógica del
negocio y acceso a las bases de datos remotas.
6
J2EE soporta aplicaciones distribuidas, en las que toma ventajas de tecnologías ya
existentes; define estándares que son implementados por distintos proveedores y
fabricantes, no fuerza a emplear ningún producto de software específico. Adicionalmente
una de las principales ventajas de utilizar esta tecnología como plataforma es que se
puede empezar con poco o en ciertos casos sin ningún costo, ya que existen muchas
herramientas de código abierto para incrementar el tamaño de las plataformas, para hacer
más sencillo su desarrollo. (Zattola, 2014)
La arquitectura de un servidor de aplicaciones consiste en los siguientes subsistemas:
1. Servidor HTTP: También es conocido como servidor web. Generalmente está
aplicado sobre TCP/IP; está basado en peticiones y respuestas que por defecto
utiliza el puerto 8080, aunque se puede configurar para utilizar otro puerto.
2. El Contenedor de Aplicaciones.
3. Un contenedor de Enterprise Java Beans, en el que se aloja todo el aplicativo java
para la interacción con la Base de Datos o los sistemas empresariales.
(Universidad Autonoma de Baja California, 2004)
Todos estos subsistemas interactúan con el cliente de la siguiente forma: el cliente que
desea utilizar la aplicación no la contacta directamente, primero se conecta con el servidor
web por medio de HTTP. El servidor web es el intermediario en la solicitud, es el
encargado de llevar la petición hasta el servidor de aplicaciones donde se aloja la
aplicación requerida. El cliente por lo general, a través de un explorador o una aplicación,
pide un recurso por medio de HTTP, el cual es localizado especificando el URL
(Localizador de Recursos Uniforme).
Los servidores de aplicaciones J2EE más comunes son Glassfish y JBoss, este último es
en código abierto y es el más usado al momento por empresas en el sector público y
privado:
1. Glassfish: es un servidor de aplicaciones hecho en software libre, que utiliza el
estándar J2EE, es desarrollado por Sun Microsystems, que pertenece a Oracle.
7
Glassfish es distribuido a través de un licenciamiento dual, lo que significa que usa
licencia CDDL (Common Development and Distribution License) y GNU GPL
(General Public Licence). EL código fuente de Glassfish es donado por la Sun y
Oracle Corporation. (Oracle Corporation, 2014)
2. Otros tipos de Servidores de Aplicaciones: Existen otros servidores de
aplicaciones que no utilizan el estándar JEE y emplean otros lenguajes de
programación que son utilizados en la actualidad, como .Net. .Net ha tenido un
crecimiento en el Mercado, por lo que Microsoft decidio lanzar su propio servidor
de aplicaciones llamado: Internet Information Server.
Así mismo, existen servidores de aplicaciones que utilizan código abierto, como por
ejemplo Base4 Server y Zope, los cuales no son tan populares por no tener soporte oficial
del fabricante y solo disponer información de foros, razón por la cual la tendencia a usar
JBoss EAP 6 es la más usada en la actualidad por empresas privadas y
gubernamentales.
1.1.2. JBOSS EAP (Enterprise Application Platform)
Es un contenedor de aplicaciones que cumple con los requerimientos de la especificación
Java empresarial; es una multiplataforma de código abierto basado en Java, la primera
versión fue realizada por Marc Fleury, con la que creo JBoss Inc., pero posteriormente fue
adquirida por Red Hat en abril del 2006. JBoss tiene su versión comunitaria, que cualquier
persona puede descargarla desde la página oficial de JBoss, la desventaja de utilizar la
versión comunitaria es que si en algún momento se presenta una falla, la solución
depende de las respuestas que se encuentran en la comunidad. Para evitar esto Red Hat,
tiene la versión empresarial, de esta forma los usuarios que utilizan JBoss tienen la
seguridad de que cualquier problema que pueda surgir, son solucionados con soporte de
Red Hat que está incluido con los tipos de suscripción disponibles 24 x 7 o 5 x 8. (Oracle
Corporation, 2013)
8
1.2. Balanceador de Cargas
Un balanceador de cargas es una solución, la cual permite dividir las tareas que son
asignadas a un único servidor a otros servidores que se encuentran en una misma red,
esto se lo hace con el propósito de maximizar el proceso de datos y la ejecución de
tareas. Con un balanceador de cargas se consigue que ningún equipo sea indispensable
en el servicio que se desea ofrecer. (Oracle Corporation, 2013)
Tiene dos características principales:
1. Evitar la saturación de un servidor. Se evita que los picos de acceso al servidor
puedan afectar el desempeño de la aplicación.
2. Se gestiona de una manera eficiente los recursos. Permite optimizar y gestionar
todos los recursos para que de esta manera los aplicativos que se tienen
implementados funcionen de la mejor forma posible.
1.2.1. Balanceo de Carga en Hardware:
Los balanceadores de carga en Hardware son servidores con un propósito único: el de
balanceo. No se pueden utilizar a dichos servidores para algún otro propósito, lo cual es
una gran desventaja ya que el servidor es subutilizado y aumenta el costo en el montaje
de los centros de datos de las organizaciones. No obstante, al utilizar balanceo de carga
por Hardware, solo para balanceo se tiene una gran potencia y estabilidad.
Así mismo, cabe recalcar que una desventaja que tiene este tipo de balanceador es el
precio, pues son muy caros y el mantenimiento es extremadamente alto; funcionan como
una caja cerrada, es decir, el desarrollador no puede manipular el código fuente ni
cambiar la estructura; solo se lo administra por una interfaz web.
1.2.2. Balanceo de Carga en Software:
Los balanceadores de carga en Software son servidores que son configurados para
realizar la tarea de balanceo, para esto el servidor necesita tener un sistema operativo y
9
una aplicación para que se encargue del balanceo. A estos se los conoce como
balanceadores de carga en capa 4 del modelo OSI, balanceadores de carga a nivel de
software. (Oracle Corporation, 2013)
Las ventajas de utilizar este tipo de balanceador son económicas, ya que este
balanceador es más barato que los balanceadores en hardware. Adicionalmente se puede
utilizar en cualquier servidor, y si se necesita una mayor potencia en balanceadores este
servidor puede ser configurado para otra utilización. El balanceo de carga en software
distribuye las peticiones a los servidores en base un algoritmo como:
1. Round robin: es una disposición de la elección de todos los elementos de un grupo
igualmente en un orden racional, por lo general desde la parte superior a la parte
inferior de una lista y luego comenzar de nuevo en la parte superior de la lista y así
sucesivamente.
2. Weighted round robin: funciona de una manera similar a Round Robin, pero
asigna más peticiones a los nodos con un mayor "peso". Durante un período de
tiempo, los nodos recibirán un número de solicitudes en proporción a su peso.
3. Least connections: Utiliza el método de menos conexiones, el equilibrador de
carga selecciona el servicio utilizando el valor (N) de la siguiente expresión: N =
Número de transacciones activas, distribuyendo las peticiones a los servidores
que menos cargas activas tengan.
4. Least response time: el menos tiempo de respuesta, este distribuye las peticiones
dando preferencia a los servidores que atiendan en el menor tiempo una petición.
1.3. Servidores Web
Un servidor web se mantiene a la espera de peticiones de ejecución que hará un cliente o
usuario de internet, el servidor web es un programa que procesa cualquier aplicación del
lado del servidor, realizando conexiones bidireccionales o unidireccionales con el cliente,
generando o cediendo una respuesta en cualquier lenguaje o aplicación del lado de
cliente. Existen dos tipos de servidores web:
10
Servidor dedicado, que se refiere a una computadora servidora dedicada
exclusivamente al sitio del cliente. Se usa comúnmente para aplicaciones de alta
demanda, y
Servidor compartido, que significa que un mismo servidor se usará para varios
clientes, compartiendo los recursos.
1.4. Herramientas usadas en la implantación
Las herramientas seleccionadas para la implementación de la arquitectura de aplicaciones
en el Ministerio de Educación se describen a continuación:
1.4.1. Servidor de aplicaciones Jboss 6.4
JBoss EAP 6.4 posee una administración centralizada de múltiples instancias del servidor.
Es una plataforma middleware, rápida y segura; provee clustering con alta disponibilidad,
mensajería rápida, cache distribuido y otras tecnologías que la ayudan a ser una
plataforma estable y escalable. La nueva estructura que presenta JBoss EAP 6 permite
que los servicios se activen únicamente cuando sean necesarios, lo que permite que
aumente significativamente la velocidad del trabajo. La consola de administración y la
interfaz de línea de comandos (CLI) eliminan la necesidad de editar manualmente los
archivos de configuración XML, con esto se añade la posibilidad de automatizar los
procesos.
En la versión de JBoss EAP 6 todos los archivos de configuración están centralizados, a
diferencia de las anteriores versiones de JBoss EAP que tenía muchos archivos de
configuración; con esta mejora se ahorra tiempo y es más fácil de realizar cambios en las
configuraciones. JBoss EAP 6 soporta clustering en diferentes niveles, provee balance de
carga y los beneficios de failover. (Palacio & Abril, 2012)
Existen varias formas de arrancar JBoss, podemos iniciar una única instancia en modo
standalone o como Managed Domain.
11
1. Standalone: se arranca el servidor Jboss como una instancia única. Esto significa
que no comparte recursos con ninguna otra instancia en el cluster, se puede
desplegar varios servidores jboss en un mismo servidor físico pero se debe
diferenciar la ip con la que este se iniciara.
2. Domain: en este modo de funcionamiento se definen un conjunto de procesos
Jboss que comparte recursos, funcionando como maestro-esclavo(s).
Figura 1 Diagrama Jboss modo domain (INCLAMSOFT, 2012)
Como se puede ver en la Figura 1. Diagrama Jboss modo domain, en todos los host tiene
que haber un “controller” (de color naranja) que es el encargado de la administración a
nivel de arquitectura. En los host esclavos pueden ejecutarse una o varias instancias (de
color azul), en el maestro se podrían tener instancias pero no suele hacerse, ya que se
ocupa exclusivamente de tareas de gestión del cluster. Se pueden definir “server-groups”
a los cuales pertenecerán las instancias y que permite especificar unas características
12
particulares para cada grupo. Por ejemplo; la máquina virtual de Java que se utiliza,
límites de uso de memoria, entre otros. (JBoss.org, 2014)
Estructura de directorios jboss EAP 6.4
JBoss EAP 6.4 incluye una estructura de directorio simplificada comparada con versiones
anteriores. A continuación se enlistan los directorios y una descripción de lo que cada
directorio contiene. También se incluye estructuras de directorio de las
carpetas standalone/ y domain/.
Tabla 1 Archivos y directorios a nivel superior Jboss 6 (Red Hat, 2013)
Nombre Propósito
appclient/ Contiene los detalles de configuración para el contenedor del cliente de la
aplicación.
bin/ Contiene los scripts de arranque para JBoss EAP 6 en Red Hat
Enterprise Linux y Microsoft Windows.
bundles/ Contiene grupos OSGi, los cuales pertenecen a la funcionalidad interna
de JBoss EAP 6.
docs/ Archivos de licencia, archivos, esquemas y ejemplos.
domain/ Los archivos de configuración, el contenido de la implementación y las
áreas de escritura utilizadas cuando JBoss EAP 6 ejecuta como un
dominio administrado.
modules/ Los módulos que JBoss EAP 6 carga de manera dinámica cuando los
servicios los requieren.
13
standalone/ Los archivos de configuración, el contenido de la implementación y las
áreas de escritura utilizadas cuando JBoss EAP 6 ejecuta como un
servidor autónomo.
welcome-content/ Tiene contenido que la aplicación web de bienvenida utiliza, la cual está
disponible en el puerto 8080 de una instalación predeterminada.
jboss-modules.jar El mecanismo bootstrap que carga los módulos.
Tabla 2 Directorios dentro del directorio domain/ (Red Hat, 2013)
Nombre Propósito
configuration/ Estos archivos se modifican por medio de la consola de administración y el CLI
de administración y no se debe modificar directamente.
data/ Información sobre los servicios implementados
log/ Contiene los archivos de registro del tiempo de ejecución para el host y los
controladores de procesos, los cuales ejecutan en la instancia local.
servers/ Contiene los directorios data/, log/ y tmp/ equivalentes para cada instancia del
servidor en un dominio, el cual contiene datos similares a los mismos directorios
dentro del nivel superior del directorio domain/.
tmp/ Contiene datos temporales tales como archivos que pertenecen al mecanismo
de clave compartida que el CLI de administración utiliza para autenticar a los
usuarios locales en el dominio administrado.
14
Tabla 3 Directorios dentro del directorio standalone/ (Red Hat, 2013)
Nombre Propósito
configuration/ Los archivos de configuración para el servidor autónomo. Estos archivos se
modifican por medio de la consola de administración y el CLI de administración.
deployments/ Información sobre los servicios implementados. El servidor autónomo incluye un
escáner de implementación de manera que pueda poner los archivadores en
este directorio a implementarse. Se recomienda administrar las
implementaciones usando la consola de administración o CLI de administración.
lib/ Bibliotecas externas, las cuales pertenecen al modo del servidor autónomo.
Vacío por defecto.
tmp/ Contiene datos temporales tales como los archivos que pertenecen al
mecanismo de clave compartida que el CLI de administración utiliza para
autenticar a los usuarios locales en el servidor.
1.4.2. Servidor Web Apache
El Proyecto Apache HTTP Server es un esfuerzo por desarrollar y mantener un servidor
HTTP de código abierto para sistemas operativos modernos, incluyendo UNIX y
Windows. El objetivo de este proyecto es proporcionar un servidor seguro, eficiente y
extensible que proporciona servicios HTTP en sincronización con los estándares HTTP
actuales. El servidor HTTP Apache ("httpd") fue lanzado en 1995 y ha sido el servidor web
más popular en Internet desde abril de 1996.
1.4.3. Módulo de Balanceo Mod cluster
Es un balanceador de carga que es basado en httpd. Como mod_jdk, que se usaba
anteriormente, mod_cluster utiliza un canal de comunicación para reenviar las solicitudes
http a un conjunto de servidores que se encuentran en un clúster de servidores de
15
aplicaciones. La diferencia principal entre mod_cluster con mod_jdk, es que mod_cluster
aprovecha una conexión adicional entre los nodos del servidor de aplicaciones y httpd.
Los nodos del servidor de aplicaciones usan esta conexión para transmitir información del
balanceador de cargas y eventos registrados a través de métodos HTTP, llamados
mod_cluster Management Protocol (MCMP). Este canal usado para la retroalimentación
permite a mod_cluster tener un nivel de inteligencia y granularidad para así poder mejorar
continuamente.
Mod_cluster trabajó en capa 7 en el modelo OSI, lo cual significa que funciona a nivel de
aplicaciones. Lo que hace es inspeccionar el mensaje hasta la capa 7, es decir, hasta la
petición HTTP, permitiendo analizar la petición y sus encabezados, lo cual se usa como
estrategia para el balanceo de carga. Con esto se puede realizar el balanceo en base a la
cadena de la consulta, en cookies o en algún encabezado que se escoge.
En contraste con los equilibradores de carga basada en httpd tradicionales, mod_cluster
utiliza factores de equilibrio de carga que son calculados y proporcionados por los
servidores de aplicaciones, en lugar de calcular estos datos en el proxy. En consecuencia,
mod_cluster ofrece un conjunto más robusto y preciso de las estadísticas y factores de
carga que está disponible en el proxy. Mod_cluster conoce cuando una aplicación no está
desplegada así que no envía solicitudes para su contexto (por medio del URL) hasta que
esta esté desplegada. (INC., 2014)
16
2. CASO DE ESTUDIO MINISTERIO DE EDUCACIÓN DEL ECUADOR
2.1. Historia
Los antecedentes del Ministerio de Educación del Ecuador se remontan a la época de
formación de la República. Cuando se constituye el Ecuador en 1830, la entidad estatal
encargada de la organización del sistema educativo era la Dirección General de Estudios,
institución de origen bolivariano que se adaptó a las necesidades del nuevo Estado-
Nación.
También de aquella época data la primera ley orgánica de Instrucción Republicana. Hay
que esperar al advenimiento del gobierno del presidente Vicente Rocafuerte (1835-1839)
para que se desarrollen las primeras políticas educativas propiamente republicanas. En
1836, a través de dos decretos de crucial importancia, Rocafuerte crea la Dirección
General de Instrucción e Inspección de Estudios para cada provincia y el Decreto
reglamentario de Instrucción Pública.
Excluyendo a los estudiantes universitarios que no pasaban de ochenta, en esos
momentos el país contaba con 8 colegios (uno femenino) y 290 escuelas (30 femeninas),
que en conjunto abarcaban una población estudiantil de poco más de 13.000 estudiantes
(Emilio, 1975).
En 1863 la Legislatura, que durante el siglo XIX tenía la atribución de crear
establecimientos educativos, logra transferir la organización de la instrucción pública a
manos de un Consejo General con extensiones provinciales, integrado por un “Ministro”
del ramo y representantes de la Iglesia, de la Universidad y de las academias científicas y
literarias. De otro lado, las municipalidades adquieren atribuciones en el manejo y
supervigilancia de las escuelas sostenidas con sus fondos.
Este carácter descentralizado del sistema educativo se pierde bruscamente por iniciativa
del presidente Gabriel García Moreno (1861-1865/1869-1875). Entre sus disposiciones no
solo se obliga a que los directores de los establecimientos profesen la religión católica
17
oficial, sino que con la Ley de 1871, también se ordena la abolición de los Consejos en las
provincias, la no intervención de los municipios en materia educativa y la transferencia al
Ejecutivo de todas las facultades directivas en educación, al tiempo que se establece la
gratuidad de la enseñanza y el derecho a una escuela por cada población que posea 500
niños. Para entonces, el número de escolares era de alrededor de 32.000 y el Estado
invertía el 11% de su presupuesto en instrucción pública (Ayala Mora, 1988).
En 1884, bajo el régimen “progresista” del presidente José María Plácido Caamaño (1883-
1888), se crea el Ministerio de Instrucción Pública. Pero el verdadero impulso para su
ampliación y fortalecimiento es consecuencia de la revolución liberal de 1895,
encabezada por Eloy Alfaro, y del proceso de consolidación del Estado laico en las
décadas subsiguientes. El Ministerio de Instrucción, junto con los de Interior, Relaciones
Exteriores, Guerra y Hacienda forma parte de las cinco carteras de estado establecidas
por el presidente liberal Leonidas Plaza durante su primera administración (1901-1905).
La mayor parte de los 1.726 empleados que tuvo el Ministerio en esos años estaba
compuesta por profesores. Los burócratas, 58 en total, se distribuyen entre las oficinas
centrales, el Conservatorio Nacional, la Biblioteca nacional, la Escuela de Bellas Artes y el
Jardín Botánico. Siendo la educación una cuestión prioritaria del gobierno liberal, en 1906
se declara la oficialidad de la enseñanza laica y la exclusividad de la subvención estatal
en su beneficio.
En ese marco, el ministro alfarista José Peralta emprende la reforma educativa más
exitosa de la historia nacional, a través de la creación de los Institutos Pedagógicos o
Normales, cuyo sostenimiento absorbería en adelante una gran parte del presupuesto
para la instrucción pública. El sistema normalista abre para los sectores medios, sobre
todo para las mujeres, una importante puerta de acceso a la función pública. Ministros
liberales tan relevantes como Luis Napoleón Dillon y Manuel María Sánchez apoyan
decididamente el “normalismo”. En 1913 Dillon contrata la Misión Pedagógica Alemana
que no solo diseña y asesora la aplicación de un nuevo plan de estudios para la formación
docente, sino que formula el Reglamento de Régimen Escolar y elabora un mapeo de las
demandas en infraestructura escolar.
18
Con el auspicio del ministro Sánchez se organiza la Primera Conferencia Pedagógica
Nacional. Una segunda misión alemana contratada por el Ministerio consolida la
formación de los maestros en la línea del enfoque herbartiano, que se generalizará como
una matriz de la cultura pedagógica establecida por la educación laica a nivel nacional.
En 1928, cuando prácticamente ha culminado la labor de las Misiones, y la Constitución
reafirma el carácter laico, gratuito y obligatorio de la enseñanza, el Ecuador cuenta con
1.771 escuelas, de las cuales 1.470 son estatales o municipales, y con un conjunto de
2.400 profesores que incluye 320 normalistas. El laicismo deja de ser el espíritu de las
políticas educativas con la Constitución de 1946 que, bajo la influencia del presidente
José María Velasco Ibarra, favorece de manera importante a la educación privada,
otorgándole una subvención estatal del 20% del presupuesto en educación. En la década
de 1960 el Ministerio de Educación inicia un proceso de modernización institucional con la
creación del departamento de Planeamiento Integral de la Educación. Entre los años
sesenta y ochenta, el Ministerio se amplía y consolida su rectoría con la creación de las
21 Direcciones nacionales. Actualmente el Ministerio funciona a través de subsecretarias,
coordinaciones zonales y distritos educativos.
Misión
Garantizar el acceso y calidad de la educación inicial, básica y bachillerato a los y las
habitantes del territorio nacional, mediante la formación integral, holística e inclusiva de
niños, niñas, jóvenes y adultos, tomando en cuenta la interculturalidad, la
plurinacionalidad, las lenguas ancestrales y género desde un enfoque de derechos y
deberes para fortalecer el desarrollo social, económico y cultural, el ejercicio de la
ciudadanía y la unidad en la diversidad de la sociedad ecuatoriana.
Visión
El Sistema Nacional de Educación brindará una educación centrada en el ser humano,
con calidad, calidez, integral, holística, crítica, participativa, democrática, inclusiva e
interactiva, con equidad de género, basado en la sabiduría ancestral, plurinacionalidad,
con identidad y pertinencia cultural que satisface las necesidades de aprendizaje
19
individual y social, que contribuye a fortalecer la identidad cultural, la construcción de
ciudadanía, y que articule los diferentes niveles y modalidades del sistema de educación.
Valores
Honestidad, para tener comportamientos transparentes –honradez, sinceridad,
autenticidad, integridad– con nuestros semejantes y permitir que la confianza colectiva se
transforme en una fuerza de gran valor.
Justicia, para reconocer y fomentar las buenas acciones y causas, condenar aquellos
comportamientos que hacen daño a los individuos y a la sociedad, y velar por la justicia a
fin de que no se produzcan actos de corrupción.
Respeto, empezando por el que nos debemos a nosotros mismos y a nuestros
semejantes, al ambiente, a los seres vivos y a la naturaleza, sin olvidar las leyes, normas
sociales y la memoria de nuestros antepasados.
Paz, para fomentar la confianza en nuestras relaciones con los demás, para reaccionar
con calma, firmeza y serenidad frente a las agresiones, y para reconocer la dignidad y los
derechos de las personas.
Solidaridad, para que los ciudadanos y ciudadanas colaboren mutuamente frente a
problemas o necesidades y se consiga así un fin común, con entusiasmo, firmeza, lealtad,
generosidad y fraternidad.
Responsabilidad, para darnos cuenta de las consecuencias que tiene todo lo que
hacemos o dejamos de hacer, sobre nosotros mismos o sobre los demás, y como
garantía de los compromisos adquiridos.
Pluralismo, para fomentar el respeto a la libertad de opinión y de expresión del
pensamiento, y para desarrollar libremente personalidad, doctrina e ideología, con respeto
al orden jurídico y a los derechos de los demás.
20
2.2. Organigrama del Ministerio de Educación del Ecuador Planta Central
El presente proyecto se realizara en la dirección Nacional de Tecnología de la Información
y Comunicación, apoyando al área de Infraestructura y Operaciones la cual pertenece a
la Coordinación General de Gestión Estratégica.
Figura 2 Organigrama Ministerio de Educación Planta Central (MINEDUC, 2012)
21
2.3. Necesidad de Diseño e implementación de nueva arquitectura para las
aplicaciones que maneja el Área de Infraestructura Tecnológica del
Ministerio de Educación del Ecuador
El Ministerio de Educación del Ecuador soporta el componente tecnológico de los
principales productos, que son administrados por la Dirección Nacional de Tecnologías de
Información y Comunicaciones, por medio de la Unidad de Infraestructura y Operaciones
Tecnológicas que posee dos centros de datos: el primero ubicado en edificio planta
central del Ministerio de Educación del Ecuador y el segundo centro de datos virtual que
se encuentra en el Cloud de CNT. Dentro de los principales productos se encuentran las
aplicaciones web.
A continuación se listan las aplicaciones que mayor impacto político y social tienen:
Inscripción, por medio de este aplicativo las personas se pueden inscribir para reservar
un cupo dentro de las instituciones educativas públicas. Este procedimiento fue lanzado a
partir del 2014. Para obtener la información base se realizó un censo en todo el país para
medir la población estudiantil. Diariamente se registran 2.900 inscripciones.
Para realizar esta inscripción el usuario ingresa a un formulario de forma directa, lo que
permite que cualquier persona pueda realizar este proceso.
Asignación de cupos, la cual tiene dos modalidades: modalidad continua, que permite la
asignación de estudiantes a instituciones educativas públicas de forma permanente, y la
modalidad ordinaria, la cual permite realizar procesos de transferencia de estudiantes y
asignación de estudiantes a instituciones educativas públicas durante fechas
programadas donde se tiene un universo de usuarios de 45.00.000, registrando 8700
asignaciones y 15000 traslados por día.
Titulación, permite realizar el proceso de titulación de los estudiantes que finalizaron sus
estudios secundarios, teniendo mayor transaccionalidad al finalizar el periodo escolar
sierra y costa, registrando 120.000 titulaciones por periodo escolar.
22
Tanto para el aplicativo asignación de cupos, titulación como otros once aplicativos más
usan aplicativo web CAS (Central Authentication Service) como método de autenticación.
En general, cuando un usuario se conecta a una de estas aplicaciones el sistema
comprueba si está autenticado y si no lo está lo redirige a la pantalla del servidor de
autenticación. Si la autenticación es correcta, el sistema de autenticación, en este caso
CAS, vuelve a redirigir al usuario a la página a la que quería acceder en un primer
momento.
Dentro de las revisiones realizadas a la plataforma tecnológica del Ministerio de
Educación, antes del diseño e implementación de la arquitectura de aplicaciones usando
el servidor de aplicaciones jboss modo domain, se pudo evidenciar un alto nivel de
complejidad en las configuraciones aplicadas a los servidores que formaban parte del
clúster de treinta servidores de aplicaciones JBoss EAP 6.2 con JDK 1.6 en la mayoría de
estos, ya que los servidores de aplicaciones no presentaban uniformidad en sus
configuraciones y ocho balanceadores web de capa 7 implementados con Apache 2.2
usando un módulo mod_jk. Para realizar la publicación de un aplicativo era necesario
hacer la edición en cada servidor de dos archivos de configuración de forma manual, el
primer archivo workers. properties donde se definen los puertos ajp de los servidores en
los que aplicaciones que se van a balancear, y el segundo archivo uriworker.properties
donde se definen los contextos de las aplicaciones y al grupo de balanceo al que
pertenecerán.
Los servidores de aplicaciones así como balanceadores web estaban implementados
sobre una plataforma de sistema operativo Red Hat Linux 6.3
Estas instalaciones se realizaron de forma emergente para suplir la necesidad de brindar
el servicio de una sola aplicación que era el Sistema de Inscripciones y Asignaciones.
El esquema general de la plataforma de aplicaciones inicial era la siguiente:
23
Figura 3 Antigua Arquitectura Ministerio de Educación del Ecuador (MINEDU, 2015)
INTERNET
ENLACE DATOS
FW MINEDUC
HOUSING
10.40.41.4
181.113.66.4/26
40 Mbps
100 Mbps
FW PERIMETRAL EN HA
181.113.66.4/26
10.200.50.0/24
FW GATEWAY Y DMZ
FW PRODUCION
APLICACIONES
RED10.200.2.0 / 24
10.200.2.0/24
WAF
WAF
WAF
WAF
10.200.4.60
10.200.4.61
10.200.4.62
10.200.4.14
BALANCEADORES APACHE 10.200.4.101 – 10.200.4.104
10.200.4.0/24
10.200.41.0/24
SRV APLICACIONES 10.200.2.100 – 10.200.2.116
10.200.6.0/24
DMZ ANTISPAM
10.200.7.0/24
10.200.40.0/24
10.200.1.0/24
BASE DE DATOS
WAF
WAF
WAF
WAF
10.200.8.5
10.200.8.6
10.200.8.7
10.200.8.8
10.200.8.0/24
BALANCEADORES APACHE 10.200.8.15 – 10.200.8.17
SERVIDORES JBOSS 10.200.8.25 – 10.200.8.30
RED10.200.4.0 /24
RED10.200.7.0 /24
RED10.200.8.0 /24
PORTALES
ARHES
10.200.50.0/24
10.40.41.6
181.113.66.21/26
10.200.5.0/24
10.200.50.0/24
FW BASE DATOS
10.200.50.0/24
SERVICIOS.EDUCACION.GOB.EC
RED CORREO ELECTRONICO
SERVICOS2.EDUCACION.GOB.EC
Servidores de Aplicaciones
10.200.2.0/34
10.200.4.0/34
Servidores de
Aplicaciones
Balanceadores
Web
24
El área de infraestructura del Ministerio de Educación manejaba dos dominios por los
cuales se podía acceder a las aplicaciones: servicios.educacion.gob.ec compuesto por
16 servidores de aplicaciones que se encontraban en la red dos y cuatro servidores web,
ambiente que se encontraban en la red cuatro, creado en primera instancia para el
despliegue del aplicativo asignación de cupos, bajo este dominio se encontraban
desplegadas trece aplicaciones las cuales usan como método de autenticación el
aplicativo CAS, presentando grandes tiempos de indisponibilidad debido a la gran
afluencia de usuario y saturación de aplicativo CAS y alto consumo de memoria por el
aplicativo asignación de cupos.
El primero de mayo del 2015 se solicita al área de infraestructura el despliegue del
aplicativo sistema de gestión docente méritos y opciones, sistema usado para la
postulación de profesionales a ser docentes de la planta docente pública, y la asignación
de vacantes o partidas en las instituciones públicas del Ecuador.
Basándose en las estadísticas de afluencia y en la verificación y consumo de recursos de
los servidores de aplicaciones del dominio servicios.educacion.gob.ec se decide
implementar otro ambiente de producción compuesto por cinco servidores de aplicaciones
y cuatro balanceadores web en la red ocho, para el despliegue del aplicativo sistemas de
gestión docente méritos y opciones, con el fin de evitar la afectación de las aplicaciones
que ya se encontraban desplegadas, de ahí que se publica el dominio
servicios2.educacion.gob.ec, al tener alta concurrencia se solicita incrementar los
recursos de infraestructura, para lo cual se incrementan tres servidores de aplicaciones y
dos balanceadores web.
Las falencias encontradas
1. Uso de un único firewall dentro de la estructura de seguridad del centro de datos
virtual, el cual ejercía las funciones de firewall perimetral y firewall de control de
acceso hacia equipos críticos de la institución entre ellos los servidores de
aplicaciones.
2. Implementación de numerosas redes para implementar servicios que contienen
características similares: servidores de aplicaciones en la red dos y red ocho.
25
3. Falta de control de acceso entre redes independientes.
4. Falta de levantamiento de herramientas de monitoreo.
5. Tiempos altos usados para el versionamiento de las aplicaciones, este proceso se
realizaba de forma manual servidor por servidor.
6. Indisponibilidad de las aplicaciones por grandes periodos.
7. Al tener las aplicaciones en jboss modo standalone, el crecimiento de recurso se
realiza de forma horizontal, con la implementación de más servidores.
8. Falta de implementación de estándares de seguridad dentro de los servidores de
producción.
9. Configuraciones diferentes dentro de servidores que ofrecen el mismo servicio.
10. Versiones diferentes de paquetes instalados en los servidores de producción.
11. Sobredimensionamiento de recursos en los servidores de producción.
12. Puntos únicos de fallo sobre aplicaciones en producción, como el aplicativo CAS.
26
3. METODOLOGÍA DE IMPLEMENTACIÓN
La metodología usada para la implementación del presente proyecto, se basa en los
procesos dictados por PMBOK. Los procesos implementados en la ejecución de este
proyecto se describen a continuación.
3.1. Iniciación
Procesos realizados para definir un nuevo proyecto o una nueva fase de un proyecto ya
existente mediante la obtención de la autorización para iniciar el proyecto o fase. Dentro
de este proceso se obtiene como producto el ANEXO B: Acta de constitución de proyecto,
con lo cual se da inicio al proyecto.
3.2. Planificación
En este proceso se definen aquellos procesos requeridos para establecer el alcance,
refinar los objetivos y definir el curso de acción necesario para alcanzar los objetivos
planteados.
En esta fase se han definido los objetivos, el alcance y las limitaciones del proyecto los
cuales se han mencionado en la introducción de este documento, además como resultado
de este proceso obtenemos el cronograma de actividades.
3.3. Cronograma
La implementación de servidor de aplicaciones JBOSS modo domain para el Ministerio de
Educación del Ecuador, deberá llevarse a cabo en el plazo máximo de 2 meses, el cual se
detalla en el siguiente cronograma:
27
Figura 4 Cronograma de actividades
3.4. Ejecución
Para la comunicación y seguimiento de la implementación del proyecto se usa el correo
electrónico como método de comunicación y la Matriz RACI Migración de servicios (Anexo
C), para la coordinación del personal y distribución de tareas.
3.5. Control
Para verificar la calidad del proyecto y para minimizar el riego del mismo se realizan
pruebas de carga y estrés sobre los servidores así como la validación del funcionamiento
de las aplicaciones y pruebas de conectividad entre los servidores. Estas pruebas se
realizaron previo a la migración de las aplicaciones para garantizar la comunicación entre
los servidores de aplicaciones y lo servidores de base de datos.
28
3.6. Cierre
Para el cierre del proyecto se cuenta con la carta de aceptación del proyecto a
satisfacción (Anexo D), además se hace entrega del manual de instalación del servidor de
aplicaciones jboss modo domain (Anexo E), así como la capacitación al personal del área
de Infraestructura del Ministerio de Educación como se puede observar en el Anexo F:
Acta de capacitación nueva arquitectura de aplicaciones.
29
4. DISEÑO DE ARQUITECTURA E IMPLEMENTACIÓN DE SERVIDOR DE
APLICACIONES JBOSS MODO DOMAIN
4.1. Arquitectura de Aplicaciones
A continuación se presenta el diagrama básico de la arquitectura implementada en el
Ministerio de Educación del Ecuador para el despliegue de las aplicaciones.
Figura 5 Arquitectura de Aplicaciones Ministerio de Educación
Elaboración: Verónica Parra
30
En la figura 5. Arquitectura de Aplicaciones Ministerio de Educación, se observa tres
capas: tecnología, administración y aplicación; la capa de tecnología contiene los
servidores de aplicaciones y servidores web así como también la discriminación de la
transaccionalidad entre redes.
La capa de administración muestra la comunicación que existe entre el balanceador web y
los host controller a través del protocolo ajp y la consola de administración de domain
controller; y en la última capa se encuentran los servicios que dispone el usuario final,
levantados en la arquitectura descrita.
Con esta arquitectura se trata de agrupar lo servidores que contienen iguales
características de servicios en un misma red, garantizar la homogeneidad en la
configuración de los servidores de aplicaciones, realizar upgrade de la versión del
servidor de aplicaciones jboss así como del jdk, presentar las aplicaciones por un solo
dominio servicios.educacion.gob.ec, evitar la saturación del aplicativo CAS, realizando
cambio en código que permita el despliegue de este aplicativo en más de un servidor de
aplicaciones; estandarizar los parámetros de configuración de las aplicaciones, evitando
tener direcciones ip en código, así como facilitar la administración de las aplicaciones.
4.1.1. Despliegue de Aplicaciones
El despliegue de las aplicaciones se realiza en el servidor de aplicaciones JBoss EAP 6.4
en Modo Domain, de forma que se tiene un punto central de administración denominado
Domain Controller, desde el cual se gestionan todos los servidores que albergan las
aplicaciones. A éstos se los denomina Host Controller.
En la arquitectura propuesta se dispone de veinte servidores JBoss EAP 6.4 que actuaran
como Host Controllers, mismos que se registran a un Domain Controller Primario. Para la
alta disponibilidad de la administración de los servidores se cuenta con un Domain
Controller secundario, mismo que tomará el control de la administración en caso de que el
primer Domain Controller falle.
31
Los servidores que actúan como Host Controller disponen de 2 tarjetas de red: una en la
red 10.200.2.0/24 y otra en la red 10.200.4.0/24.
La primera interfaz es utilizada para la comunicación con el esquema de balanceo de
carga. La segunda interfaz, es usada para la administración, comunicación con las bases
de datos y el domain controller, con esto se implementa una red de administración de
servidores, a la cual solo tiene acceso personal autorizado.
4.1.2. Balanceo de Carga
El esquema de balanceo de carga cuenta con 8 servidores Web, donde se tiene instalado
y configurado apache web 2.4 con el módulo de balanceo mod_cluster, el cual ya viene
integrado a JBoss 6.4. La ventaja de esta implementación es que el factor de balanceo se
calcula en base al estado de cada nodo a ser balanceado, realiza un autodiscovery de
nodos, permitiendo levantar nodos dinámicamente en base a la demanda.
Éstos 8 servidores se comunican con los servidores de aplicaciones levantados en los
Host Controllers. Ésta comunicación se lo realiza por la red 10.200.2.0/24.
La publicación de las aplicaciones a internet se lo realiza mediante el equipo de red WAF,
mismo que se conecta a los 8 servidores Web.
4.2. Etapas de la Instalación y trabajos realizados
El proceso de instalación se realizó en tres etapas.
4.2.1. Primera Etapa
La primera etapa de implementación del servidor de aplicaciones jboss modo domain
consistió en la instalación y configuración de servidores como se enlista a continuación:
Instalación de servidores de aplicaciones JBoss EAP: para facilitar la instalación de
los servidores, se implementó un repositorio local, en el cual se colocó plantillas de
instalación, facilitando la instalación del sistema operativo, instalación y actualización de
los paquetes o programas.
32
Figura 6 Repositorio RELV7 (MINEDUC)
Configuración de servidor de aplicaciones en Modo Domain: finalizada la instalación,
se procedió con el cambio de la nomenclatura de las interfaces de red de los servidores
ya que la versión del sistema operativo instalado Red Hat 7 asigna identificadores
estables a las interfaces de red basándose en el tipo (local Ethernet, WLAN, WWAN), por
ejemplo: enp0s3 y cambiarla a la nomenclatura habitual eth0, evitando así problemas de
comunicación de los Host Controllers con el Domain Controller. A continuación se muestra
la configuración de interfaces de escucha.
Las aplicaciones se desplegarán en los Servers, mismos que deben ser agrupados
mediante la creación de los Server Groups. Los Servers de un Server Group comparten
el mismo perfil de configuración, aplicaciones desplegadas y socket bindings. En este
punto se realizó la creación y configuración de los sever Group.
<interface name="public">
<nic name="eth0"/>
</interface>
<interface name="management">
<nic name="eth1"/>
</interface>
33
Figura 7 Configuración Domain Controller
.
Todas las aplicaciones necesitan el jar seguridades-educacion-ejb.jar que se encuentra
en el ear de la aplicación seguridades educación para su despliegue, por lo que es
necesario desplegar este aplicativo en conjunto con cada aplicación, lo que ocasiona que
al tener 15 server group con mínimo tres server por cada server group, tendríamos
desplegada la aplicación seguridades en 45 servers, al existir algún inconveniente en
esta aplicación se debe realizar un revisión en 45 server ocasionando una carga de
trabajo para el administrador de los servidores de aplicaciones, para solventar este
inconveniente se realizó la creación de un perfil ha-seguridades.
SERVER GROUP
34
Figura 8 Perfil Domain Controller
Con el fin de evitar que el contexto de la aplicación seguridades sea publicado en 45
server, ya que las demás aplicaciones se encuentran en el perfil ha en este perfil, se
excluyó la lectura del contexto seguridades-educacion-web por el mod cluster como se
puede observar en la Figura 8. Perfil Ha Domain Controller, así para acceder a la
aplicación seguridades se lo realizara por el perfil ha-seguridades el cual tendrá un server
group con tres servers.
Figura 9 Perfil ha Domain Controller
35
Tabla 4. Distribución de aplicaciones MINEDUC
Server Group Perfil de
Configuración
Port Offset
para
servidores
Nombre de Servidores
Cas ha 0 server-cas
Asignación-cupos ha 51 server-asignacion-cupos
Geol ha 100 server-geol
Gestión docente - modulo th ha 150 server-gestion
Inscripciones ha 200 server-inscripciones
Méritos-oposiciones ha 250 server-meritos-oposiciones
Titulación ha 300 server-titulacion
Titulación 25 ha 350 server-titulacion25
Geoserver ha 400 server-geoserver
Jasper ha 450 server-jasper
Activos ha 500 server-activos
Institución educativa ha 550 server-institucion
Beet ha 600 server-beet
Seguridad ha-
seguridades
650 server-seguridad
Fsac ha 700 server-fsac
36
Para evitar la saturación del espacio en disco de los servidores de aplicaciones, se
implementó un servidor de logs en el cual se guardan el log de las aplicaciones y se
comprime y respalda los log con más de dos días de antigüedad usando un cron para
automatizar esta tarea.
Instalación y configuración de los servidores Web: al disponer de una gran cantidad
de host o nodos para despliegue de aplicaciones y contextos de las mismas es necesario
realizar la siguiente configuración en el archivo httpd.conf añadiendo los parámetros:
1. Maxcontext: Ese es el número máximo de contextos apoyados por
mod_cluster).Por defecto: 100
2. Maxnode: Es decir número máximo de nodos soportado por mod_cluster. Por
defecto: 20
3. Maxhost: Ese es el número máximo de host soportados por mod_cluster. Ese es
también el número máximo a ser balanceado. Por defecto: 20
Donde aumentamos el número de host de nodos y contexto. Para el cálculo del parámetro
Maxcontext se aplicó:
Configuración de un esquema de Balanceo de aplicaciones java: En los servidores
de aplicaciones JBoss EAP 6.4 se realiza la configuración del subsistema
mod_cluster para la comunicación con el servidor Web. Esto se realiza en cada perfil de
cada grupo de servidores que desean ser balanceados. Se específ ica el servidor Web y
el puerto de comunicación, como se puede observar en Figura 8. Perfil ha Domain
Controller.
Maxhost 500
Maxnode 1000
37
Afinamientos de los parámetros de JVM y sistema operativo: se realizaron Java
tuning por aplicación basado en el Java Tuning White Paper.
Para obtener más detalle sobre los procesos de instalación, referirse al manual de
instalación Anexo E.
4.2.2. Segunda etapa
En esta etapa se realizó el despliegue de las aplicaciones y pruebas de funcionalidad las
cuales se realizaron en base un cronograma de pruebas. Durante esta etapa fue
importante la participación del usuario funcional para validar el funcionamiento de la
aplicación
Las aplicaciones a ser desplegadas han sido desarrollas en java web bajo el modelo vista
controlada MVC. En general, en las aplicaciones que usan autenticación fue necesario la
edición del archivo pom.xml, realizando un upgrade al dialecto de comunicación que usan
con la base de datos Oracle y el cambio del parámetro de comunicación con el aplicativo
CAS y envió de correo. En la antigua arquitectura se colaba la dirección ip del servidor de
aplicaciones donde se encontraba desplegado CAS así como la dirección ip del servidor
de envió de correos.
Figura 10 Archivo pom.xml
38
Aplicación Jasperserver: Para el correcto despliegue de la aplicación Jasperserver se
modificó la conexión utilizada para la comunicación con la base de datos en el archivo
jsjboss7-ds.xml.
[root@server ]# unzip jasperserver.war
[root@server ]# cd jasperserver.war/WEB-INF
[root@server WEB-INF]# cat js-jboss7-ds.xml
<datasource jta="false" jndi-name="java:/jdbc/jasperserver" pool-name="jasperserver"
enabled="true" use-ccm="false">
<connection-url>jdbc:postgresql://X.X.X.X/jasperserver</connection-url>
<driver>postgres-driver</driver>
<security>
<user-name>X.X.X</user-name>
<password>X.X.X</password>
</security>
<validation>
<validate-on-match>true</validate-on-match>
<background-validation>false</background-validation>
<check-valid-connection-sql>SELECT 1</check-valid-connection-sql>
</validation>
<statement>
<share-prepared-statements>false</share-prepared-statements>
</statement>
</datasource>
</datasources>
[root@server ]# cd jasperserver.war
[root@server jasperserver.war]# zip -r jasperserver.war *
Además se realizó la configuración del módulo jaspersof:
39
jaspersoft system
[root@srvapp01 modules]# cd jaspersoft/
[root@srvapp01 jaspersoft]# ls
[root@srvapp01 batik]# cd main/
[root@srvapp01 main]# ls
batik-anim-1.7.jar batik-ext-1.7.jar batik-script-1.7.jar batik-transcoder-1.7.jar
batik-awt-util-1.7.jar batik-extension-1.7.jar batik-squiggle-1.7.jar batik-util-1.7.jar
batik-bridge-1.7.jar batik-gui-util-1.7.jar batik-svg-dom-1.7.jar batik-xml-1.7.jar
batik-codec-1.7.jar batik-gvt-1.7.jar batik-svggen-1.7.jar module.xml
batik-css-1.7.jar batik-parser-1.7.jar batik-svgpp-1.7.jar xml-apis-ext-1.3.04.jar
batik-dom-1.7.jar batik-rasterizer-1.7.jar batik-swing-1.7.jar
[root@srvapp01 main]# cat module.xml
<module xmlns="urn:jboss:module:1.1" name="jaspersoft.org.apache.batik">
<dependencies>
<module name="javax.api"/>
</dependencies>
<resources>
<resource-root path="batik-anim-1.7.jar"/>
<resource-root path="batik-awt-util-1.7.jar"/>
<resource-root path="batik-bridge-1.7.jar"/>
<resource-root path="batik-codec-1.7.jar"/>
<resource-root path="batik-css-1.7.jar"/>
<resource-root path="batik-dom-1.7.jar"/>
<resource-root path="batik-ext-1.7.jar"/>
<resource-root path="batik-extension-1.7.jar"/>
<resource-root path="batik-gui-util-1.7.jar"/>
<resource-root path="batik-gvt-1.7.jar"/>
<resource-root path="batik-parser-1.7.jar"/>
<resource-root path="batik-rasterizer-1.7.jar"/>
<resource-root path="batik-script-1.7.jar"/>
<resource-root path="batik-squiggle-1.7.jar"/>
40
<resource-root path="batik-svg-dom-1.7.jar"/>
<resource-root path="batik-svggen-1.7.jar"/>
<resource-root path="batik-svgpp-1.7.jar"/>
<resource-root path="batik-swing-1.7.jar"/>
<resource-root path="batik-transcoder-1.7.jar"/>
<resource-root path="batik-util-1.7.jar"/>
<resource-root path="batik-xml-1.7.jar"/>
<resource-root path="xml-apis-ext-1.3.04.jar"/>
</resources>
</module>
Aplicación Geoserver: Para el correcto despliegue de la aplicación se modificó la
conexión utilizada por el servidor para la comunicación con la base de datos en el
archivo datastore.xml.
[root@server ]# unzip geoserver.war
[root@server ]# cd geoserver.war/data/workspaces/min_educacion/ministerio_educacion/
[root@server WEB-INF]# cat datastore.xml
<dataStore>
<id>DataStoreInfoImpl--36a83eef:141dc2c932f:-7ffd</id>
<name>ministerio_educacion</name>
<type>PostGIS</type>
<enabled>true</enabled>
<workspace>
<id>WorkspaceInfoImpl--36a83eef:141dc2c932f:-7fff</id>
</workspace>
<connectionParameters>
<entry key="Connection timeout">20</entry>
<entry key="port">5432</entry>
<entry key="passwd">pre_QJP</entry>
41
<entry key="dbtype">postgis</entry>
<entry key="host">10.200.10.210</entry>
<entry key="encode functions">false</entry>
<entry key="validate connections">true</entry>
<entry key="max connections">1000</entry>
<entry key="database">codigo_postal</entry>
<entry key="namespace">min_educacion</entry>
<entry key="schema">public</entry>
<entry key="Loose bbox">true</entry>
<entry key="Expose primary keys">false</entry>
<entry key="Max open prepared statements">50</entry>
<entry key="fetch size">1000</entry>
<entry key="preparedStatements">false</entry>
<entry key="Estimated extends">true</entry>
<entry key="user">asignacion_cupos</entry>
<entry key="min connections">1</entry>
</connectionParameters>
<__default>false</__default>
</dataStore>
[root@server ]# cd geoserver.war
[root@server geoserver.war]# zip -r geoserver.war *
Aplicación CAS: permite tener un punto central de autorización y autenticación
para el acceso a las diferentes aplicaciones desplegadas. Sin configuraciones
adicionales la aplicación guarda su información de tickets en el servidor donde se
despliega, por lo que no es posible tener varias instancias de la aplicación CAS
levantadas.
42
Para solventar lo expuesto se realizaron varias configuraciones a nivel de servidor
y de aplicación de manera que se pueda tener alta disponibilidad mediante la
creación de varios servers con la aplicación CAS.
Para el almacenamiento de los tickets generados por la aplicación CAS se
configuró Memcached, lo que permite alojarlos en un servidor externo a la
aplicación de manera que todos los nodos que tengan levantada la aplicación CAS
puedan acceder para verificarlos previo a la autorización de un usuario. Los
cambios realizados en la aplicación son:
1. Se añadió las librerías necesarias para que CAS pueda gestionar los tickets
utilizando memcached.
Archivos: cas-server-integration-memcached-3.4.12.jar y memcached-
2.3.1.jar.
Directorio: cas-educacion.war/WEB-INF/lib
2. Se editó el archivo pom.xml, citando las dependencias requeridas:
Archivo: cas-educacion.war/META-INF/maven/ec.gob.educacion/cas-
educacion/
Líneas ingresadas:
<dependency>
<groupId>org.jasig.cas</groupId>
<artifactId>cas-server-integration-memcached</artifactId>
<version>${cas.version}</version>
<type>jar</type>
</dependency>
43
3. Se creó el archivo que hace referencia al servidor donde se alojan los
tickets:
Archivo: cas-educacion.war/WEB-INF/spring-configuration/memcached-
registry.xml
Contenido:
<?xml version="1.0" encoding="UTF-8"?>
<beans xmlns="http://www.springframework.org/schema/beans"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xmlns:p="http://www.springframework.org/schema/p"
xmlns:tx="http://www.springframework.org/schema/tx"
xmlns:jee="http://www.springframework.org/schema/jee"
xsi:schemaLocation="http://www.springframework.org/schema/beans
http://www.springframework.org/schema/beans/spring-beans-2.0.xsd
http://www.springframework.org/schema/tx
http://www.springframework.org/schema/tx/spring-tx-2.0.xsd
http://www.springframework.org/schema/jee
http://www.springframework.org/schema/jee/spring-jee-2.5.xsd">
<!-- Ticket Registry -->
<bean id="ticketRegistry"
class="org.jasig.cas.ticket.registry.MemCacheTicketRegistry">
<!-- List of hostname:port pairs -->
44
<constructor-arg index="0">
<list>
<value>srvmemcached01.infra.educacion.gob.ec:11211</value>
<value>srvmemcached02.infra.educacion.gob.ec:11211</value>
</list>
</constructor-arg>
<!-- TGT timeout in seconds -->
<constructor-arg index="1" type="int" value="21600" />
<!-- ST timeout in seconds -->
<constructor-arg index="2" type="int" value="300" />
</bean>
</beans>
4.2.3. Tercera etapa
Se consideró el tiempo de estabilización donde las aplicaciones desplegadas se
encontraron en constante monitoreo. En la antigua arquitectura no se contaba con
herramientas de monitoreo y el personal del Ministerio de Educación del Área de
Infraestructura y Comunicación debía hacer el monitoreo de forma manual y
presencial, incrementado la carga laboral fuera del horario de trabajo, por lo que
se implementó JBoss Operations Network (JBoss ON) que ofrece funciones de
control y gestión para gestionar de manera efectiva todos los entornos de
aplicaciones de JBoss.
Esto mejora la eficiencia operativa, reduce los costes y garantiza una experiencia
positiva para los usuarios finales. Para realizar el monitoreo es necesario la
45
instalación del agente JON en los servidores de aplicaciones, el cual permite
hacer un descubrimiento de las instancias de Jboss y realiza una agrupación
dinámica de los servidores con similares características. Además se procedió con
la configuración de alertas, las cuales se envían por correo electrónico al
administrador de los servidores de aplicaciones.
Durante esta etapa también se realizaron talleres de capacitación al personal del
área de infraestructura y se realizó la entrega de credenciales de administración
así como el manual de instalación (Anexo E).
46
5. RESULTADOS
En base a las estadísticas obtenidas durante las validaciones de funcionamiento
de las aplicaciones y una vez culminado el periodo de estabilización, se presentan
los siguientes resultados.
Tabla 5. Comparación de resultados
PRE IMPLENTACIÓN POS INSTALACIÓN
ACTIVIDAD RESULTADOS ACTIVIDAD RESULTADOS
Versionamiento de
aplicación por servidor 15 (minutos)
Versionamiento de
aplicación por
servidor 1 (minuto)
Indisponibilidad de
aplicación 39.5%
Indisponibilidad de
aplicación 1 %
Revisión de log por
aplicación tiempo
promedio 1 (días)
Revisión de log por
aplicación tiempo
promedio 30 (minutos)
La DNTIC en el periodo anterior a la instalación del servidor jboss modo domain
no contaba con herramientas de monitoreo, por lo que los estadísticos se ha
obtenido mediante los registros levantados en la herramienta Gobierno por
resultados GPR, así como en las herramientas de monitoreo implementadas pos
instalación y la apreciación del personal encargado de la administración de los
servidores de aplicaciones.
47
5.1. Versionamiento de las aplicaciones
Se puede observar una disminución en el tiempo empleado para el versionamiento
de las aplicaciones, gracias a la centralización de la administración, el proceso de
versionamiento no se debe realizar por cada servidor de aplicaciones, sino una
sola vez en el servidor que funciona como controlador de dominio y esta se
reaplicará a los demás servidores de forma automática.
Otra ventaja de esta implementación es que al versionar una aplicación las
además aplicaciones no son afectadas en cuanto a su funcionamiento y tiempos
de disponibilidad, ya que no es necesario reiniciar el servidor para que el
versionamiento sea efectivo.
5.2. Disponibilidad de las aplicaciones
Figura 11 Monitoreo de aplicaciones PRTG
48
Gracias a la herramienta de monitoreo Paessler Router Traffic Grapher (PRTG)
se pude validar el aumento en el porcentaje de disponibilidad de las aplicaciones
a un noventa y ocho por ciento (98%) como se pude observar en la figura 8.
Monitoreo de aplicaciones PRTG, considerando que dentro de los periodos de
indisponibilidad se encuentra el tiempo usado para el versionar la aplicación.
5.3. Independencia de log
Siendo la independencia de log de las aplicaciones uno de los principales
objetivos de este proyecto, se puede afirmar que la implementación de jboss en
modo domain ha permitido dividir el log por aplicación gracias a la creación de
varios grupos de server en un servido. Como se observa en la imagen existen
siete aplicaciones en el servidor, cada uno con su log.
5.4. Arquitectura Final
A continuación en la Figura 12. Arquitectura Ministerio de Educación y Cultura
(MINEDUC, 2016), donde podemos observar la simplificación de la arquitectura,
unificando los servidores con similares características en una sola red.
49
Figura 12 Arquitectura Ministerio de Educación del Ecuador (MINEDU, 2016)
10.253.253.14
INTERNET
ENLACE DATOS
FW MINEDUC
10.40.41.8Red
10.200.2.0/2410.200.4.0/24
181.113.66.27/26
40 Mbps
100 Mbps
FW_PERIMETRAL181.113.66.27
FW DMZ10.200.4.246
172.30.100.5 172.30.100.3RED-DMZ172.30.100.0/24
10.200.4.246
10.200.2.246
10.200.5.246
FW_PERIMETRALCONEXIÓN TEMP
181.116.66.4
FW_DESARROLLORED 40/41
CONEXIÓN TEMP181.116.66.21
10.200.41.246
GRP_JBOSS_RED_4
GRP_APACHE_RED_2
FW_BDD_02CONEXIÓN TEMP
10.200.5.240
10.200.5.240
10.200.5.10610.200.5.108
10.200.41.101
10.200.1.10110.200.1.10210.200.1.103
Ip route add 10.200.4.0/24 via 10.200.5.246
Ip route add 10.200.4.0/24 via 10.200.5.246
route –p 10.200.4.0/24 10.200.1.246
route –p 10.200.4.0/24 10.200.1.246
route –p 10.200.4.0/24 10.200.1.246
Servicios.educacion.gob.ec ; 181.113.66.17
SRV_JBOSS_RED_2
10.200.7.246
10.200.7.1
10.40.41.4
10.200.6.1
GATEWAY 172.30.100.5
RED10.200.3.0 /24
10.200.6.1
SRV_IDM_RED_4
Puertos IDM
CORREO
PORTALES
REPOSITORIO LOCAL
SERVIDOR DE MONITORO JON
REPOSITORIO LOCAL
SERVIDOR DE MONITOREO PRTG
50
6. CONCLUSIONES Y RECOMENDACIONES
6.1. CONCLUSIONES
1. Al centralizar la administración de aplicaciones, se viabiliza la escalabilidad
de los servidores bajo demanda, lo que permite el crecimiento en el número
de servidores de aplicaciones en momentos de alta transaccionalidad
asegurando la disponibilidad de las aplicaciones.
2. La descentralización de los logs, es un aspecto clave para la mejora en los
tiempos de resolución de los incidentes presentados, ya que agilita las
búsquedas de los errores presentados por aplicación.
3. El concepto de balanceador de carga es una solución viable, ya que permite
delegar la carga de trabajo de manera eficiente.
51
6.2. RECOMENDACIONES
1. Una de las desventajas de esta arquitectura es que al tener un solo
controlador de dominio, siendo este un punto de falla, es decir que en el
evento en el que este falle, no se va a tener una alta indisponibilidad, por lo
que se recomienda usar mecanismos de replicación, para que en el caso de
falla, un controlador de dominio secundario asuma las funciones del
controlador de dominio primario.
2. Se recomienda la implementación de algún aplicativo que permita el manejo
de rol y reglas de seguridad para el acceso a los servidores, considerando
las normas básicas de seguridad informática.
3. Se recomienda el planificar una migración de java JDK 1.7 a JDK 1.8 ya
que la versión actualmente usada JDK 1.7 se descontinuará en menos de
un año, para esta actualización se debe realizar un estudio de
compatibilidad de las librerías usadas actualmente por las aplicaciones.
52
BIBLIOGRAFÌA
1. EPIDATA. (2014/10/ 07 . Epidata. Recuperado el 22 de 02 de 2016, de
Epidata: http://www.epidataconsulting.com/tikiwiki/tiki-
print.php?page=JBoss7
2. INC., R. H. (2014). Plataforma de Aplicaciones Emplesariales Jboss 6.3
Guia de Instalacion. Estados Unidos.
3. JBOSS.ORG. (S.F.). Recuperado el Diciembre de 2014, de
http://docs.jboss.org/mod_cluster/1.2.0/html/
4. ORACLE CORPORATION. (2013, Noviembre). Recuperado el Diciembre
de 2014, de https://glassfish.java.net/roadmap.html
5. ORACLE CORPORATION. (2013, Noviembre ). Recuperado el Diciembre
de 2014, de Legal information: https://glassfish.java.net/license.html
6. ORACLE CORPORATION. (2014). Java Documentation. Recuperado el
Noviembre de 2014, de https://docs.oracle.com/javaee/7/firstcup/java-
ee002.htm
7. PALACIO, D., & ABRIL, A. (2012, Noviembre). Introducción al Balanceo de
Carga en Aplicaciones Web. Recuperado el Diciembre de 2014, de
https://redesocialespaldava.files.wordpress.com/2012/11/articulo.pdf
53
8. RED HAT, INC. (2014). Red Hat Customer Portal. Recuperado el
Noviembre de 2014, de https://access.redhat.com/documentation/en-
US/JBoss_Enterprise_Application_Platform/6.3/html/Getting_Started_Guide
/chap-Introduction.html#About_JBoss_Enterprise_Application_Platform_6
9. REINOSO, A. C. (2013). La Educación en el Ecuador.
10. UNIVERSIDAD AUTONOMA DE BAJA CALIFORNIA. (2004). Servidor
Yaqui. Obtenido de
http://yaqui.mxl.uabc.mx/~larredondo/distribuidas/IntroJ2EE.html
11. UNIVERSIDAD DE ALICANTE. (2003). Experto Java. Recuperado el
Diciembre de 2014, de http://www.jtech.ua.es/j2ee/2003-2004/abierto-j2ee-
2003-2004/sa/sesion1-apuntes.htm
12. ZATTOLA, R. (2014). Introducción Básica a aplicaciones Web en Java.
Recuperado el Diciembre de 2014, de
http://es.slideshare.net/rodrigozeta/intro-aplicaiones-web-java-j2ee-parte-
uno-rodrigo-zottola
54
ANEXOS
ANEXO A. CARTA DE SOLICITUD DE IMPLEMENTACIÓN DE PROYECTO
MINISTERIO DE EDUCACIÓN
55
56
ANEXO B. Acta de constitución de proyecto
57
58
59
60
61
ANEXO C. RACI usada para la implementación de servidor de aplicaciones
jboss modo domain
62
63
64
ANEXO D. Certificación de satisfacción de entrega de proyecto Ministerio de
Educación
65
66
ANEXO E. Manual de instalación
Manual de Instalación
SERVIDOR DE APLICACIONES JBOSS MODO DOMAIN
INF-MINEDU-ARQ-FEB2016
Versión: 1.0
Preparado por: VERÓNICA PARRA
QUITO – ECUADOR
2016
67
Trabajos realizados
Los trabajos realizados durante la implementación del servidor de aplicaciones
jboss modo domain se listan a continuación:
1. Instalación de servidores de aplicaciones JBoss EAP.
2. Configuración de servidor de aplicaciones en Modo Domain.
3. Instalación y configuración de los servidores Web.
4. Configuración de un esquema de Balanceo de aplicaciones java.
1. Instalación de Domain Controller: el sistema operativo usado en todos los
servidores es RHEL 7. Esta instalación se realizó por medio de plantillas de
instalación kickstart. Para despliegue del servidor de aplicaciones es
necesario la instalación de java developer kit, para este caso se implementó
el JDK de Oracle.
2. Instalación de Java Oracle 1.7.0:
[root@srvdcY ~]# yum install -y java-1.7.0-oracle java-1.7.0-oracle-devel
3. Para la instalación de paquetes de Jboss se debe ejecutar el comando:
68
[root@srvdcY ~]# yum install -y jbossas-appclient jbossas-bundles jbossas-core
jbossas-domain jbossas-hornetq-native jbossas-jbossweb-native jbossas-modules-
eap jbossas-product-eap jbossas-standalone jbossas-welcome-content-eap
1. Configuración de Domain Controller: Los servidores de aplicaciones JBoss
EAP 6.4 levantados en Modo Domain estarán configurados de manera de que, en
caso de que el servidor que actúa con Domain Controller Primario se vea
afectado, los servidores de aplicaciones JBoss EAP 6.4 levantados como Host
Controller se registren con el servidor que actúa con Domain Controller
Secundario.
Para que no se tengan problemas de inconsistencia de configuraciones en los
nodos es necesario que el Domain Controller Secundario tenga sincronizado su
archivo domain.xml y la carpeta content con respecto al Domain Controller
primario.
Ésta sincronización se la manejará mediante un cron que copie los archivos desde
el Domain Controller Primario al Domain Controller Secundario el cual se muestra
a continuación:
[root@srvdcY ~]# crontab -e
* * * * * /bin/rsync -av /etc/jbossas/domain/domain.xml
srvdc2:/etc/jbossas/domain/domain.xml
69
* * * * * /bin/rsync -av /usr/share/jbossas/domain/data/content
srvdc2:/usr/share/jbossas/domain/data/content
Para que los cambios provistos del servidor Domain Controller Primario sean
aplicados, es necesario la recarga de las configuraciones en el Domain Controller
Secundario, por lo que se crea un cron que recargue el servicio cada minuto
mediante CLI:
[root@srvdcX ~]# crontab -e
* * * * * /HOMEJBOSS/bin/jboss-cli.sh --connect –controller=x.x.x.x:9999 --
file=/root/reload.cli
[root@srvdc2 domain]# cat /root/reload.cli
batch
reload --host=master
run-batch
En cuanto a la administración de la Arquitectura del Servidor de Aplicaciones la
administración se la debe hacer en el servidor Domain Controller Primario. En
caso de que por alguna circunstancia se realicen cambios utilizando la consola del
servidor Domain Controller Secundario, éstos deben ser replicados en el Primario
de forma manual.
70
La configuración en los servidores que actúan como Domain Controller
básicamente consiste en levantar los dos servidores con la misma configuración.
En el caso de los servidores Host Controllers la configuración contemplará los
servidores Domain Controllers Primario y Secundario.
El procedimiento detallado a continuación se debe realizar en los servidores que
actúan como Domain Controller Primario y Domain Controller Secundario. El
directorio utilizado para la configuración del servidor de aplicaciones JBoss EAP
6.4 en Modo Domain es /HOMEJBOSS/jbossas/domain:
[root@srvdcY domain]# ls
configuration data log servers tmp
Las configuraciones para que el servidor de aplicaciones JBoss se ejecute como
Domain Controler se lo realizan en el directorio configuration:
Se crea el archivo host-master-minedu.xml mismo que se basa en las
configuraciones del archivo plantilla host-master.xml. Éste archivo es usado para
la configuración de la comunicación del Domain Controller con los Host
Controllers.
El cambio realizado en el archivo es la configuración de la dirección IP de escucha
para la comunicación con los Host Controllers:
<inet-address value="${jboss.bind.address.management:x.x.x.x}"/>
71
En el archivo domain.xml se tiene la información de los perfiles usados para la
configuración de los grupos de servers donde se despliegan las aplicaciones. El
log utilizado para revisar el estado del Domain Controller es host-controller.log.
Para el acceso a las consolas de administración es necesario crear un usuario,
para crearlo se debe ingresar el directorio HOMEJBOSS/bin y ejecutar el scrip
./add-user.sh y colocar la información solicitada.
El link de acceso a la consola de administración es http://ipservidor:9990
Figura 5. Consola de administración Domain Controller
2. Configuración de Host Controller: Las configuraciones para que el servidor
de aplicaciones JBoss se ejecute como Host Controler se lo realizan en el
directorio /HOMEJBOSS/domain/configuration.
Se crea el archivo host-slave-minedu.xml mismo que se basa en las
configuraciones del archivo plantilla host-slave.xml. Éste archivo es usado para la
72
configuración de la comunicación de los Host Controllers con el Domain Controller.
A continuación se muestra la configuración de interfaces de escucha.
<interface name="public">
<nic name="eth0"/>
</interface>
<interface name="management">
<nic name="eth1"/>
</interface>
En el mismo archivo se realiza la configuración para la comunicación con el
domain controller primario y secundario dentro del parámetro domain-controller
El log utilizado para revisar el estado del Host Controller es host-controller.log. En
<domain-controller>
<remote security-realm="ManagementRealm" username="JBossHostControllers">
<discovery-options>
<static-discovery name="primary" host="hostname o ip del domain controller
primario” port="${jboss.domain.master.port:9999}"/>
<static-discovery name="backup" host=" hostname o ip del domain controller
primario " port="${jboss.domain.master.port:9999}"/>
</discovery-options>
</remote>
</domain-controller>
73
caso de que el Domain Controller Primario se vea afectado la reconexión del Host
Controler al Domain Controller Secundario se registrará en este archivo.
Esta configuración se realiza en todos los servidores que servirá como Host
Controller.
3.2.4 Creación de server Group y Servers: Las aplicaciones se despliegan en
los Servers y estos son agrupados mediante la creación de los Server Groups.
Los Servers de un Server Group comparten el mismo perfil de configuración, JVM,
aplicaciones desplegadas y socket bindings.
La creación de los Server Groups se lo realiza en la pestaña Domain en la opción
Server Groups. La información solicitada es:
1. Nombre del Grupo.
2. Perfil de Configuración.
3. Socket Binding.
74
Figura 6. Consola de administración Domain Controller Create Server
Group
La creación de los server se lo realiza en la pestaña Domain en la opción Server
Configurations como se muestra en la Figura 6. Consola de administración
Domain Controller Create Server Group, se debe tener en cuenta que en el Host
Controller se desea ubicar el server creado, éste es escogido en la opción Host.
La información solicitada es para la creación de un server en un Host Controller
es:
1. Nombre del server.
2. Server Group al que va a pertenecer.
3. Port Offset, que permite incrementar el valor deseado a los puertos por
defecto del Socket Binding.
75
4. Auto Start, que permite al servidor ser iniciado al levantar el Host Controller
que lo alberga.
Figura 7. Consola de administración Domain Controller Create Server
configuraction
Una vez que el server es creado debe ser iniciado. En la pestaña Domain en la
opción Overview se tiene un perspectiva de cómo se encuentran distribuidos los
servidos en una matriz Server Groups vs Host Controllers como se muestra en la
figura 8. Consola de administración Domain Controller Create Topology.
76
Figura 8. Consola de administración Domain Controller Create Topology
3. Despliegue de aplicaciones: antes del despliegue de aplicaciones es
indispensable la configuración de los datasources para lo cual se instala Java
Database Connectivity (JDBC) para esto se debe desplegar él .JAR como si
realizara el despliegue de una aplicación este se encarga de enviar comandos
SQL hacia una base de datos esta puede ser Oracle, mysql o postgres. Este
método es particularmente útil cuando se ha configurado el servidor como
Dominio, el despliegue es automáticamente propagado a todos los servidores.
Después de esto configuración procedemos con la creación de los datasources,
seleccionamos en la consola de administración Configuration, seleccionamos el
perfil y la opción add y datasources registramos la información solicitada.
1. Name
77
2. Jndi-name
3. Connection-url
4. Driver-class
5. User-name
6. Password
Figura 9. Consola de administración Domain Datasources
Para validar que la configuración del datasources sea correcta se debe realizar un
test de conexión como se muestra en la figura 10. Consola de Administración Test
de Conexión Base de Datos.
78
Figura 10. Consola de Administración Test de Conexión Base de Datos
Si no hay problema de conectividad entre los servidores de aplicaciones y la base
de datos y el datasources se mostrara el mensaje “successfully created JDB
connection”.
El despliegue de aplicaciones se realiza por medio de la consola de
administración, seleccionamos en el menú la opción Deployments.
79
Figura 11. Consola de administración Domain Despliegue de Aplicaciones
Add
Como podemos observar en la Figura 9. Consola de administración Domain
Despliegue de Aplicaciones, seleccionamos la opción add e indicamos la
dirección donde se encuentra el empaquetado de la aplicación que se desea
desplegar.
80
Figura 12. Consola de administración Domain Despliegue de Aplicaciones
Assing
Una vez almacenado el empaquetado de debe asignar el mismo a un server group
para esto seleccionamos la opción assing y seleccionamos el sever group donde
esta aplicación se desplegara.
1. Instalación Servidor Web: Una vez instalados y configurados los servidores
de aplicaciones JBoss se realiza el balanceo de las aplicaciones
desplegadas. Para lo cual se instala un servidor Apache Web con el módulo
de balanceo mod_cluster.
Instalación del paquete httpd.
81
[root@srvweb01 ~]# yum install -y httpd22 mod_cluster-native mod_ssl22
Configuración de Módulo de Balanceo: Las configuraciones del módulo de
balanceo del servidor web se alojan en el archivo
/etc/httpd22/conf.d/mod_cluster.conf. En el archivo se deben realizar las siguientes
configuraciones:
2. Cargar módulos requeridos:
LoadModule proxy_cluster_module modules/mod_proxy_cluster.so
LoadModule slotmem_module modules/mod_slotmem.so
LoadModule manager_module modules/mod_manager.so
LoadModule advertise_module modules/mod_advertise.so
3. Directorio para la generación de keys para la memoria compartida.
MemManagerFile /var/cache/mod_cluster
4. Configuración de puerto de escucha y permisos de acceso al servidor web:
82
<IfModule manager_module>
Listen XXXX
<VirtualHost *:XXXX>
<Directory />
Order deny,allow
Allow from all
</Directory>
5. Permite la comunicación de los nodos JBoss EAP con el servidor Web:
ServerAdvertise off
EnableMCPMReceive
6. Configuración de la consola de monitoreo del balanceo
<Location /mod_cluster_manager>
SetHandler mod_cluster-manager
Order deny,allow
83
#Deny from all
Allow from all
</Location>
</VirtualHost>
</IfModule>
En los servidores de aplicaciones JBoss se realiza la configuración del subsistema
modcluster para la comunicación con el servidor Web. Esto se realiza en cada
perfil de cada grupo de servidores que desean ser balanceados en el path /JBOSS
HOME/configuration/domain.xml.
7. Se especifica el servidor Web, el puerto de comunicación:
<mod-cluster-config advertise-socket="modcluster" proxy-list="host name o
dirección ip del servidor web " advertise="false" connector="ajp">
Los servidores de aplicaciones deben ser reiniciados para que el cambio tenga
efecto.
Una vez que se encuentren realizadas todas las configuraciones indicadas, se
presentan los nodos balanceados en el link
http://x.x.x.x:XXXX/mod_cluster_manager.
84
Al ser efectiva la configuración, se observa el contexto de las aplicaciones
desplegadas en los servidores jboss, como se puede observar en la Figura 10.
Balanceador Web Mod Cluster Manager, los contextos de las aplicaciones son
reconocidas de forma automática.
Figura 13. Balanceador Web Mod Cluster Manager
85
ANEXO F. Listado de asistencia a la capacitación - acta de reunión