DISEÑO DE ARQUITECTURA LOGICA Y FÍSICA

PARA APLICACIONES EMPRESARIALES

Historia:

Replicación

HTTP, Https, RPC request

Conexion

Servidor de recursos
estáticos Cluster Nodo 1

Servidores CDN

Caché
Cliente

Respaldo BD
Nodo 2
Router balanceador
de carga
Balanceador de
carga

Caché
Nube Firewall

Nodo 3
Balanceador de
carga

Respaldo de router Servidores

de bases de
Caché datos

Servidor JMS

Servidor de
Documentos Respaldo JMS

1 OBJETIVOS

Proponer una plataforma tecnológica escalable, confiable, segura y de alta

disponibilidad de forma que pueda atender eficiente y eficazmente las
necesidades de los ciudadanos, instituciones públicas y privadas, y
expectativas de modernización institucional.
Diseño de Arquitectura Lógica y Física para Aplicaciones Empresariales

2 ARQUITECTURA DE HARDWARE

La arquitectura de hardware comprende principalmente a servidores, routers y

switches a cuales conocemos como equipos, además al medio de
comunicación entre estos (la red). Las capacidades de cada equipo, el número
de equipos, las configuraciones y distribución de los mismos impactan
directamente en el rendimiento y la disponibilidad del servicio. La adquisición
de nuevos equipos de última generación (que normalmente son muy caros) no
necesariamente va a mejorar esos dos aspectos.

La arquitectura propuesta se ilustra en el diagrama Nº1 “Arquitectura para la

alta disponibilidad de los servicios”, cuyos componentes detallamos a
continuación.
Diseño de Arquitectura Lógica y Física para Aplicaciones Empresariales

Esquema Nº 1 “Arquitectura para la alta disponibilidad de los servicios-Esquema General”

Historia:

Replicación

HTTP, Https, RPC request

Conexion

Servidor de recursos
estáticos Cluster Nodo 1

Servidores CDN

Caché
Cliente

Respaldo BD
Nodo 2
Router balanceador
de carga
Balanceador de
carga

Caché
Nube Firewall

Nodo 3
Balanceador de
carga

Respaldo de router Servidores

de bases de
Caché datos

Servidor JMS

Servidor de
Documentos Respaldo JMS
Diseño de Arquitectura Lógica y Física para Aplicaciones Empresariales

Esquema Nº 2 “Arquitectura para la alta disponibilidad de los servicios”

Familias de Clúster

Clúster SIO

Servidor de
Servidores recursos estáticos
CDN Clúster RRCC
Bases de datos

Cliente

Servidores de
bases de datos

Router Activo

Internet LAN
Clúster certificación
digital
Firewall

Router Backup

Clúster AFIS
Respaldo DB

Clúster PVM y servicios

en línea

Servidor de Servidor JMS

Documentos

Respaldo JMS
Diseño de Arquitectura Lógica y Física para Aplicaciones Empresariales

Esquema Nº 3 “Configuración típica de un Clúster”

Cluster

Nodo 1

cache
Bases de datos

Balanceador
de carga
Nodo 2

cache

Nodo 3

Respaldo balanceador
de carga

cache

3.1. Nodos
Para nuestro caso, son los servidores de aplicaciones Java EE sobre los
cuales se ejecutan las aplicaciones Java que son accedidos por los
usuarios a través de protocolos HTTP o HTTPs. Son servidores que
implementan estándares de JEE y físicamente están instalados en una
computadora con capacidades de servidor (por ejemplo de tipo blade).

Los nodos deben tener características similares en hardware y deben

proporcionar los mismos servicios.

3.2. Clúster de servidores

Es una configuración de un conjunto de servidores interrelacionados que
se comportan como si fuera uno solo, orquestados por uno o varios
servidores balanceadores de carga, cuya finalidad es de proporcionar
Diseño de Arquitectura Lógica y Física para Aplicaciones Empresariales

servicios de: Alto rendimiento, alta disponibilidad, balanceo de carga y

escalabilidad.

Ésta configuración permite fácilmente agregar nuevos servidores cuando

se requiera mayores capacidades del servicio, bajar un servidor para su
mantenimiento o repotenciación, todo esto sin afectar la continuidad del
servicio.

Para lo cual, las sesiones deben ser replicadas entre todos los nodos del
clúster, de modo que si uno de ellos deja de estar disponible, otro nodo
comenzará inmediatamente a proporcionar los servicios sin perder la
sesión del usuario. Esta característica se conoce como replicación de
sesiones, es parte de las especificaciones del estándar JEE y que los
servidores de aplicaciones más populares como Glassfish, OAS, WebLogic
y Jboos lo implementan.

Se debe configurar varios clúster de servidores, cada clúster destinado a

un conjunto de aplicaciones que guarden relación

3.3. Balanceadores de carga

Los balanceadores de carga son servidores web convencionales pero con
una configuración particular que le permite distribuir la carga de número de
peticiones HTTP entre los nodos que conforman el clúster.

El balanceador de carga es un elemento muy importante y crítico en este

esquema de alta disponibilidad, en el sentido de que cualquier caída del
mismo puede afectar la disponibilidad del servicio, por ello se requiere que
tenga un servidor de contingencia.

3.4. Servidor JMS:

El uso de este servidor estaría destinado para servicios de mensajería,
ejecutar proceso por lotes (batch), servicios de consulta, para evitar la
complejidad del acceso y transferencia de datos desde un servidor de
aplicaciones vía protocolo HTTP y HTTPs.
Diseño de Arquitectura Lógica y Física para Aplicaciones Empresariales

Un servidor de mensajería por sus propias características de conexión y

protocolos de transmisión de datos, ofrece tiempos de respuesta más
rápidos que un servidor de aplicaciones.

3.5. Servidor de recursos estáticos

Los servidores de recursos estáticos son servidores web convencionales,
no ejecutan sobre algún JVM, cuya finalidad principal es de distribuir los
archivos estáticos como de los tipos: css, js, imágenes, flash y videos que
no cambian con frecuencia.

La estrategia de implementar un servidor para todos los recursos estáticos

de todas las aplicaciones, corresponde a liberar carga a los servidores de
aplicaciones que debieran dedicarse solo a tender peticiones
transaccionales, asimismo se puede aprovechar la reutilización de los
recursos existentes en caché del browser entre distintas aplicaciones ya
que todas invocarán al mismo dominio.

Este tipo de servidores no requiere utilizar cookies, por lo que

recomendamos su desactivación.

3.6. Bases de datos

Los servidores de bases de datos son recursos extremadamente críticos,
debido a que una caída de cualquiera de ellos ocasionará la caída o la
interrupción de servicio de todos los aplicativos que conectan a ella; por lo
tanto, se debe implementar servidores de contingencia sincronizados para
las bases de datos y distribuidos en diferentes locales.

3.7. Router
El router es un recurso crítico, necesariamente debe contar con un
mecanismo de redundancia que se acople a toda la infraestructura
planteada y asegure la alta disponibilidad de los servicios.
Diseño de Arquitectura Lógica y Física para Aplicaciones Empresariales

3 ARQUITECTURA DE SOFTWARE

No es posible definir una única arquitectura de software para las aplicaciones,

ya que dependiendo de los requisitos no funcionales del mismo, la arquitectura
y sus componentes pueden variar. Sin embargo podemos recomendar de que
el desarrollo de nuevas aplicaciones siga plenamente los estándares y
patrones de diseño JEE y aproveche los frameworks que implementan dichos
patrones, además de seguir la guía que se menciona en el documento
“Estándar de arquitectura para el desarrollo y mantenimiento de aplicaciones
web” de la Sub Gerencia de Ingeniería de Software.

La arquitectura de software propuesta es presentada en el esquema Nº 3

“Arquitectura de software para aplicaciones empresariales web”, el cual
propone un cambio muy importante en el JVM, se trata de no usar el JDK
habitual de Oracle y remplazarlo por JRockit, que es un JVM mucho más
eficiente en ambientes de producción de alto rendimiento, muestra un
excelente manejo de recursos como CPU y Memoria, Pool de conexiones, etc.

Una arquitectura de software va de la mano con la arquitectura de hardware

descrita en el apartado anterior, al combinar ambos y no descuidar detalles de
ninguno podemos obtener aplicativos de muy alto rendimiento. No diseñar una
buena arquitectura de software puede poner en riesgo todo un esquema físico
por más eficiente que fuera.

El rendimiento de los aplicativos es un tema complejo que lamentablemente no

se trata de un solo aspecto a solucionar, hay diversas consideraciones que en
ocasiones no le damos importancia pero al final suman como parte del
problema o la solución.

Los errores comunes que se cometen en la parte de software son en primer

lugar no seguir estándares y patrones, desarrollar sobre frameworks que no se
dominan o desarrollar con JDK antiguo.
Diseño de Arquitectura Lógica y Física para Aplicaciones Empresariales

Esquema Nº 4 “Arquitectura de software para aplicaciones empresariales web”

Sesiones

Pool de Herramientas
de monitoreo
Aplicaciones empresariales de Reniec
Conexiones
Librerías js
Servidor
Cache Patrones de diseño Estándares JEE
JavaScript css imágenes

Full Cache Compresión de datos Servidor de aplicaciones

JVM Browser Optimización de vistas JROCKIT 1.6 (JVM)

Sistema Operativo Peticiones HTTP, HTTPS Sistema Operativo

Cliente Comunicación Servidor de Aplicaciones

Diseño de Arquitectura Lógica y Física para Aplicaciones Empresariales

4.1. Servidor de Aplicaciones:

4.3.1. JRockit (Java Virtual Machine)

JRockit es una máquina virtual. Es lo que ejecuta los programas

basados en Java. Está orientado principalmente a servidores de alto
desempeño y rendimiento. Originalmente propiedad de Bea Systems,
quien la desarrolló como el core dentro de la plataforma WebLogic y
liberada en la actualidad con una licencia libre para desarrollo y uso en
producción interno (la licencia es la misma que Sun JDK ha tenido
durante varios años).

JRockit es muy eficiente en el manejo y administración de los recursos

como la Memoria y el CPU, asimismo ofrece un conjunto de
herramientas de diagnóstico como Oracle JRockit Real Time, Oracle
JRockit misión control.

JRockit es un JVM dinámicamente optimizado, por lo que tiene su rendimiento en tiempo

de ejecución basado en algoritmos de muestreo y heurística avanzada. Las herramientas
de JRockit toman ventaja de esta rica información y la proveen al usuario con muy poco
impacto en la aplicación que está corriendo. (http://www.a2econ.com/jsite)

4.3.2. Servidor Caché

El servidor cache guarda los objetos y archivos frecuentemente usados

por el servidor de aplicaciones, ayuda en la rapidez de la ejecución de
un proceso, y por ende mejora el tiempo respuesta al cliente.

4.3.3. Pool de conexiones

El pool de conexiones es un conjunto de conexiones a la base de datos

administrados por el servidor de aplicaciones, permite la reutilización de
las conexiones que requiere un determinado aplicativo.

Todos los aplicativos deben configurar un pool de conexiones, con

parámetros adecuados y de acuerdo a su necesidad, los cuales deben
ser ajustados mediante un procedimiento de test de carga del sistema,
Diseño de Arquitectura Lógica y Física para Aplicaciones Empresariales

utilizado herramientas de stress como JMeter y JConsole monitoreando

los parámetros del servidor.

No se recomienda un número mayor a 15 de conexiones abiertas del

pool, ya que cada conexión significa consumo de recursos (memoria) en
el servidor de base de datos.

4.3.4. Memoria

Algunos aplicativos han experimentado problemas con la memoria

dinámica del JVM. La causa puede deberse a diversos aspectos una de
ellas la arquitectura lógica propio del aplicativo, el uso de algún
framework pesado o el no uso de ninguno.

Los frameworks más difundidos en si ya optimizan el uso de la memoria,

es cierto que unos requieren algo más de memoria que otros, pero
normalmente eso no significa un problema. No usar ningún framework y
no desarrollar bajo estándares y patrones de diseño es un verdadero
problema, a parte de hacer difícil el mantenimiento y evolución del
aplicativo, ocasiona problemas de copamiento de memoria.

Por defecto los servidores aplicaciones configuran la memoria dinámica

a 64Mb(PermGen), este parámetro se puede incrementar y se
recomienda que se realice mediante una prueba de sobre carga.

4.3.5. Sesiones
Minimizar el uso de sesiones, por que los servidores de aplicaciones
que pertenecen a un clúster, van a compartir los objetos de sus
sesiones, este proceso puede afectar al rendimiento si la cantidad de
memoria que ocupa cada sesión es muy grande, aproximadamente
encima de los 10Kb.

El uso de sesiones debe realizarse para guardar solamente datos

básicos de la conexión del usuario, como identificación de sesión, login
y algunos parámetros adicionales.
Diseño de Arquitectura Lógica y Física para Aplicaciones Empresariales

4.2. Comunicación

4.2.1. Peticiones HTTP, HTTPs

Para cada petición, se debe tener en cuenta la latencia de comunicación

sobre la red, que se evidencia en conexiones satelitales o cuando la pc
cliente se encuentra a mucha distancia de los servidores (caso
consulados de Perú en otros continentes), haciendo mas lenta la
respuesta.

La solución corresponde a aspectos de tecnología de comunicación que

debe ser mejorado, en caso de que no se pueda, las aplicaciones
deberían evitar realizar muchas peticiones HTTP, mientras se haga más
peticiones, el usuario puede percibir lentitud del sistema.

4.3.6. Compresión de datos

Los servidores de aplicaciones tienen la capacidad de comprimir la data

que será devuelta al browser, esta característica no esta configurada
por defecto, aprovechar esta configuración aumentaría la velocidad de
carga de una página.

4.3.7. Optimización de las páginas

Los JSPs se deben optimizar al máximo, en el sentido de aprovechar
los archivos css para decorar la estructura de una página web, los
archivos js para los JavaScripts y éstos no deben contener scriplets.

En muchas ocasiones, los jsps contienen más decoración que

información, se definen funciones JavaScript dentro de una página jsp,
lo cual hace que la trama de respuesta sea considerable y más lenta.

Las páginas que no muestren datos dinámicos, deben ser configuradas

para que permanezcan en el cache del browser, por un año.
Diseño de Arquitectura Lógica y Física para Aplicaciones Empresariales

4.3. Cliente

4.3.1. Caché del browser

Se debe aprovechar al máximo el cache del browser para hacer

persistente los archivos estáticos como: css, js, imágenes (jpg, bmp,
png, etc), flash y applets; de modo que el browser no requiera re-cargar
todas las veces que requiera los recursos, no realizará la peticion HTTP
y no se transmitirá ninguna información a través de la red sino será
recuperada del cache.

Esta característica, se puede aprovechar también para páginas jsp que

no muestran datos dinámicos, por lo menos al momento de su carga en
la pantalla.

4.3.2. Memoria de JVM cliente

No es recomendable el uso de applets, el uso de los mismos debe

pasar por una exhaustiva evaluación de alternativas como el uso de
webservice local.

En caso de requerir necesariamente applets, se debe configurar la

memoria dinámica del JVM del cliente, y los permisos necesarios
adecuadamente.

4.3.3. Servicio CDN

Es un esquema conformado de múltiples servidores distribuidos en

diversos puntos a nivel mundial, sirven básicamente para distribuir
recursos estáticos. Se puede aprovechar este esquema para hacer que
la latencia en las conexiones sea menor, ya que el browser descargará
los recursos desde el servidor más cercano a su ubicación gracias al
DNS.
Diseño de Arquitectura Lógica y Física para Aplicaciones Empresariales

4 SEGURIDAD

Según el sistema (internet o intranet) se deben tomar medidas adecuadas de

seguridad para garantizar la protección contra vulnerabilidades del sistema,
dependiendo de los requerimientos del aplicativo se debe estudiar la posibilidad
de implementar la transmisión por canal seguro (HTTPS). En algunas
ocasiones será necesario el uso de certificados digitales y/o validación con
huella digital.

El sistema debe ser confiable y seguro al cumplir su propósito sin descuidar el

registro de transacciones (logs) y envíos de alertas o avisos (emails) de
preferencia usando herramientas de mensajería asíncrona que delegan dicha
responsabilidad a servidores especializados en procesos que pueden tomar
tiempos largos, ahorrándole tiempo al servidor de aplicación en su propósito
principal

5 CARACTERISTICAS DE LA INFRAESTRUCTURA

6.1. Viabilidad
La infraestructura propuesta es viable por:
- La arquitectura de hardware no requiere la adquisición de servidores de
última generación. Por el contrario, la infraestructura fue diseñada para
construir un sistema de alto rendimiento, alta disponibilidad y
escalabilidad a bajo costo con servidores normales como por ejemplo del
tipo Blade.
- La arquitectura de software, considerando los altos costos de
licenciamiento de software, puede ser implementada con herramientas
Open Source o haciendo una combinación con el software comercial
producto de un estudio de alternativas y de ventajas que brindan.
- La nueva infraestructura no requiere de un conocimiento especializado
más allá de las propias capacidades exigidas a los actores como los
administradores, arquitectos y programadores.
- En cuanto a la capacitación se puede aprovechar la amplia gama de
información que está disponible en la Internet.
Diseño de Arquitectura Lógica y Física para Aplicaciones Empresariales

6.2. Flexibilidad
La infraestructura propuesta es flexible, su implementación no obliga la
utilización de herramientas software y hardware de un determinado
fabricante. Haciendo posible por ejemplo la migración de un determinado
servidor de aplicaciones hacia otro sin ocasionar impacto negativo en las
aplicaciones.

Asimismo, debemos tener en cuenta algunos aspectos que reforzarán la

flexibilidad de la infraestructura:

- Se requiere definir herramientas de desarrollo, producción y monitoreo

que estén de acuerdo con los aspectos más importantes como sencillez,
ligereza, integralidad y rendimiento.
- Los desarrollos de las aplicaciones web, deben estar gestionadas y
construidas de manera simple, en red y estándar, utilizando un servidor
de librerías, simplificando el uso y reusó de librerías, que permita a las
aplicaciones ser migradas de un servidor a otro sin problemas de
dependencias incorrectas, así mismo se agiliza el pase a producción ya
que también se cuenta con un servidor de librerías para el ambiente de
producción.
- Se debe definir procedimientos como estándares para el control de
rendimiento y uso de recursos de aplicaciones web empresariales. Que
permitan controlar la memoria, la rapidez de conexión y la carga de la
aplicación en el navegador.
- Asimismo, considerar el uso de servidores de versionamiento para
dinamizar y organizar los archivos fuente en el desarrollo de los
proyectos. El cual debe contar con su respectivo servidor de
contingencia.

6 ESTRATEGIA DE MIGRACION

Las aplicaciones con nueva implementación y las que recientemente se

pasaron a producción deben migrar a esta nueva infraestructura (caso de SIO,
certificación digital, erep). Para el resto de aplicaciones y según su
característica de ser crítica o no crítica, se debe formar una comisión integrada
Diseño de Arquitectura Lógica y Física para Aplicaciones Empresariales

por los Arquitectos de software, Programadores y Administradores de

servidores para evaluar el cumplimiento de recomendaciones mínimas de
arquitectura de software propuesta.