Diseño e Implementación de una Infraestructura Auto escalable y de Alta

Disponibilidad para asegurar la calidad de Aplicaciones Web. Caso de estudio:

Universidad Nacional Mayor de San Marcos

Geinner K Tucto-Huaripata, Luis A Alarcón-Loayza

Facultad de Ingeniería de Sistemas e Informática, Universidad Nacional Mayor de San Marcos, Lima, Perú
geinertucto@gmail.com, lalarconl10@gmail.com

Resumen: El desarrollo de aplicaciones web aumentó considerablemente en los últimos años debido a sus grandes ventajas
respecto a las aplicaciones desarrolladas para entornos de escritorio. Sin embargo hoy en día muchas de las aplicaciones se
ven afectadas ante la aleatoria concurrencia de usuarios que en situaciones especiales ocasionan picos de demanda y
sobrepasan la capacidad del hardware en donde se ejecutan, trayendo serias consecuencias como: largos tiempos de
respuesta y baja disponibilidad. Por ello el presente trabajo se enfoca en el diseño e implementación de una infraestructura
auto escalable para asegurar alta disponibilidad y alto rendimiento de las aplicaciones web de la UNMSM. Con esta finalidad
se realizó inicialmente una investigación de la literatura para conocer los avances en diferentes contextos del tema, luego se
analizaron las necesidades de las aplicaciones a ser soportadas por esta infraestructura. Con ello se procedió a definir y
seleccionar herramientas para diseñar, implementar y validar la infraestructura. Como resultado se logró una infraestructura
auto escalable cumpliendo los atributos de calidad planteados en la ISO 9126-1 y brindar alta disponibilidad y mejor calidad
de servicio a los usuarios de la UNMSM. Con esta solución hemos concluido que para que las aplicaciones web logren tener
alta performance mucho dependerá del buen diseño de la infraestructura que la soporta.

prevista y hoy en día se ven afectadas las aplicaciones, al no

1. Introducción
En la última década la UNMSM viene utilizando
sistemas web debido a que estos ofrecen servicios en línea
con diferentes propósitos y poseen grandes ventajas con
respecto a las aplicaciones desarrolladas para entornos de
escritorio, como portabilidad, accesibilidad, desarrollo
multiplataforma, etc. Estos sistemas son desplegados en
servidores que permiten que los usuarios finales puedan
realizar sus actividades con normalidad; sin embargo en
algunos de estos la demanda de transacciones usuarias
aumenta periódicamente, esto provoca que los sistemas
mencionados sufran de intermitencia, baja calidad de
servicio, baja disponibilidad, alto consumo de recursos,
largos tiempos de respuesta, etc. Esto a su vez trae
consecuencias más relevantes como la baja confiabilidad de
los usuarios finales y desprestigio del área informática de la
organización. Ante los sucesos mencionados anteriormente,
los administradores de estos sistemas evitan o simulan
arreglar la situación aumentando recursos de hardware en
exceso ante los picos de demanda y/o realizando un
mantenimiento ante las caídas de estos servicios. Sin embargo
se trata de una manera muy costosa y de una tarea en la cual
se emplea mucho tiempo, para el área tecnológica, y peor aun
cuando esto afecta a los usuarios ya que durante ese lapso de
tiempo los sistemas se encuentran no disponibles. Es de vital
importancia la alta disponibilidad de algunas aplicaciones que
son el core del negocio. Por ejemplo en la UNMSM, la
disponibilidad que debe tener el Sistema Único de Matrículas
(SUM) durante épocas de matrícula.
En algunas aplicaciones web de la UNMSM los
requerimientos no funcionales (atributos de calidad o
restricciones del producto) no han sido tomados en cuenta,
es por ello que la infraestructura para alojarlas ha sido mal
ofrecer los niveles de servicio que demandan los usuarios.
Considerando que las aplicaciones ya se encuentran
desarrolladas y funcionando en producción, el presente
artículo resume una propuesta de solución que permita
implementar una infraestructura auto escalable para aumentar
el rendimiento y disponibilidad de las aplicaciones existentes
y de los futuros sistemas que se implementen en la UNMSM.
El presente trabajo de investigación está organizado de
la siguiente manera: en la sección II se presenta la revisión de
la literatura realizada. En la sección III se presenta el aporte
que contiene la metodología, arquitectura y herramientas para
implementar la solución propuesta. La sección IV
revisaremos las validaciones realizadas con la finalidad de
corroborar el cumplimiento de los objetivos propuestos del
trabajo. Finalmente en la sección V presentaremos las
conclusiones.
2. Estado del Arte
El objetivo principal en esta sección es la revision de
la literatura existente relativa a Metodologías, Arquitecturas
y Herramientas de software para el diseño e implementación
de Infraestructuras auto escalables y de alta disponibilidad
que resuelvan el problema. Se analizarán aquellas que se
utilizaran como base para el desarrollo de la propuesta que se
plantea.
2.1. Metodologías
En la literatura revisada cada autor utiliza una
metodología específica para definir e implementar su
propuesta. En [1] Sanmiguel A. Gutiérrez, utiliza el modelo
en cascada como metodología para desarrollar el sistema de
alta disponibilidad, esta metodología ordena rigurosamente
las etapas del proceso de desarrollo, de este modo cada etapa

1
debe esperar la culminación de la etapa anterior. Con esta Para elegir la metodología a utilizar en este trabajo, se realizó
metodología se ha logrado cumplir los objetivos expuestos en una evaluación comparativa de las metodologías
el estudio de viabilidad; sin embargo la planificación se ha mencionadas, como se indica en la siguiente cuadro (ver
visto truncada a último momento puesto que la fecha de Tabla I) decidiéndose utilizar la metodología Top Down en la
entrega real es posterior a la deseada, esto debido a la poca fase de desarrollo de la solución, también se decidió
flexibilidad que brinda dicha metodología. combinarla con técnicas experimentales y comparativas que
nos permitan validar nuestra solución.
Otra metodología típica para este tipo de temas es la
experimental usada en [2] por Alfredo Miguez, que es
Tabla 1 Evaluación de las Metodologías
complementada con metodologías comparativas y
estadísticas. El combinar estas metodologías le ayuda a Combinación
Alfredo Miguez probar y validar la solución que él propone. Factor de Top (análisis,
N° Cascada Cuantitativa
El método cuasi experimental es particularmente útil para Análisis Down comparativa,
estudiar problemas en los cuales no se puede tener control estadística)
Adaptable sobre
absoluto de las situaciones, pero se pretende lograr el mayor 1 cualquier 3 2 3 2
control posible. Algunas de las técnicas mediante las cuales proyecto
se puede recopilar información en un estudio cuasi 2 Flexibilidad 1 2 3 2
experimental son las pruebas estandarizadas, las entrevistas, Comunicación
3 2 3 2 3
las observaciones, entre otras. con el cliente.
Tiempo en el
Luis Felipe y Darin Jairo utilizan una metodología en 4 2 2 3 3
análisis y diseño
[3] que busca proponer una solución para pequeñas y 5
Tiempo en
2 2 3 2
medianas empresas basada en una arquitectura de alta construcción
disponibilidad y tolerancia a fallos; en esta investigación se 6 Monitoreo 2 0 3 0
basan fundamentalmente en el concepto de redundancia, con Facilidad de
7 3 2 3 1
seguimiento
la cual buscan duplicar sus elementos críticos y disponerlos
TOTAL 15 13 20 13
de manera redundante ya sean elementos de software o
*Elaboración Propia
hardware que cooperan entre sí. Para realizar el desarrollo
del trabajo los autores utilizan una metodología Top Down,
2.2. Arquitecturas
la cual guía el diseño de soluciones empresariales basadas en
redes confiables, seguras y administrables; la estructura de la Cali Nieto Fabián Vinicio en [5] determina que es
metodología se muestra en la Fig. 1. necesario implementar un clúster a nivel de servidor de
aplicaciones el cual contara con un balanceo de carga. El
balanceador de carga se encargara de distribuir las peticiones
HTTP y recibir respuestas directamente. Cuando el
balanceador de carga direcciona una petición desde un cliente
al nodo A, el servidor inicia una sesión y todas las futuras
peticiones asociadas con esta sesión deben ser direccionadas
al nodo A. La replicación de estado es manejada por el
servidor de aplicaciones JBoss.
Alfred Gutiérrez en [1] indica que el clúster debe tener un
sistema de comunicación, el software del clúster. Entre hosts
para su correcta monitorización, así como un método para
abstraer los servicios de un host concreto, cosa que permite
que se desplacen entre diversos nodos de manera transparente
para la aplicación y los usuarios. Para el presente trabajo la
configuración de los nodos en clúster está realizada de modo
activo/pasivo. En esta configuración todos los nodos del
clúster pueden ejecutar los mismos recursos simultáneamente
de modo que si uno falla y deja de estar disponible, sus
Fig, 1 Metodologia Top Down recursos siguen estando accesibles a través de los otros nodos
del clúster.
En [4] Mireles, Jhonangel y Maldonado, Javier en noviembre
del 2014, tiene por finalidad diseñar un clúster orientado a La arquitectura que plantea Lenin Alcántara en [6] está
servicios para aplicaciones web en la Universidad Nacional conformada por un nodo master o nodo maestro, conocido
Experimental del Táchira y Para lograr el objetivo se como server1, nodo Standby que actúa como suplente del
emplearon metodologías cuantitativas y se aplicaron una serie master y nodos de cómputo (esclavos), nodos esclavos cuya
de casos en un ambiente de prueba; así como también, se función principal es servir las páginas web del clúster. Al
analizaron ciertas métricas sobre el clúster formado por un finalizar esta implementación de un Clúster de Alta
grupo de nodos de base de datos y un grupo de nodos Disponibilidad con Equilibrado de Carga, se da por sentada la
frase que dice: “Mientras más, mejor”, lo cual creemos que es
servidores web, en una arquitectura orientada a la alta
bastante subjetivo y no necesariamente tiene que ser así.
disponibilidad. Los valores obtenidos demostraron que
existen métricas en las que la utilización del clúster se traduce La arquitectura que plantean en [7], para realizar la
en mejores resultados. solución de alta disponibilidad consta de dos servidores, en
cada uno de estos servidores físicos se encuentran 2 servidores
2
virtuales, uno para la base de datos y otro para las aplicaciones.
Los dos servidores de bases de datos instalados conforman el
clúster de base de datos los cuales tienen una IP en común
denominada IP virtual, a través de la cual los servidores web
se conectan a ellas. Los otros dos servidores web forman el
clúster de servidores web, que de igual modo tienen una IP
virtual que permite que los clientes puedan acceder a los
servicios web.
En [8] Acero Quilumbaquin descarta implementar un
clúster de tipo activo/pasivo y de failover compartido, ya que
se desperdicia recursos en ambos casos. En cambio en clúster
de tipo activo/activo, todos los nodos del clúster se encuentran
trabajando y son capaces de ejecutar recursos y a la vez
funcionar como respaldo en caso de que alguno falle.
Como lo dijimos desde el principio el aporte del presente
trabajo de investigación es la revisión de las literaturas y según
eso tomar lo mejor de cada literatura revisada y mejorar las
soluciones que se han venido dando hasta el momento, por ello
para la elección de la arquitectura de nuestra solución hemos
combinado las que se presentaron anteriormente y hemos
evaluado la mejor, con la finalidad de dar la mejor solución al
problema planteado. En la fig. 3 se puede observar de manera
general la arquitectura que tomaremos en nuestra solución, la
cual básicamente utiliza virtualización de servidores y
balanceo de carga, el nodo principal y la réplica de este será
del tipo activo-activo.
Fig. 2 Arquitectura de la solucion
2.3 Herramientas tecnológicas
En las literaturas revisadas los autores han trabajado con
distintas herramientas para lograr la solución al problema que
plantean, la mayoría de estas herramientas son software los
cuales permiten y facilitan ciertas cosas como el balanceo de
carga, virtualización, etc. Vamos a revisar lo más relevante
de lo encontrado.
En [5] para lograr el balanceo de carga es implementado
utilizando la plataforma mod_jk el cual es un módulo de
Apache Tomcat, el servidor de aplicaciones es un Jboss el
cual corre sobre un Red Hat Enterprise que tiene incluido
Open JDK versión 6.
Alfredo Miguez en [2] realiza una evaluación de las
distintas distribuciones de Linux en la cual selecciona Centos
en su versión 5, ya que es de libre costo y se adapta a su
solución, la elección del proxy también es de suma
importancia para Miguez y se basa en que sea compatible con
el Centos elegido, Miguez plantea en su trabajo la utilización
de Heartbeat la cual es una herramienta que le permitirá
mejorar la alta disponibilidad.
En la referencia [4] el servidor web seleccionado fue
Apache HTTP en su versión 2.2 de la fundación de software
Apache, ya que es el más utilizado en Internet, con más de 10
millones de sitios web estaban usándolo en el año 2013,
además de ser un software robusto, con muchas
características y de libre disposición e implementación del
código fuente. Jhonangel y Javier vieron la necesidad de
utilizar un software que prestara servicios de Corta Fuegos
(Firewall) y Puerta de enlace (Gateway). Para ello, se
seleccionó una distribución basada en Linux, Firewall. El
sistema operativo seleccionado fue Ubuntu y para el diseño
de la arquitectura del clúster se vio necesario la utilización de
un componente de software cuya principal característica fuera
el balanceo de tráfico, por ellos se seleccionó HA Proxy en su
versión 1.5.
En [6], Lenin elije Ubuntu 12.04 LTS Server Edition
debido a que tiene gran flexibilidad de configuración. Un
aspecto interesante que se realiza Lenin es el uso de Scripts
Bash en el proceso de instalación de los sistemas y
aplicaciones, el uso de estos scripts hace que la instalación se
haga de una manera desatendida y automática. En los
servidores esclavos se ha instalado Apache. Esta
infraestructura está bajo el software de virtualización Oracle
VM Virtual Box. Para conseguir la configuración correcta de
Alta Disponibilidad con Equilibrado de Carga, instalamos los
paquetes corosync, pacemaker y ldirectord en ambos
directores (Master y Standby).
Katherine Campos realiza una comparación en [6] para
poder escoger la solución más adecuada, por un lado compara
del escenario el servidor físico tiene Sistema Operativo
Windows Server 2012, luego se instaló Hyper-V como
virtualizador. En el otro escenario el servidor físico tiene
instalado el sistema operativo Fedora 20, luego se instaló el
hipervisor Xen Server, los servidores virtuales de ambos
servidores tienen Centos 6.5 como sistema operativo. La
elección luego de las pruebas que se realiza en la presente
investigación fue la segunda opción (Fedora, Xen server y
Centos 6.5). Para que exista comunicación entre los
servidores y teniendo en cuenta la compatibilidad, fue
necesario el uso de un software de monitoreo a través de la
técnica de heartbeat. Para la solución de alta disponibilidad el
autor decide realizar una evaluación de las tecnologías
conformadas por Pacemarker, Corosync y CMAN contra el
complemento de alta disponibilidad de RedHat Clúster.
Nuevamente vamos a escoger lo mejor de cada literatura
presentada, para esto se ha evaluado la plataforma de
virtualización, sistema operativo, contenedor de aplicaciones,
balanceo de carga y software de alta disponibilidad. Luego de
nuestra evaluación las herramientas escogidas son las que
aparecen en la Fig. 3.
Fig. 3 Herramientas seleccionadas
3
2.4. Propuesta de la metodología y su personalización
Como ya se mencionó anteriormente la metodología que
se utilizara en nuestra solución será Top Down, así que vamos
a personalizarla con la finalidad de adaptarla para nuestra
comodidad. En el presente trabajo se ha detallado y descrito
las fases y actividades que serán parte de la metodología. Ver
Fig. 4.
Fig. 4. Metodologia Top Down personalizada
3. Aporte
En este apartado vamos a presentar el aporte propuesto en
el presente trabajo de investigación. Para mostrar el aporte
conseguido primero vamos a revisar el diseño de investigación
que hemos realizado, el cual consta de procesos y actividades
que ayudaron a conseguir nuestro objetivo. Cabe resaltar que
el presente trabajo ha sido desarrollado tomando como caso de
estudio el área Sistema Integrado de Gestión Financiera
(SIGF), que es el área de TI encargada de brindar servicios
financieros a toda la Universidad.
3.1. Diseño de Investigación
La Fig. 5 muestra el diseño de investigación que se ha
realizado en el presente trabajo. El primer paso de nuestra
investigación es la revisión del estado del arte, en el cual
básicamente se revisaron literaturas referentes al problema
planteado. Este paso es la base de nuestro trabajo ya que nos
muestra las investigaciones y aportes que se han realizado
recientemente en el ámbito de infraestructura y aplicaciones
web. Para tener una visión más adecuada nuestra revisión la
hemos dividido en revisión de metodología, arquitectura y
herramientas tecnológicas, que serán los componentes de
nuestra solución.
El segundo paso realizado es la evaluación y selección de
los componentes de nuestra solución, en este paso hemos
tomado la información recogida del estado del arte, ya que
habiendo hecho la revisión componente por componente, nos
fue más fácil evaluar cuáles han sido los mejores aportes de
las literaturas revisadas. Para realizar nuestra evaluación
hemos definido criterios y puntajes relacionados, el puntaje
más alto será el componente con el que se trabajó nuestra
solución. Una vez seleccionados los componentes se ha
propuesto la solución a groso modo, esta solución será
adecuada a la organización a la que se aplique el presenta
trabajo, la adecuación es posible siguiendo los pasos
siguientes.
El tercer paso realizado es el análisis, que esta aplicado a
la organización escogida. En este paso vamos a conocer a más
detalle la organización con la que estamos trabajando, para
esto recolectaremos información de las actividades, servicios,
recursos, modalidad de trabajo, software que utiliza,
problemas que se presentan, etc. Luego de haber recolectado
la información de manera general vamos a enfocarnos en
realizar dos actividades importantes, las cuales son analizar su
servidor de aplicaciones y analizar las aplicaciones de la
organización.
Fig. 5. Diseño de investigacion
El cuarto paso es diseñar la arquitectura, tomando en
cuenta la información recolectada en el paso anterior. Para
realizar esta fase vamos a realizar las siguientes actividades:
 Información relevante de las aplicaciones de la
organización
 Evaluación del nivel de criticidad de las aplicaciones
 Definir políticas para la distribución de aplicaciones
en los nodos
 Distribución de aplicaciones y diseño de los nodos
 Supuestos y dimensionamiento de los nodos
En el quinto paso vamos a poner manos a la obra, para
empezar con el desarrollo de nuestra solucion vamos a tomar
como referencia el diseño realizado en el paso anterior.
Primero vamos con la creacion y configuracion de maquinas
virtuales, cada maquina virtual se convertira en nuestros
nodos, de la solucion. A estas maquinas virtuales vamos a
tratarlas como un servidor independiente por ellos vamos a
instalarle el sistema operativo y configurarlo correctamente
para su buen funcionamiento. luego vamos a instalar y
configurar el contenedor de aplicaciones y finalmente vamos
a instalar y configurar el balanceador de carga que es el core
de nuestra solucion. Al finalizar este paso vamos a tener
nuestra infraestructura funcionando, lista para probarla y
validarla.
En este paso la aplicación se encuentra funcionando en
fase de pruebas, esto nos servirá para recolectar información
del comportamiento de la solución. Vamos a tomar esta
información para validar la solución implementada, dicha
solución deberá cumplir las características de calidad de la
ISO 9126, Fiabilidad, Eficiencia y Portabilidad, por ellos
vamos a enfocarnos en esos puntos.
4
3.2. Aporte - General
El aporte del presente trabajo es una infraestructura auto
escalable que resuelve el problema de la inestabilidad de
aplicaciones web en la UNMSM, esta infraestructura brindara
soporte tanto para las aplicaciones existentes como para las
nuevas, proveerá al software tres características de calidad de
la ISO 9126 (fiabilidad, eficiencia y portabilidad). La Fig. 6
muestra el aporte que hemos realizado.
Fig. 6. Mapa del Aporte
Nuestro aporte consiste en proveer una infraestructura
auto escalable que brinde performance y alta disponibilidad a
las aplicaciones que alojan, la solución está compuesta por los
siguientes componentes, tenemos nodos (máquinas virtuales)
que pertenecen a un clúster, estos nodos están diseñados para
soportar aplicaciones de cierto nivel de criticidad (alto, medio
y bajo), para nuestra solución se han diseñado 3 nodos
principales, los dos primeros nodos tienen replicas ya que el
nivel de criticidad de las aplicaciones alojadas lo amerita.
Para el tercer nodo que aloja aplicaciones ligeras no se ha
considerado replica ya que la carga es baja. Estos nodos
cuentan con un nodo adicional que entraría en
funcionamiento en casos de contingencia. Por otro lado la
solución cuenta con un nodo adicional el cual, está diseñado
especialmente como balanceador de carga y proxy, este nodo
es el que recibe las peticiones y mediante las configuraciones
realizadas en HA Proxy (software de balanceo instalado) es
capaz de redirigir la petición a los nodos correspondientes.
Pongamos un ejemplo para la mejor comprensión,
supongamos que un usuario desea entrar a una aplicación
critica del nodo 1, al ingresar a la dirección correspondiente
el Ha Proxy recoge la petición y en su configuración le dirá
que puede redirigirla al nodo 1 o al nodo 1-replica, el software
decidirá por uno de los dos y la re direccionará; desde ese
momento el usuario trabajara con una sesión solamente en ese
nodo 1. Ahora supongamos que luego otro usuario desea
entrar a la misma aplicación, igualmente ingresara a la
dirección y el HA Proxy nuevamente tendrá que decidir a qué
nodo redirigir la petición, como la última petición fue
direccionada al nodo 1, esta vez HA Proxy tendrá que re
direccionar al nodo 1-replica ya que es el que tiene menos
carga en ese momento. Así sucesivamente será el
funcionamiento del balanceador de carga. Los nodos son
capaces de escalar verticalmente sus recursos gracias a la
virtualización que utiliza solo los recursos necesarios en un
determinado instante, también es posible escalar
horizontalmente ya que de agregar un nodo, simplemente
bastaría con agregar una línea a la configuración del
balanceador de carga y el nuevo nodo entraría en
funcionamiento aliviando aún más la carga de los nodos
correspondientes.
En casos de que uno de los nodos falle, el balanceador de
carga va a reconocer que uno de los nodos está fallando y
todas las peticiones serán re direccionadas al único nodo que
queda. En caso de que ambos nodos no estén disponibles
entonces el nodo de contingencia entrara en funcionamiento.
Todas las aplicaciones trabajan con una base de datos
centralizada.
Es importante la solución propuesta ya que de esta manera
se ha solucionado la inestabilidad de las aplicaciones web,
hemos brindado características de calidad de software a las
aplicaciones de la organización y además brinda Alta
disponibilidad, tolerancia a fallos, contingencia, fácil
administración, auto escalabilidad, fácil monitoreo, etc.
Consideramos que nuestra solución mejora los aportes de
las literaturas presentados en los últimos años, ya que gracias
a la revisión hemos podido extraer lo mejor de cada literatura
y armar una solución mucho más eficiente y eficaz, otro de
los puntos fuertes de la solución propuesta es la auto
escalabilidad de recursos de manera vertical y la escalabilidad
de manera horizontal. Otro punto por resaltar en el presente
trabajo es el modelo de solución que se da a una determinada
organización, gracias a los pasos establecidos en nuestra
metodología personalizada, esta puede ser aplicada a
cualquier organización solamente siguiente a detalle nuestras
fases y actividades descritas.
3.3. Aporte - Detalles
En esta sección vamos a detallar los componentes del
aporte presentado.
El primer componente de nuestra solución es los
servidores físicos de producción, estos servidores físicos son
la base de nuestra solución ya que son estos los que se
virtualizan para poder crear las máquinas virtuales.
El servidor físico de contingencia es de vital importancia
para permitir la continuidad de las operaciones ante cualquier
fallo de los nodos principal y replica.
Los nodos principales y replicas alojan a las aplicaciones
de la organización, estos nodos tienen instalado centos 7 como
sistema operativo y sobre este, el servidor de aplicaciones
Apache Tomcat en su versión 7. Cada uno de estos nodos tiene
la seguridad, configuraciones y software necesarios para el
correcto funcionamiento, además tiene automatizadas las
tareas de levantamiento del servicio de tomcat, esto hace que
ante cualquier inconveniente sea necesario reiniciar el
servidor el levantamiento del servicio de las aplicaciones sea
de manera automática, disminuyendo tiempo e intervención
manual. La ventaja que tienen estos nodos al estar
virtualizados es que el consumo de recursos es de manera
eficiente, es decir utiliza los recursos que necesita en ese
5
instante, si en horas pico el nodo necesita más recursos para
trabajar y no ver perjudicado el rendimiento de las
aplicaciones, este nodo va a tomar los recursos del servidor
físico y cuando baje la cantidad de usuarios este disminuirá
también el uso de recursos y los liberará, estos recursos
liberados podrán ser utilizados para cualquier otra gestión del
host físico.
Los nodos de contingencia son una copia de los nodos
principales y se encuentran inactivos, la finalidad de estos
nodos es entrar en funcionamiento cuando ninguno de los
nodos, principal y replica, se encuentren disponibles. Estos
nodos tienen las mismas características en cuanto a recursos
que el nodo principal, con la finalidad de dar continuidad a las
operaciones y no causar problemas.
El nodo balanceador de carga es el componente más
ligero y a la vez el más importante de la solución, este nodo
tiene instalado Centos 7 como sistema operativo y sobre él,
HA Proxy que es una solución gratuita, rápida y confiable que
ofrece alta disponibilidad, balanceo de carga y proxy para TCP
y aplicaciones basadas en HTTP. Especialmente adecuado
para los sitios web de muy alto tráfico y bastante visitados. Su
modo de funcionamiento hace que su integración en
arquitecturas existentes sea muy fácil y sin riesgo. El archivo
haproxy.conf de HA Proxy permite configurar el
comportamiento de nuestro balanceador. Adicionalmente se
puede configurar el HA Proxy para que pueda redirigir las
peticiones de los aplicativos de pruebas u otros.
4. Validación
En este apartado vamos a realizar las pruebas y validación
de nuestra solución. Para esto primero hemos monitoreado y
recolectado información necesaria que nos ayudó a realizar
una comparación del comportamiento de la situación anterior
de la organización y el nuevo comportamiento de la situación
actual, que ya utiliza nuestra solución implementada.
Para validar la solución el presente trabajo deberá cumplir
las tres características de calidad establecidas en la ISO 9126
que son Fiabilidad, Eficiencia y Portabilidad.
4.1. Pruebas para la validación de Fiabilidad
Esta característica de la ISO 9126 se enfoca en el nivel
de prestación de servicio libre de fallo durante un periodo
establecido, es decir el sistema debe estar disponible y
funcionando correctamente durante el periodo que es
requerido.
Fig. 7. Caida de un nodo principal
Por ejemplo para el caso de la organización SIGF el
sistema de planillas es requerido las primeras semanas de
cada mes por lo tanto debe estar altamente disponible para la
correcta continuidad de negocio y en caso de caídas o fallos
en el sistema el sistema debe tener la capacidad de
recuperabilidad y hacerlo en el menor tiempo posible. Para la
validación de esta característica, vamos a validar cada una de
sus sub características, las cuales son la madurez,
recuperabilidad y tolerancia a fallos.
4.1.1 Prueba 1 - Forzar la caída de uno de los nodos: La
prueba consiste en apagar uno de los nodos donde se alojan
las aplicaciones criticas y vamos a analizar el
comportameinto de la solucion. En la Fig. 7 se puede observar
que el nodo1 (con IP 188) no se encuentra disponible, sin
embargo la réplica si lo está.
Ahora vamos a proceder a tratar de ingresar a alguna de
estas aplicaciones. Como podemos ver en la Fig. 8, las
aplicaciones se encuentran funcionando correctamente, la
caída de uno de los nodos es transparente para el usuario y no
afecta la continuidad del negocio.
Fig. 8. Prueba de aplicación disponible
4.1.2. Prueba 2 - Forzar la caída de uno de los servidores (Host
Físico): Para esta prueba vamos a apagar un servidor, en el
cual están creadas las máquinas virtuales (nodos). Y vamos a
analizar el comportamiento de la solución. En la Fig. 9 se
puede ver que al apagar uno de los servidores, el nodo 1 y el
nodo 2 no se encuentran disponibles; sin embargo en la Fig.
10 se aprecia que las réplicas están disponibles y se puede
acceder a cualquiera de las aplicaciones. Esto ha sido posible
debido a que los nodos están ubicados en servidores físicos
distintos.
6
Fig.9. Nodos principales apagados

Fig. 10. Nodos replicas activos

Tabla 2 Comparación de caídas, anterior y actual
4.1.3. Prueba 3 - Comparación de caídas de la situación
anterior y la solución actual: Con la finalidad de validar la CANTIDAD DE CAIDAS
madurez de la solución vamos a comparar la cantidad de
caídas de servicio que se daban en la anterior situación con la PERIODO SITUACION ANTERIOR
SITUACION
cantidad de caídas de servicio que suceden ahora (con la ACTUAL
LUNES 9-10 AM
solución propuesta). Para esto vamos a tomar la información LUNES 3-4 PM
que se recolecto durante el análisis de la situación actual, es SEMANA 5 MARTES 10-11 AM
0 CAIDAS
ese punto se monitoreó dos semanas consecutivas el servidor 1 CAIDAS MIERCOLES 9-10
y nos encontramos con que, hubieron 9 caídas durante esas AM
VIERNES 10-11 AM
semanas. Ahora vamos a monitorear la solución propuesta y
LUNES 10-11 AM
ver los resultados. SEMANA 4 LUNES 3-4 PM
0 CAIDAS
2 CAIDAS JUEVES 10-11 AM
VIERNES 10-11 AM
Elaboración Propia

En la Tabla 2 se observa que durante las dos semanas de

monitoreo no se presentó ninguna caída en los servidores.
Con esta prueba se validó que el sistema tiene un alto grado
de madurez ya que esta sub característica se relaciona con la
frecuencia de fallos en el software, y con la solución
propuesta no se presentó ninguna.

7
4.1.4. Prueba 4 - Tiempo de recuperación de los sistemas: función bajo condiciones determinadas, como cantidad de
Para esta prueba vamos a simular la caída de los nodos usuarios por ejemplo.
principales y de sus réplicas y medimos el tiempo que tarda
el sistema en recuperarse, es decir volver a levantar los nodos 4.3.1 Prueba 5 - Comparación de tiempos de respuesta con
y recuperar el servicio de las aplicaciones. Vamos a apagar la solución antigua : Durante la fase de análisis obtuvimos
todos los dos nodos, para poder simular esta caída, luego información del tiempo de respuesta que tenía cada sistema,
vamos a encenderlos y desde ese momento hasta la vamos a comparar esa información con la información que se
disponibilidad de las aplicaciones, vamos a medir el intervalo recolectara del monitoreo de la solución propuesta. Vamos a
de tiempo. En la Tabla III se puede apreciar que se simularon elegir 3 aplicaciones críticas y serán las que comparemos para
5 caídas y se calculó el tiempo de la recuperación del servicio la respectiva validación.
para cada nodo, se observa claramente que la recuperación
tomó, en promedio 2 minutos con 25 segundos en promedio Tabla 4 Comparación de tiempo de respuesta
total de los nodos. Sin embargo en la situación anterior la
recuperación tardaba aproximadamente 20 minutos.
unidad de tiempo en milisegundos(ms)
aplicación
tiempo de respuesta tiempo de tiempo
Tabla 3 Tiempo de recuperación con la solución propuesta anterior respuesta actual disminuido
Promedio
Sistema
tiempo de recuperación (milisegundos) Total Logístico 10248,54 645 9603,54
nodo1 nodo2 Sistema
#prueba nodo1 Replica nodo2 Replica nodo3 Reporteador 9895,25 348 9547,25
Sistema
caída 1 128070 128085 128100 128115 128130
Contable 8854,15 286 8568,15
caída 2 125010 125023 125036 125049 125062 Elaboración propia
122575,6
caída 3 118470 117046 115622 114198 112774
En la tabla anterior se puede apreciar que los tiempos de
caída 4 122430 121130 119830 118530 117230 respuesta obtenidos con la solución propuesta, han
caída 5 124250 124270 124290 124310 124330
disminuido considerablemente y eso se verá reflejado en la
Tiempo satisfacción del usuario final.
Promedio 123646 123110,8 122575,6 122040,4 121505,2
Elaboración propia
4.3.2 Prueba 6 - comparación de uso de recursos con la
4.2. Validaciones de Fiabilidad solución anterior: Para esta prueba vamos a monitorear el
4.2.1 Validación 1: Con las dos primeras pruebas porcentaje de consumo de recursos de cada nodo y también el
realizadas se valida la característica de Fiabilidad ya que la consumo de recursos del host físico. Con la finalidad de
solución brinda la alta disponibilidad requerida por las validar que el consumo de recursos de los nodos sea menor al
aplicaciones del SIGF. En la solución antigua, cuando fallaba de la situación anterior y también validar que el servidor
el sistema, absolutamente todo se veía afectado, mientras que utilice solo los recursos necesarios requeridos en un instante
la solución propuesta se valida que es tolerante a fallos y de tiempo.
permite brindad un mejor servicio y continuidad de negocio
4.2.2 Validación 2: Con la tercera prueba se valida la Tabla 5 Comparación de consumo de recursos
característica de Fiabilidad ya que el sistema tiene un alto
grado de madurez y esta sub característica se relaciona con la Porcentaje de uso de Recursos
sistema % de uso de % de uso de % de uso de
frecuencia de fallos en el software, y con la solución CPU RAM Disco
propuesta no se presentó ninguna.
situación anterior 86,74% 84,50% 60,12%
4.2.3 Validación 3: Con la cuarta prueba se valida la
característica de Fiabilidad ya que el tiempo de recuperación solución
25% 33,50% 31%
propuesta(nodos)
ante fallos es un tiempo mínimo (2 minutos aproximados), en
comparación con la situación anterior que demoraba más de
15 minutos en levantar y aún más tiempo en caso de que En la tabla anterior se observa que el consumo de recursos
sucedan otros errores durante el levantamiento del servidor. de la solución propuesta está por debajo del 50%, ha
mejorado bastante con respecto a la situación anterior. Ahora
veamos cual es el consumo del host físico, si bien es cierto las
4.3. Pruebas para la validación de Eficiencia máquinas virtuales tienen separado en el host físico sus
recursos, la ventaja de la virtualización es que si los recursos
Esta característica de la ISO 9126 se enfoca en la no son necesitados en un determinado momento por una
relación que existe entre el nivel de desempeño del software máquina virtual, otra los puede usar.
y la cantidad de recursos necesitados. Para validar esa
característica vamos a recolectar información de los tiempos 4.4.1. Validación 4: Con la prueba número 5 se valida la
de respuesta que se alcanzan utilizando la solución de característica de eficiencia ya que la solución brinda un buen
infraestructura propuesta y verificar que la solución utilice los desempeño al software, se ha evidenciado que la solución
recursos adecuados cuando el software lleva a cabo su propuesta disminuye considerablemente los tiempos de
respuesta de las aplicaciones.
8
4.4.2. Validación 5: Con la prueba número 6 se valida
también la característica de eficiencia, ya que la solución
trabaja con la cantidad de recursos necesitados en un instante
de tiempo, liberando recursos que pueden servir para otro uso.
4.5. Validaciones de Portabilidad
Esta característica de la ISO 9126 se enfoca en la
capacidad de un sistema para ser transferido y adaptado desde
una plataforma a otra. La solución anterior no era portable ya
que todo se encontraba amarrado a un host físico y pasar toda
la configuración a otro servidor era tedioso y riesgoso; sin
embargo la solución propuesta cumple la característica de
portabilidad ya que en caso de querer mover un nodo a otro
ambiente por cuestiones de mantenimiento y/u otros, lo único
que se tendría que hacer es coger los ficheros de dicha
máquina virtual e importarlo en el otro servidor. La
portabilidad se puede entender mejor en la Fig. 11.
Fig. 11 Portabilidad de maquinas virtuales
5. Conclusiones
La primera conclusión es referente al problema
solucionado en el presente trabajo. La inestabilidad de
aplicaciones depende mucho de la infraestructura que la
soporta y con el presente trabajo se corrobora que una
infraestructura bien implementada puede brindar calidad de
servicio al software que aloja.
En los últimos años implementar Clustering se ha
convertido en algo necesario.
Las plataformas de virtualización permiten un ahorro de
los recursos de hardware que se usan dentro de una
infraestructura tecnológica. También nos facilita la
administración de nuestros servidores.
El balanceo de carga permite tener redundancia sin
necesidad de migraciones de datos o interrupciones de
servicios, siendo transparente para el usuario final.
6. Referencias
[1] Sanmiguel, A. G. (2012). Clúster de alta disponibilidad y balanceo de
carga sobre un servidor web. Sabadell.
[2] Miguez, R. A. (2012). Desarrollo de una infraestructura de redundancia
para servidores proxy GNU/LINUX en la intranet de la facultad de
ciencias. Riobamba - Ecuador.
[3] Wanumen Silva, L. F., & Mosquera Palacios, D. J. (2014). Sistema de
alta disponibilidad basado en plataforma de virtualización para
pequeñas y medianas empresas. Tecnura.
[4] Javier, M. J. (2014). Diseño de un clúster orientado a servicios para
aplicaciones web en la Universidad nacional experimental de Táchira.
Tachira.
[5] Nieto, F. V. (2011). Implementacion de un cluster a nivel de aplicacion
en la empresa casa Moeller Martinez C.A. utilizando una plataforma y
herramientas open source. Quito.
[6] Roa, L. A. (2014). 3.2.3 Instalación y configuración de un clúster de
alta disponibilidad con reparto de carga – servidor web y máquinas
virtuales. Valencia.
[7] Campos Bustos, K. E., & Vera Chávez, J. L. (2015). Diseño e
implementacion de una solucion de alta disponibilidad usando cluster
y virtualizacion de servidores web y de base de datos para las
apliccaiones de la FIEC.. Guayaquil - Ecuador.
[8] Armando, A. Q. (2016). 3.2.5 Diseño e implementación de un clúster
de alta disponibilidad para virtualizar los servidores de adquisición y
procesamiento de datos del instituto geofísico. Quito.