Embed Size (px)
Citation preview
ADMINISTRACIÓN DE META4 PEOPLENET Y VEGA EN LA UCO
Índice de contenido
1.- Administración de Meta4 PeopleNet...........................................................................................2
1.1.- Introducción a Meta4.......................................................................................................2
1.2.- Características................................................................................................................2
1.3.- Arquitectura genérica en 3 niveles de Meta4........................................................................2
1.4.- Elementos principales del Sitio de Meta4 ............................................................................4
1.5.- Tipos de instalación.........................................................................................................5
1.6.- Arquitectura de Meta4 en la Universidad de Córdoba............................................................5
1.7.- Subsistemas del servidor de aplicaciones de Meta4..............................................................6
1.7.1.- Subsistemas de ejecución..........................................................................................6
1.7.1.1.- Transaccional (OLTP: On Line Transaction Processing).............................................6
1.7.1.2.- Delta Transaccional Optimizado (OLTP).................................................................7
1.7.1.3.- Conversacional (Proxy)......................................................................................7
1.7.1.4.- Ejecución programada (Planificador de tareas: Job Scheduler).................................7
1.7.2.- Subsistemas auxiliares o de servicios..........................................................................7
1.7.2.1.- Subsistema de comunicaciones...........................................................................7
1.7.2.2.- Subsistema de base de datos lógica.....................................................................7
1.7.2.3.- Subsistema de usuarios.....................................................................................8
1.7.2.4.- Subsistema de metadatos..................................................................................8
1.7.2.5.- Subsistema de cache.........................................................................................8
1.7.2.6.- Subsistema XML................................................................................................8
1.7.3.- Subsistema de trazas................................................................................................8
1.7.3.1.- Subsistema de logs...........................................................................................8
1.7.3.2.- Subsistema de trazas de máquina virtual..............................................................8
1.7.3.3.- Subsistema de trazas de benchmark....................................................................8
1.7.3.4.- Subsistema de control de memoria......................................................................9
1.8.- Editor de configuraciones.................................................................................................9
1.9.- El monitor del Servidor de aplicaciones...............................................................................9
1.10.- Servidores de bases de datos..........................................................................................9
1.11.- Puestos cliente............................................................................................................10
1.12.- Ficheros de configuración..............................................................................................10
1.13.- Arranque automático del entorno ..................................................................................11
2.- Administración de VEGA........................................................................................................13
2.1.- Introducción a Sigma.....................................................................................................13
2.2.- Ámbitos de actuación.....................................................................................................13
2.3.- Arquitectura de Sigma en la UCO.....................................................................................15
2.4.- Scripts de monitorización de AppServer / WebServer..........................................................17
2.5.- Script de monitorización de Sigma...................................................................................17
1.- Administración de Meta4 PeopleNet
1.1.- 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.
1.2.- 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.
1.3.- Arquitectura genérica en 3 niveles de Meta4
La aplicación Meta4 está especialmente optimizada para trabajar en una arquitectura cliente/
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á
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.
1.4.- 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
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.
1.5.- 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 aplicacione s: 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.
1.6.- 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
– 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% (1200 – 1500Mb): 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.
1.7.- 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.
1.7.1.- 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.
1.7.1.1.- Transaccional (OLTP: On Line Transaction Processing)
Cada ejecución es una operación independiente , cuya información de estado no se almacena
en el servidor. El modo OLTP está orientado a conexión.
1.7.1.2.- 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.
1.7.1.3.- 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.
1.7.1.4.- 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.
1.7.2.- 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.
1.7.2.1.- 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ó.
1.7.2.2.- 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.
1.7.2.3.- 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,...)
1.7.2.4.- 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.
1.7.2.5.- 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.
1.7.2.6.- 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.
1.7.3.- Subsistema de trazas
El subsistema de trazas se encarga de gestionar todas las trazas y logs del sistema. Se divide
en tres subsistemas.
1.7.3.1.- 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)
1.7.3.2.- 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.
1.7.3.3.- 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.
1.7.3.4.- 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.
1.8.- 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.
1.9.- 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.
1.10.- 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.
• 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.
1.11.- 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.
1.12.- 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
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.
1.13.- 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)
Directorio ejecución: /m4serversite/zmeta4_x
Arranque: ./m4kshserver start
Parada: ./m4kshserver stop
• Servidor Web TOMCAT
Directorio ejecución: /jakarta-tomcat-5.0.28/bin
Arranque: ./startup.sh start
Parada: ./startup.sh stop
2.- Administración de VEGA
2.1.- 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 2008.
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.
2.2.- Á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.
• 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).
2.3.- Arquitectura de Sigma en la UCO
• 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 1.6.0.14 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:
◦ 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 1.152 conexiones
contra la bb.dd. (768+96+256+32).
2.4.- 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.
2.5.- 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.
