ADMINISTRACIÓN DE META4 PEOPLENET Y VEGA EN LA UCO

Transcripción

1 ADMINISTRACIÓN DE META4 PEOPLENET Y VEGA EN LA UCO Índice de contenido 1.- Administración de Meta4 PeopleNet Introducción a Meta Características Arquitectura genérica en 3 niveles de Meta Elementos principales del Sitio de Meta Tipos de instalación Arquitectura de Meta4 en la Universidad de Córdoba Subsistemas del servidor de aplicaciones de Meta Subsistemas de ejecución Transaccional (OLTP: On Line Transaction Processing) Delta Transaccional Optimizado (OLTP) Conversacional (Proxy) Ejecución programada (Planificador de tareas: Job Scheduler) Subsistemas auxiliares o de servicios Subsistema de comunicaciones Subsistema de base de datos lógica Subsistema de usuarios Subsistema de metadatos Subsistema de cache Subsistema XML Subsistema de trazas Subsistema de logs Subsistema de trazas de máquina virtual Subsistema de trazas de benchmark Subsistema de control de memoria Editor de configuraciones El monitor del Servidor de aplicaciones Servidores de bases de datos Puestos cliente Ficheros de configuración Arranque automático del entorno Administración de VEGA Introducción a Sigma Ámbitos de actuación Arquitectura de Sigma en la UCO Scripts de monitorización de AppServer / WebServer Script de monitorización de Sigma...17

2 1.- Administración de Meta4 PeopleNet Introducción a Meta4 El sistema de gestión de RR.HH. Meta4 PeopleNet identifica a la Persona como el verdadero protagonista de la organización y reconoce sus atributos individuales más importantes: el rol que desempeña, sus competencias y las relaciones con el resto de los individuos como base de la gestión. El Directorio de global de personas de PeopleNet conserva información sobre todos los individuos relacionados con la organización. Este directorio es la base del módulo de Administración de personal y ofrece una instantánea de todo tipo de relaciones que un individuo puede tener con la organización Características Según la propia web de Meta4 Peoplenet, las principales características de la aplicación son las siguientes: Gestión de los datos de todas las personas que interaccionan con la organización. Gestión de múltiples colectivos (empleados, colaboradores externos, jubilados, etc) Información contractual y del puesto que desempeña el empleado en cada momento. Gestión de los diferentes activos propiedad de la empresa. Cálculo automático de la EJC (Equivalente a Jornada Completa). Seguimiento de las distintas evaluaciones, formación y el plan de carrera. Obtención de informes (nuevas contrataciones, movimientos, bajas, rotación, estabilidad, etc.). Gestión global de personas: Disponer de Información globalizada adaptada a cada legislación local. Información histórica asociada a un único Identificador para la persona. Gestión de los movimientos internos de un empleado, cambio de puesto, de rol, etc. Gestión integral de documentos (gestión documental) asociados a una persona. Asignación masiva de vacaciones y automatización para la reinicialización de la bolsa a fin de año. Generación de informes y gráficos con cualquier información laboral o económica de forma dinámica Arquitectura genérica en 3 niveles de Meta4 La aplicación Meta4 está especialmente optimizada para trabajar en una arquitectura cliente/

3 servidor de varios niveles, los cuales se detallan a continuación. Nivel de almacenamiento de datos, que se corresponde con el servidor en el que está

4 instalado el SGBD relacional. Nivel de aplicación, que se corresponde con un servidor Windows o Unix, en el que se ejecutan la mayoría de los procesos de Meta4 lanzados por el servidor de aplicaciones. Nivel de presentación, el cual se corresponde con los equipos cliente. La arquitectura cliente/servidor de varios niveles garantiza el rendimiento del sistema y su escalabilidad, pues en cualquier momento se puede aumentar el número de servidores de bases de datos y de aplicaciones para atender mayor cantidad de servidores de aplicaciones y puestos de trabajo cliente Elementos principales del Sitio de Meta4 El servidor de aplicaciones: El servidor de aplicaciones es el componente de la arquitectura de las aplicaciones de Meta4 que actúa como intermediario entre los clientes y los servidores de base de datos. El servidor de aplicaciones hace posible que las aplicaciones de Meta4 sean escalables, articulando una arquitectura de múltiples niveles. Para facilitar la tolerancia a fallos, la escalabilidad y la redundancia de las aplicaciones de Meta4, varios servidores de aplicación pueden instalarse en una o varias máquinas, y dar servicio de modo transparente a modo de cluster. Cuando varios servidores de aplicaciones se agrupan en una sola unidad lógica, se habla de Meta4 Server Site (M4SS) o Sitio de Meta4. Los servidores de aplicaciones atienden las solicitudes de los puestos cliente e implementan la interfaz entre los procesos de aplicación y los datos gestionados por los servidores de bases de datos. Básicamente se encarga de ejecutar las operaciones de lectura y escritura sobre la base de datos y enviar los resultados obtenidos a los puestos clientes. Está orientado a la ejecución de Meta4Objects. Para que se produzca esta comunicación, los servidores de aplicaciones necesitan disponer de conexión a la base de datos; es decir, en los servidores de aplicaciones debe instalarse el middleware propietario de cada fabricante de base de datos y los controladores ODBC si son necesarios. El servidor de aplicaciones puede residir en una plataforma con Windows o con UNIX. Cada servidor de aplicaciones de Meta4 es un único proceso multihilo cuya misión es ejecutar las peticiones que recibe por parte de los clientes. En una configuración típica, los clientes (cliente distribuido o aplicación web de Meta4, por ejemplo) se conectan por TCP/IP a un puerto en el que el servidor de aplicaciones acepta sus peticiones de ejecución. Site Dispatcher: En un entorno con mayor demanda de recursos, puede ser necesario que sean varios procesos, en uno o varios sistemas, los que aceptan las peticiones de

5 los clientes. Para ello, se utiliza un elemento distribuidor de carga, llamado Site Dispatcher. Los clientes se conectan al dispatcher, que actúa de modo transparente al usuario, como si se tratara de un servidor de aplicaciones, pero repartiendo la carga equilibradamente entre varios procesos redundantes. Application Controller: El dispatcher necesita que, en cada uno de los sistemas en los que existan servidores de aplicaciones, que se instale un elemento adicional, el Application Controller, para poder comunicarse con cada servidor que forma parte del sitio. El dispatcher y el controller desempeñan una función adicional que es proporcionar tolerancia a fallos al servidor de aplicaciones de Meta4. Si existiera cualquier incidencia (por ejemplo, caída de servicios de red o base de datos), que causase la detención de uno de los servidores de aplicaciones, el dispatcher recibiría esta información, e intentaría reiniciarlo remotamente para que volviera a proporcionar servicio lo más pronto posible Tipos de instalación. El Sitio de Meta4 se puede instalar de una de las maneras siguientes: Instalación simple de un solo servidor de aplicaciones: Estaría compuesto por un Servidor de aplicaciones sin Application Controller ni Dispatcher en una máquina física. Instalación de un sitio de servidores de aplicaciones: Estaría compuesto por una instancia de Servidor de aplicaciones, un Application Controller y un Dispatcher en la misma máquina. Instalación de un sitio de múltiples servidores: Estaría compuesto por varias instancias de un Servidor de aplicaciones, un Application Controller y un Dispatcher en la misma máquina. Instalación avanzada, basada en el Editor de configuraciones: Se utiliza para crear un M4SS completo, como el instalado en la Universidad de Córdoba, formado por varias máquinas físicas en las cuales existe una o varios servidores de BBDDs, varias instancias del servidor de aplicaciones distribuidas en diferentes máquinas y varios dispatcher, en una o varias máquinas distribuidas Arquitectura de Meta4 en la Universidad de Córdoba La arquitectura existente en la Universidad de Córdoba es la que se describe a continuación. 2 entornos, producción y desarrollo. Desarrollo instalación todo en la misma máquina. Tiene activas todas las trazas y ficheros de log Producción distribuido en 3 máquinas con instalación avanzada, basada en el editor de configuraciones. Portal del empleado

6 Servidor de aplicaciones principal (incluye Dispacher, Tomcat, M4UpdateService y M4Gateway). Servidor de aplicaciones secundario. Existen 3 instancias por máquina, si bien funcionan solo 2 y la otra queda en reserva.. El sistema reserva numerosos puertos para los diferentes servicios: Controller, Dispatcher, Servicios web,... Para la gestión de memoria se reservan umbrales: 0-90% (0 1300Mb): normal 85 95% ( Mb): alert > 90% (> 1450 Mb): critical EL JobScheduler se configura con 12 ejecutores. Se utiliza SSL en la conexión web. La BBDD producción es Oracle 11g. La BBDD Desarrollo es también Oracle 11g. La versión instalada es 7.1 sp6 El acceso se realiza mediante clientes windows virtuales (clientes ricos) instalados en un proxmox. Existe un pound para distribuir la url, según sea producción o desarrollo Subsistemas del servidor de aplicaciones de Meta4 El servidor está estructurado en un conjunto de subsistemas, cada uno de los cuales gestiona aspectos distintos de su funcionamiento Subsistemas de ejecución Realizan los procesos solicitados al Servidor de aplicaciones de Meta4. Se divide a su vez en varios subsistemas. Los tres primeros tipos de ejecución, OLTP, Delta y Proxy necesitan una conexión en tiempo real entre los puestos cliente y los servidores de aplicaciones. La ejecución programada no necesita una conexión en tiempo real entre el cliente y el servidor Transaccional (OLTP: On Line Transaction Processing) Cada ejecución es una operación independiente, cuya información de estado no se almacena

7 en el servidor. El modo OLTP está orientado a conexión Delta Transaccional Optimizado (OLTP) Cada ejecución es una operación independiente, en la que el servidor retiene información sobre el cliente y sobre el estado de la transacción, lo cual permite reducir los datos enviados desde el cliente al servidor en cada transacción, trabajando sólo con los cambios respecto a la última transacción cliente-servidor Conversacional (Proxy) En el modo Proxy el cliente establece una sesión de trabajo con el servidor, éste ejecuta el proceso y envía los resultados al cliente. Sin embargo, a diferencia de lo que sucede en el modo OLTP, el servidor retiene información sobre el cliente y sobre el estado de la transacción. El modo Proxy permite al cliente ejecutar una consulta compleja a la base de datos, y recuperar los resultados de manera progresiva. Se dice que el modo Proxy está orientado a sesiones Ejecución programada (Planificador de tareas: Job Scheduler) El puesto cliente solicita la ejecución de un proceso a un servidor determinado indicando la fecha y hora en la que quiere que comience la ejecución del proceso o bien indicar que el proceso se ejecute tan pronto como sea posible. Cuando el servidor recibe la orden de ejecución de una tarea programada recupera la tarea de la base de datos, verifica que el usuario y su rol son válidos, y tras procesar toda la información solicitada, almacena los resultados e intenta enviarlos al cliente, si es posible Subsistemas auxiliares o de servicios Son aquellos subsistemas que aportan los servicios necesarios para enlazar los subsistemas de ejecución con el resto de componentes del sistema. Se divide a su vez en varios subsistemas Subsistema de comunicaciones Este subsistema, basado en colas, establece y finaliza las comunicaciones necesarias entre las diferentes aplicaciones cliente, dirige sus peticiones hacia el módulo de ejecución apropiado y proporciona la respuesta correspondiente a quien la solicitó Subsistema de base de datos lógica Se trata de un subsistema que ofrece a los módulos de ejecución acceso a los datos. Su responsabilidad incluye abrir y agrupar conexiones a la base de datos física, así como enviar y recibir los datos entre los módulos de ejecución y la base de datos física, ofreciendo lo que se denomina conexiones lógicas.

8 Subsistema de usuarios Gestiona el acceso de los usuarios al Servidor de aplicaciones de Meta4 (autenticación del usuario y la autorización en función de su rol, gestión de sesiones abiertas,...) Subsistema de metadatos La definición de los Meta4Objects, las presentaciones y las máscaras de seguridad son clases de metadatos. Tanto el servidor como el cliente necesitan utilizar metadatos para ejecutar procesos lógicos. Los clientes obtienen los metadatos del servidor mediante un protocolo basado en el estándar TCP/IP, mientras que el servidor trabaja con ellos de forma interna Subsistema de cache Permite reutilizar los elementos idénticos que solicitan distintos componentes de la aplicación, lo que evita la duplicación de información en el servidor. Cada componente, antes de crear un elemento, obtiene acceso a la caché para ver si ya existe, y si es así, toma una referencia de su ubicación. Para evitar que el tamaño de la caché sea desmesurado, se utiliza una política de tiempo de validez, transcurrido el cual, si no se obtuvo acceso a la información contenida, ésta se limpia del mapa Subsistema XML El subsistema XML proporciona los servicios necesarios para que los clientes ligeros HTML se conecten al Servidor de aplicaciones a través de un servidor Web Subsistema de trazas El subsistema de trazas se encarga de gestionar todas las trazas y logs del sistema. Se divide en tres subsistemas Subsistema de logs Desde este subsistema se puede cambiar ciertos parámetros de trazabilidad del archivo logfile.html (tamaño máximo de los archivos de log y habilitar o deshabilitar cada uno de los tipos de trazas según el grado de severidad que se necesite documentar) Subsistema de trazas de máquina virtual Permite hacer un seguimiento de las PDU s en la gestión de las transmisión de datos entre los componentes de la arquitectura Subsistema de trazas de benchmark Permite ver y modificar el tamaño máximo del archivo benchmark que contiene el volcado de los tiempos de ejecución.

9 Subsistema de control de memoria Este subsistema permite parametrizar los límites de los niveles de la memoria. Además permite establecer los niveles de criticidad del consumo de los recursos de memoria, mediante la definición de umbrales inferiores y superiores por nivel Editor de configuraciones Es una aplicación escrita en Java denominada m4appconfig y que permite modificar los campos de los archivos de configuración del servidor que han de modificarse con más frecuencia. Esta herramienta también permite configurar los otros componentes del Sitio de Meta4, como el Application Controller y el Site Dispatcher. Existe una versión para Windows y otra para Unix, que es la utilizada por la Universidad de Córdoba El monitor del Servidor de aplicaciones El monitor del Servidor de aplicaciones es una herramienta desarrollada para el sistema Windows, que facilita al administrador la supervisión de cualquier servidor en funcionamiento. El Monitor no sólo hace un seguimiento de los servidores, sino que es la herramienta diseñada para iniciarlos y detenerlos. Además se conecta con el Site Dispatcher, a través del cual controla todos los servidores del Sitio de Meta4. Entre los datos que se muestran, destacan si una instancia está arrancada o parada, así como el número de sesiones activas por instancia, junto con el consumo de la máquina y de CPU del host en el que se encuentra corriendo dicha instancia. El acceso desde el monitor de administración al Dispatcher se puede restringir a un conjunto de puestos de administración. Para ello es necesario crear manualmente un fichero de nombre m4dspadmhosts.ini en el directorio conf del Dispatcher y añadir la lista de puestos autorizados, en base a su dirección IP. En caso de no existir el fichero (defecto) o encontrarse vacío, se asume que todos los puestos están autorizados Servidores de bases de datos En los servidores de bases de datos reside la base de datos física. Las características más destacables de la arquitectura Meta4 son: Independencia del sistema respecto a los fabricantes de SGBD relacionales, pues el sistema gestor de bases de datos actúa como un "repositorio" de información. Todas las comprobaciones sobre la validez e integridad de los datos se realizan en los servidores de aplicaciones, a través de la base de datos lógica (BDL). El hecho de que todas las validaciones de datos y los procedimientos se ejecuten en servidores de aplicaciones, o en máquinas cliente garantiza la independencia respecto al SGBD relacional.

10 Minimiza el tiempo necesario para el desarrollo de nuevas funcionalidades. Minimiza los requerimientos de red y optimiza el rendimiento de la red corporativa, ya que únicamente se transmite a los servidores de datos información ya validada por la BDL de los servidores de aplicaciones Posibilidad de trabajar con bases de datos distribuidas de distintos fabricantes. Optimización y accesibilidad en las conexiones al servidor de base de datos, pues puede determinarse el número de conexiones lógicas a la base de datos mediante opciones de configuración. De este modo, no podrán ejecutarse procesos que impliquen que se supere el número de conexiones lógicas parametrizadas en la configuración Puestos cliente Los puestos cliente desde los cuales los usuarios trabajan con la aplicación, implementan el nivel de presentación del sistema. Meta4 distribuye varios tipos de software cliente: Clientes de desarrollo: Emulan la funcionalidad de aquél y se conectan directamente al servidor de base de datos para trabajar en modo local. Puestos clientes en entorno Web (cliente ligero): Los clientes ligeros permiten acceso solo a determinados módulos de la aplicación a través de un explorador capaz de interpretar HTML estándar. Tras acceder a la base de datos y realizar las tareas solicitadas, devuelve el resultado al servidor web, en donde el cliente ligero se encarga de transforma esta respuesta en código HTML. Puestos cliente rico (rich web): Estos clientes implementan el nivel de presentación en un entorno HTML y permiten ejecutar procesos de aplicación en local en lugar del servidor en la medida que sea posible. En la actualidad, el cliente rico de Meta4 solamente funciona con Internet Explorer, por lo que es obligatorio el uso de un sistema Windows, razón por la cual los escritorios corporativos de los usuarios de la Universidad autorizados para utilizar la aplicación Meta4 deben acceder a un S.O. Windows Ficheros de configuración DIRECTORIO PRINCIPAL DE INSTALACIÓN (todos los hosts): /NAS/meta4 Controller: /m4serversite/m4appctl/conf m4appctl.conf: Indica la relación de instancias del Serv. de Aplic. que se controllan. Se indican los puertos de configuración del controller (puerto base y administración). Se configura con la herramienta m4appconfig.ksh del directorio setup. Dispatcher: /m4serversite/m4dispatcher/conf m4dsptarget.xml: Indica las instancias de servidor que deben activarse en el

11 arranque del servidor. Se indica el host, el nombre de la instancia, el puerto base de la misma, el usuario administrativo y la clave encriptada. El último parámetro "enabled" indica si la instancia está habilitada o no. Cada vez que el dispatcher intenta levantar una instancia el fichero se cambia. m4dspini.xml: Fichero de inicialización. Indica el puerto base, el host y el nombre de la configuración de todos los controller que dirige el dispatcher. Se puede especificar el número de reintentos para levantar el controller y cada cuanto tiempo se reintenta. Instancias meta4_x / zmeta4_dsrx regmeta4.reg: Fichero para activar/desactivar trazas. startup.obl: Configura el dimensionamiento del servidor, los ejecutores, los umbrales de memoria, los time-out, los puertos base, etc. Se configura con la herramienta m4appconfig.ksh del directorio setup. ssc_appuser: Especifica el usuario/clave del usuario administrador de la aplicación de Meta4. Está cifrado en base a la configuración del host. Servicios Web: /WEB-INF/classes/properties/ configclient.xml: Incluye los datos necesarios para que una petición html pueda conectarse al Serv. de Aplic., la página de login, la de redirección de error, el puerto de conexión Arranque automático del entorno Script: meta4ctl.sh Para arrancar y/o parar los distintos componentes del entorno de Meta4 es preciso ejecutar una serie de scripts que se encuentran localizados en los siguientes directorios que se describen a continuación: Controller Directorio ejecución: /m4serversite/m4aappclt/bin Arranque:./m4kshappctl start Parada:./m4kshappctl stop Dispatcher Directorio ejecución: /m4serversite/m4dispatcher/bin Arranque:./m4kshdispatcher start Parada:./m4kshdispatcher stop Instancia del servidor de aplicaciones (modo stand-alone)

12 Directorio ejecución: /m4serversite/zmeta4_x Arranque:./m4kshserver start Parada:./m4kshserver stop Servidor Web TOMCAT Directorio ejecución: /jakarta-tomcat /bin Arranque:./startup.sh start Parada:./startup.sh stop

13 2.- Administración de VEGA Introducción a Sigma SIGMA Gestión Universitaria A.I.E. es una agrupación de interés económico integrada por varias Universidades españolas y otras instituciones privadas del ámbito de la enseñanza superior, a las que se unió la Universidad de Córdoba en enero de Entre estas aplicaciones se encuentra el Sistema de Gestión Académica Avanzado VEGA, que está formado por tres módulos: SIGMA: Es el módulo que gestiona los estudios oficiales de 1º y 2º Ciclo (futuros grados), así como los estudios de Doctorado y estudios oficiales de Postgrado. ATLAS: Aplicación orientada a la gestión de la ordenación docente (definición de oferta académica, planes de docencia, definición de grupos de docencia, asignación de profesorado, etc) ORION: Aplicación orientada a la gestión de los estudios propios de la Universidad. VEGA ofrece también otras aplicaciones que no van a ser objeto de implantación en la Universidad de Córdoba, pero que pertenecen al entorno de VEGA. ARGOS: Destinada a la gestión de la investigación PERSEO: Destinada a la formación continua del PDI y del PAS. SIGMA está dirigida a todos los colectivos de la universidad (alumnos, docentes y P.A.S.). El alumno tiene la posibilidad de resolver vía Web aquellas gestiones que se realizan habitualmente en ventanilla mediante el módulo Secretaría Virtual. El docente puede disponer de toda la información actualizada de sus grupos de docencia en el módulo de Campus Docente desde su propio ordenador. La automatrícula SIGMA optimiza los periodos de matriculación, reduciendo su duración mediante la automatización de los procesos, sin requerir un esfuerzo adicional de las personas. Contempla las adaptaciones relativas al Espacio Europeo de Educación Superior, tanto el Suplemento al Diploma como los créditos ECTS Ámbitos de actuación Datos Generales. Gestión fácil e intuitiva de la información que se considera genérica a toda la aplicación. Accesos. Gestiona la información asociada a los diferentes tipos de acceso mediante los cuales las universidades permiten a los alumnos iniciar los distintos estudios que en éstas se imparten.

14 Mayores de 25 años. Gestiona todo el circuito de un alumno que se matricula para las pruebas de acceso de Mayores de 25 años. Planes de Estudio. Permite modelar un plan de estudios gráficamente describiendo los diferentes itinerarios que puede escoger un alumno así como la distribución de las asignaturas en cursos, ciclos, especialidades y las relaciones de incompatibilidad entre ellas. Validación Académica. Garantiza que la información académica del alumno sea coherente con el plan de estudios y las normas académicas vigentes durante el periodo docente del alumno. Matrícula. Permite que las secretarías de los centros matriculen a los alumnos o que éstos se automatriculen por Internet. Tasas. Gestiona la parte económica de la gestión académica de la Universidad. Certificados: Permite realizar toda la gestión administrativa relacionada con los pagos, bien con el alumno, o bien con la entidad financiera. Becas. Gestión completa de las becas de Régimen General y Movilidad que el MECD convoca cada año. incluye tanto la recogida de las solicitudes y el posterior envío al MECD, como el tratamiento de modificaciones, reclamaciones, traslados, revocaciones y otros procesos. Expedientes. Gestiona y almacena la información relativa a conocimientos adquiridos por el alumno en otros centros y/o estudios e incorpora esta información a su expediente. Secretaría Virtual. Aquellas gestiones que habitualmente realiza un alumno en la ventanilla de su centro administrativo, ahora pueden realizarse desde cualquier ordenador, como por ejemplo, la automatrícula, la consulta del expediente, la solicitud de títulos, etc. Exámenes. Gestión completa de las actas y convocatorias de examen. Incluye gestión de versiones de acta para mantener el histórico de toda acción sobre las mismas. Campus docente. Soluciona necesidades de gestión del docente con sus alumnos y con la organización administrativa de la universidad. Confecciona y mantiene las fichas informatizadas de los alumnos incluyendo su foto. Permite la entrada y modificación de calificaciones (mediante nota final o plantillas definidas por el profesor), emisión de listas de calificaciones, estadísticas gráficas de las calificaciones, etc. Certificados. Definición y emisión de los diferentes certificados o documentos que la universidad expide dando fe de sus contenidos. Títulos. Gestiona todo el proceso de un título, desde que éste se solicita a la universidad, hasta que es entregado al alumno correspondiente. Estadísticas. Generación de cintas y listados estadísticos que se entregan cada año a la Secretaría General del Consejo de Universidades, al Instituto Nacional de Estadística (INE), y a la Dirección General de Universidades (DGU).

15 2.3.- Arquitectura de Sigma en la UCO

16 Nuestro Balanceador de carga es por software haciendo uso de una herramienta open source llamada Pound que utilizamos para centralizar el acceso de todas nuestras aplicaciones vía web (incluida Sigma), que corre bajo un Debian 5 virtualizado con OpenVZ, con 1 GB. Nuestras máquinas para los WebServers y AppServers (1, 2 y 3) son zonas de 3 máquinas distintas (una T5000 y dos T6000), con sistema de ficheros ZFS, 16 GB de RAM y 64 Threads (8 procesadores de doble núcleo, con 4 thread cada núcleo: 8 x 2 x 4), con Solaris 10. La máquina de la bb.dd. es una zona de una M5000, con sistema de ficheros ZFS, 32 GB de RAM y 32 Threads (4 procesadores de doble núcleo, con 4 thread cada núcleo: 4 x 2 x 4), con Solaris 10. Utilizamos la JDK de 32 bits para todo. Los servidores Web son Sun One Web Server 6.1 update 11. Los servidores de aplicaciones son Sun GlassFish Enterprise Server 2.1 con profile enterprise. La forma de trabajar es la siguiente:

17 El usuario final accede a Sigma a través del balanceador de carga que lo redirige a uno de los tres servidores web de que disponemos (cada servidor web esta asociado a una y sola una instancia, la que corre en su misma máquina). Las tres instancias están en cluster, lo que facilita su mantenimiento, administración e instalación de productos desde el DAS que está en la primera. Para GECO se ha creado una instancia independiente, que como vimos no tiene asociado ninguna aplicación salvo la gestión de colas (QMN). Los scripts de GECO se comunican con esta instancia y la generación del listado se lanza posteriormente al balanceador para desligarlo completamente de las instancias que forman el cluster. Para el acceso a la bbdd. se han definido 8 pools de conexión para Sigma y 1 para Navega. Cada pool dispone de 32 conexiones del tirón (mínimo y máximo), por lo que existen disponibles 256 conexiones (8x32) para Sigma y 32 para Navega, por cada instancia. En total con las 3 instancias disponemos de 768 (3x256) conexiones para Sigma y 96 (3x32) Navega. La instancia de GECO también tiene asociados los mismo pools, disponiendo de 256 (8x32) para Sigma y 32 para Navega. En total tenemos levantadas conexiones contra la bb.dd. ( ) Scripts de monitorización de AppServer / WebServer Comentarte también, que tanto el AppServer como el WebServer disponen de scripts de monitorización que utilizan los técnicos para enviarles qué está pasando en el sistema cuando se abre una incidencia con ellos, pero que también se pueden utilizar para recoger todo tipo de información sobre qué esta pasando y poder extraer alguna conclusión, en el momento en el que se produce algún cuelgue Script de monitorización de Sigma Existe un script para arrancar, parar o ver el estado del entorno de Sigma, denminado sigmactl. Tiene un fichero de propiedades que recoge toda la configuración del entorno, modificable para producción o desarrollo, de forma que no haya que tocar para nada el script al cambiar de entorno, al ampliar o reducir el número de instancias, cambiar puertos, pools, nombres, etc.