DISEO DE ARQUITECTURA LOGICA Y FSICA

PARA APLICACIONES EMPRESARIALES

Historia:
Replicacin
HTTP, Https, RPC request
Conexion
Servidor de recursos
estticos

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
Cach

Servidores
de bases de
datos

Servidor JMS

Servidor de
Documentos

Respaldo JMS

OBJETIVOS
Proponer una plataforma tecnolgica escalable, confiable, segura y de alta
disponibilidad de forma que pueda atender eficiente y eficazmente las
necesidades de los ciudadanos, instituciones pblicas y privadas, y
expectativas de modernizacin institucional.

Diseo de Arquitectura Lgica y Fsica para Aplicaciones Empresariales

ARQUITECTURA DE HARDWARE
La arquitectura de hardware comprende principalmente a servidores, routers y
switches a cuales conocemos como equipos, adems al medio de
comunicacin entre estos (la red). Las capacidades de cada equipo, el nmero
de equipos, las configuraciones y distribucin de los mismos impactan
directamente en el rendimiento y la disponibilidad del servicio. La adquisicin
de nuevos equipos de ltima generacin (que normalmente son muy caros) no
necesariamente va a mejorar esos dos aspectos.
La arquitectura propuesta se ilustra en el diagrama N1 Arquitectura para la
alta disponibilidad de los servicios, cuyos componentes detallamos a
continuacin.

Diseo de Arquitectura Lgica y Fsica para Aplicaciones Empresariales

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

Historia:
Replicacin
HTTP, Https, RPC request
Conexion
Servidor de recursos
estticos

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
Cach

Servidor JMS

Servidor de
Documentos

Respaldo JMS

Servidores
de bases de
datos

Diseo de Arquitectura Lgica y Fsica para Aplicaciones Empresariales

Esquema N 2 Arquitectura para la alta disponibilidad de los servicios

Familias de Clster

Clster SIO

Servidores
CDN

Servidor de
recursos estticos

Clster RRCC

Bases de datos

Cliente

Servidores de
bases de datos

Router Activo

LAN

Internet

Clster certificacin
digital
Firewall

Router Backup

Clster AFIS
Respaldo DB

Clster PVM y servicios

en lnea

Servidor de
Documentos

Servidor JMS

Respaldo JMS

Diseo de Arquitectura Lgica y Fsica para Aplicaciones Empresariales

Esquema N 3 Configuracin tpica de un Clster

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 travs de protocolos HTTP o HTTPs. Son servidores que
implementan estndares de JEE y fsicamente estn instalados en una
computadora con capacidades de servidor (por ejemplo de tipo blade).

Los nodos deben tener caractersticas similares en hardware y deben

proporcionar los mismos servicios.

3.2. Clster de servidores

Es una configuracin 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

Diseo de Arquitectura Lgica y Fsica para Aplicaciones Empresariales

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

escalabilidad.

sta configuracin permite fcilmente agregar nuevos servidores cuando

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

Para lo cual, las sesiones deben ser replicadas entre todos los nodos del
clster, de modo que si uno de ellos deja de estar disponible, otro nodo
comenzar inmediatamente a proporcionar los servicios sin perder la
sesin del usuario. Esta caracterstica se conoce como replicacin de
sesiones, es parte de las especificaciones del estndar JEE y que los
servidores de aplicaciones ms populares como Glassfish, OAS, WebLogic
y Jboos lo implementan.

Se debe configurar varios clster de servidores, cada clster destinado a

un conjunto de aplicaciones que guarden relacin

3.3. Balanceadores de carga

Los balanceadores de carga son servidores web convencionales pero con
una configuracin particular que le permite distribuir la carga de nmero de
peticiones HTTP entre los nodos que conforman el clster.

El balanceador de carga es un elemento muy importante y crtico en este

esquema de alta disponibilidad, en el sentido de que cualquier cada 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 estara destinado para servicios de mensajera,
ejecutar proceso por lotes (batch), servicios de consulta, para evitar la
complejidad del acceso y transferencia de datos desde un servidor de
aplicaciones va protocolo HTTP y HTTPs.

Diseo de Arquitectura Lgica y Fsica para Aplicaciones Empresariales

Un servidor de mensajera por sus propias caractersticas de conexin y

protocolos de transmisin de datos, ofrece tiempos de respuesta ms
rpidos que un servidor de aplicaciones.

3.5. Servidor de recursos estticos

Los servidores de recursos estticos son servidores web convencionales,
no ejecutan sobre algn JVM, cuya finalidad principal es de distribuir los
archivos estticos como de los tipos: css, js, imgenes, flash y videos que
no cambian con frecuencia.

La estrategia de implementar un servidor para todos los recursos estticos

de todas las aplicaciones, corresponde a liberar carga a los servidores de
aplicaciones

que

debieran

dedicarse

solo

tender

peticiones

transaccionales, asimismo se puede aprovechar la reutilizacin de los

recursos existentes en cach del browser entre distintas aplicaciones ya
que todas invocarn al mismo dominio.

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

recomendamos su desactivacin.

3.6. Bases de datos

Los servidores de bases de datos son recursos extremadamente crticos,
debido a que una cada de cualquiera de ellos ocasionar la cada o la
interrupcin 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 crtico, necesariamente debe contar con un
mecanismo de redundancia que se acople a toda la infraestructura
planteada y asegure la alta disponibilidad de los servicios.

Diseo de Arquitectura Lgica y Fsica para Aplicaciones Empresariales

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 estndares y
patrones de diseo JEE y aproveche los frameworks que implementan dichos
patrones, adems de seguir la gua que se menciona en el documento
Estndar de arquitectura para el desarrollo y mantenimiento de aplicaciones
web de la Sub Gerencia de Ingeniera 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 ms
eficiente en ambientes de produccin 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 disear una
buena arquitectura de software puede poner en riesgo todo un esquema fsico
por ms 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 solucin.

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

lugar no seguir estndares y patrones, desarrollar sobre frameworks que no se
dominan o desarrollar con JDK antiguo.

Diseo de Arquitectura Lgica y Fsica para Aplicaciones Empresariales

Esquema N 4 Arquitectura de software para aplicaciones empresariales web

Sesiones

Pool de
Conexiones

Herramientas
de monitoreo

Aplicaciones empresariales de Reniec

Libreras js
JavaScript

css
Full Cache

JVM

Servidor
Cache

imgenes

Browser

Patrones de diseo

Compresin de datos

Servidor de aplicaciones

Optimizacin de vistas

JROCKIT 1.6 (JVM)

Sistema Operativo

Peticiones HTTP, HTTPS

Cliente

Comunicacin

Sistema Operativo

Servidor de Aplicaciones

Estndares JEE

Diseo de Arquitectura Lgica y Fsica para Aplicaciones Empresariales

4.1. Servidor de Aplicaciones:

4.3.1. JRockit (Java Virtual Machine)
JRockit es una mquina virtual. Es lo que ejecuta los programas
basados en Java. Est orientado principalmente a servidores de alto
desempeo 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
produccin interno (la licencia es la misma que Sun JDK ha tenido
durante varios aos).

JRockit es muy eficiente en el manejo y administracin de los recursos

como la Memoria y el CPU, asimismo ofrece un conjunto de
herramientas de diagnstico como Oracle JRockit Real Time, Oracle
JRockit misin control.
JRockit es un JVM dinmicamente optimizado, por lo que tiene su rendimiento en tiempo
de ejecucin basado en algoritmos de muestreo y heurstica avanzada. Las herramientas
de JRockit toman ventaja de esta rica informacin y la proveen al usuario con muy poco
impacto en la aplicacin 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 ejecucin 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 reutilizacin de
las conexiones que requiere un determinado aplicativo.

Todos los aplicativos deben configurar un pool de conexiones, con

parmetros adecuados y de acuerdo a su necesidad, los cuales deben
ser ajustados mediante un procedimiento de test de carga del sistema,

Diseo de Arquitectura Lgica y Fsica para Aplicaciones Empresariales

utilizado herramientas de stress como JMeter y JConsole monitoreando

los parmetros del servidor.

No se recomienda un nmero mayor a 15 de conexiones abiertas del

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

4.3.4. Memoria
Algunos aplicativos han experimentado problemas con la memoria
dinmica del JVM. La causa puede deberse a diversos aspectos una de
ellas la arquitectura lgica propio del aplicativo, el uso de algn
framework pesado o el no uso de ninguno.

Los frameworks ms difundidos en si ya optimizan el uso de la memoria,

es cierto que unos requieren algo ms de memoria que otros, pero
normalmente eso no significa un problema. No usar ningn framework y
no desarrollar bajo estndares y patrones de diseo es un verdadero
problema, a parte de hacer difcil el mantenimiento y evolucin del
aplicativo, ocasiona problemas de copamiento de memoria.

Por defecto los servidores aplicaciones configuran la memoria dinmica

a 64Mb(PermGen), este parmetro 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 clster, van a compartir los objetos de sus
sesiones, este proceso puede afectar al rendimiento si la cantidad de
memoria que ocupa cada sesin es muy grande, aproximadamente
encima de los 10Kb.

El uso de sesiones debe realizarse para guardar solamente datos

bsicos de la conexin del usuario, como identificacin de sesin, login
y algunos parmetros adicionales.

Diseo de Arquitectura Lgica y Fsica para Aplicaciones Empresariales

4.2. Comunicacin
4.2.1. Peticiones HTTP, HTTPs
Para cada peticin, se debe tener en cuenta la latencia de comunicacin
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 solucin corresponde a aspectos de tecnologa de comunicacin que

debe ser mejorado, en caso de que no se pueda, las aplicaciones
deberan evitar realizar muchas peticiones HTTP, mientras se haga ms
peticiones, el usuario puede percibir lentitud del sistema.

4.3.6. Compresin de datos

Los servidores de aplicaciones tienen la capacidad de comprimir la data
que ser devuelta al browser, esta caracterstica no esta configurada
por defecto, aprovechar esta configuracin aumentara la velocidad de
carga de una pgina.

4.3.7. Optimizacin de las pginas

Los JSPs se deben optimizar al mximo, en el sentido de aprovechar
los archivos css para decorar la estructura de una pgina web, los
archivos js para los JavaScripts y stos no deben contener scriplets.

En muchas ocasiones, los jsps contienen ms decoracin que

informacin, se definen funciones JavaScript dentro de una pgina jsp,
lo cual hace que la trama de respuesta sea considerable y ms lenta.

Las pginas que no muestren datos dinmicos, deben ser configuradas

para que permanezcan en el cache del browser, por un ao.

Diseo de Arquitectura Lgica y Fsica para Aplicaciones Empresariales

4.3. Cliente
4.3.1. Cach del browser
Se debe aprovechar al mximo el cache del browser para hacer
persistente los archivos estticos como: css, js, imgenes (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 informacin a travs de la red sino ser
recuperada del cache.

Esta caracterstica, se puede aprovechar tambin para pginas jsp que

no muestran datos dinmicos, 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 evaluacin de alternativas como el uso de
webservice local.

En caso de requerir necesariamente applets, se debe configurar la

memoria dinmica del JVM del cliente, y los permisos necesarios
adecuadamente.

4.3.3. Servicio CDN

Es un esquema conformado de mltiples servidores distribuidos en
diversos puntos a nivel mundial, sirven bsicamente para distribuir
recursos estticos. 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 ms cercano a su ubicacin gracias al
DNS.

Diseo de Arquitectura Lgica y Fsica para Aplicaciones Empresariales

SEGURIDAD
Segn el sistema (internet o intranet) se deben tomar medidas adecuadas de
seguridad para garantizar la proteccin contra vulnerabilidades del sistema,
dependiendo de los requerimientos del aplicativo se debe estudiar la posibilidad
de implementar la transmisin por canal seguro (HTTPS). En algunas
ocasiones ser necesario el uso de certificados digitales y/o validacin con
huella digital.

El sistema debe ser confiable y seguro al cumplir su propsito sin descuidar el

registro de transacciones (logs) y envos de alertas o avisos (emails) de
preferencia usando herramientas de mensajera asncrona que delegan dicha
responsabilidad a servidores especializados en procesos que pueden tomar
tiempos largos, ahorrndole tiempo al servidor de aplicacin en su propsito
principal

CARACTERISTICAS DE LA INFRAESTRUCTURA
6.1. Viabilidad
La infraestructura propuesta es viable por:
-

La arquitectura de hardware no requiere la adquisicin de servidores de

ltima generacin. Por el contrario, la infraestructura fue diseada para
construir

un sistema de

alto rendimiento,

alta

disponibilidad

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 combinacin con el software comercial
producto de un estudio de alternativas y de ventajas que brindan.

La nueva infraestructura no requiere de un conocimiento especializado

ms all de las propias capacidades exigidas a los actores como los
administradores, arquitectos y programadores.

En cuanto a la capacitacin se puede aprovechar la amplia gama de

informacin que est disponible en la Internet.

Diseo de Arquitectura Lgica y Fsica para Aplicaciones Empresariales

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

Asimismo, debemos tener en cuenta algunos aspectos que reforzarn la

flexibilidad de la infraestructura:

Se requiere definir herramientas de desarrollo, produccin y monitoreo

que estn de acuerdo con los aspectos ms importantes como sencillez,
ligereza, integralidad y rendimiento.

Los desarrollos de las aplicaciones web, deben estar gestionadas y

construidas de manera simple, en red y estndar, utilizando un servidor
de libreras, simplificando el uso y reus de libreras, que permita a las
aplicaciones ser migradas de un servidor a otro sin problemas de
dependencias incorrectas, as mismo se agiliza el pase a produccin ya
que tambin se cuenta con un servidor de libreras para el ambiente de
produccin.

Se debe definir procedimientos como estndares para el control de

rendimiento y uso de recursos de aplicaciones web empresariales. Que
permitan controlar la memoria, la rapidez de conexin y la carga de la
aplicacin 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.

ESTRATEGIA DE MIGRACION
Las aplicaciones con nueva implementacin y las que recientemente se
pasaron a produccin deben migrar a esta nueva infraestructura (caso de SIO,
certificacin digital, erep). Para el resto de aplicaciones y segn su
caracterstica de ser crtica o no crtica, se debe formar una comisin integrada

Diseo de Arquitectura Lgica y Fsica para Aplicaciones Empresariales

por los Arquitectos de software, Programadores y Administradores de

servidores para evaluar el cumplimiento de recomendaciones mnimas de
arquitectura de software propuesta.