arquitectura fisica y logica

DISEÑO DE ARQUITECTURA LOGICA Y FÍSICA

PARA APLICACIONES EMPRESARIALES

Caché

Nodo 1

Nodo 2

Firewall

Servidor de recursos

estáticos

Servidores

de bases de

datos

Nube

Router balanceador

de carga

Nodo 3

Caché

Cluster

Replicación

HTTP, Https, RPC request

Historia:

Conexion

Servidores CDN

Servidor JMS

Servidor de

Documentos Respaldo JMS

CachéCliente

Respaldo BD

Balanceador de

carga

Balanceador de

carga

Respaldo de router

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.


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

Caché

Nodo 1

Nodo 2

Firewall

Servidor de recursos

estáticos

Servidores

de bases de

datos

Nube

Router balanceador

de carga

Nodo 3

Caché

Cluster

Replicación

HTTP, Https, RPC request

Historia:

Conexion

Servidores CDN

Servidor JMS

Servidor de

Documentos Respaldo JMS

CachéCliente

Respaldo BD

Balanceador de

carga

Balanceador de

carga

Respaldo de router


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

LANInternet

Firewall

Servidor de

recursos estáticos

Router Activo

Servidores

CDN

Servidores de

bases de datos

Servidor JMSServidor de

Documentos

Respaldo JMS

Cliente

Router Backup

Clúster SIO

Familias de Clúster

Bases de datosClúster RRCC

Clúster certificación

digital

Clúster AFIS

Clúster PVM y servicios

en línea

Respaldo DB


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

Respaldo balanceador

de carga

Balanceador

de carga

Nodo 1

cache

Nodo 2

cache

Nodo 3

cache

Cluster

Bases de datos

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


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.


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.


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.


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

Servidor de aplicaciones

Sistema Operativo

JROCKIT 1.6 (JVM)

Patrones de diseño Estándares JEE

Aplicaciones empresariales de Reniec

Servidor

Cache

Pool de

ConexionesHerramientas

de monitoreo

Sesiones

Full Cache

Sistema Operativo

BrowserJVM

JavaScript

Librerías js

imágenes

Peticiones HTTP, HTTPS

Optimización de vistas

Compresión de datos

Servidor de AplicacionesCliente Comunicación

css


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,

http://www.a2econ.com/


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.


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.


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.


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.


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


por los Arquitectos de software, Programadores y Administradores de

servidores para evaluar el cumplimiento de recomendaciones mínimas de

arquitectura de software propuesta.

arquitectura fisica y logica

Documents