Manual JBoss

1

ÍndiceCapítulo I : Instalación de JBoss...........................................................................4

Introducción.....................................................................................................4Pasos Previos...................................................................................................4

Instalación del JDK (JSE) ..............................................................................4Instalación de JBoss ....................................................................................4

Estructura ................................................................................................5Ejecución ........................................................................................................6

Configuración ..............................................................................................7Capítulo II: Despliegue de Aplicaciones...............................................................9

Introducción.....................................................................................................9Despliegue en caliente....................................................................................9Estructura del descriptor de despliegue..........................................................9Estructura de un paquete de aplicación........................................................10

Capítulo III: Integración de JBoss con Eclipse....................................................12Introducción...................................................................................................12Obtener Eclipse..............................................................................................12Configurar Eclipse con JBoss..........................................................................14

Capítulo IV : Monitorización...............................................................................19Introducción...................................................................................................19Arquitectura de JMX.......................................................................................19Monitorización de JBoss.................................................................................20Monitorización con JConsole .........................................................................21Monitorización con ManageEngine Applications Manager.............................23Monitorización con Munin..............................................................................30

Instalación de munin-master......................................................................31Instalación en Debian/Ubuntu................................................................31Instalación en CentOS............................................................................31

Configuración del munin-master................................................................32Instalación de munin-node.........................................................................33

Instalación en Debian/Ubuntu................................................................33Instalación en CentOS............................................................................33

Arrancar el servicio munin-node................................................................34Informes.....................................................................................................35Escribir plugins para munin utilizando JMX................................................37

Formato de un plugin munin..................................................................39Conclusión..................................................................................................42

Monitorización con Nagios.............................................................................43Introducción...............................................................................................43Requisitos...................................................................................................43

Instalación.....................................................................................................43Escribir plugins para nagios utilizando JMX................................................46

Capítulo V: JAAS.................................................................................................50Configuración de la seguridad estándar en la aplicación web.......................50Configurar un módulo de login JAAS..............................................................50Configuración de la seguridad específica de JBoss en la aplicación web.......51Creación de tablas y carga de datos en SQL.................................................51Definición del datasource y configuración de la política de seguridad en

2

JBoss..............................................................................................................53Capítulo VI : Clustering......................................................................................55

Configuración de JGroups...............................................................................55Ejecución del cluster......................................................................................56Apache mod_jk..............................................................................................57

Propiedades Globales.................................................................................59Propiedades de los workers........................................................................60

Variables, Variables de entorno..............................................................60Propiedad de herencia............................................................................60Lista de directivas de los workers...........................................................61Directivas de balanceo de carga............................................................62

Cluster HA......................................................................................................64Capítulo VII: Optimización de JBoss...................................................................70

Elección de la JVM..........................................................................................70JVM Heap ...................................................................................................71

Optimización de Tomcat.................................................................................71Eliminar directorios de trabajo.......................................................................72Comportamiento de la carga de clases..........................................................72Optimización de JSP........................................................................................72Optimización de Log4J...................................................................................73

El mbean de registro..................................................................................73Deshabilitar el registro por consola........................................................73Cambiar el nivel de registro...................................................................74

3

Capítulo I : Instalación de JBoss

Introducción.

JBoss es un servidor de aplicaciones J2EE de código abierto implementado en Java puro. Al estar basado en Java, JBoss puede ser utilizado en cualquier sistema operativo que lo soporte. Los principales desarrolladores trabajan para una empresa de servicios, JBoss Inc., adquirida por Red Hat en Abril del 2006, fundada por Marc Fleury, el creador de la primera versión de JBoss. El proyecto está apoyado por una red mundial de colaboradores. Los ingresos de la empresa están basados en un modelo de negocio de servicios.JBoss implementa todo el paquete de servicios de J2EE.

Pasos Previos.

Instalación del JDK (JSE)

La base para operar cualquier producto que utiliza "Java" es el "JDK" de la plataforma correspondiente, puede encontrar instrucciones para plataformas Linux así como Windows, en http://java.sun.com

Instalación de JBoss

Una vez obtenido el archivo tar o exe (depende del sistema operativo) de http://www.jboss.org que contiene el binario, este debe ser instalado (o descomprimido en Linux) en un directorio temporal (/tmp por lo general) para poder iniciar la instalación.

El paso anterior genera un directorio por nombre JBoss-<numero_de_version> dentro del directorio temporal (/tmp) si desciende a este directorio observará el directorio jboss el cual contiene la distribución de Jboss.

Cabe mencionar que la versión de Tomcat incluida en JBoss es idéntica a la proporcionada en http://jakarta.apache.org/tomcat , la única diferencia es que los archivos de configuración para JBoss se encuentran adaptados a Tomcat.

Se recomienda movilizar el directorio jboss al directorio /usr/local, además se recomienda definir la variable ambiental JBOSS_HOME al archivo /etc/bashrc , si no esta familiarizado con ambientes *nix, esto significa agregar la linea: export JBOSS_HOME=/usr/local/jboss;; para instalaciones Windows esta variable ambiental puede ser definida de la misma manera que CLASSPATH, descrita en las instrucciones del JDK.

4

Estructura

bin

Este directorio contiene los ejecutables utilizados por JBoss, el más importante siendo el "script" de arranque utilizado por éste (run.sh)

client

Contiene los diversos archivos JAR's que serán utilizados por los distintos clientes de los EJB's utilizados en JBoss. Dichos archivos deben ser agregados a la variable CLASSPATH del sistema donde radica el cliente; el cliente generalmente siendo un JSP/Servlet que accesa el EJB, este paradigma gira alrededor de Stubs/Skeletons de RMI una parte central de EJB's.

docs

Este directorio contiene documentación acerca de JBoss.

lib

Este directorio contiene los archivos JAR's empleados por JBoss requeridos en cualquier modalidad.

server

Este directorio contiene tres sub-directorios nombrados: all, default y minimal; cada sub-directorio contiene los distintos archivos de configuración necesarios para ejecutar JBoss en diferentes modalidades.

La modalidad all incluye la ejecución de JBoss para emplearse como cluster, ejecución de webservices y otras funcionalidades más; el directorio default como su nombre lo implica, incluye la configuración para ejecutar JBoss de manera básica, mientras el directorio minimal contiene los valores de configuración necesarios para ejecutar JBoss con requerimientos mínimos; el script de arranque proporcionado con JBoss emplea los valores del directorio default, para emplear otra modalidad es necesario modificar dicho script de arranque (run.sh).

A continuación se describen los directorios residentes en la modalidad de arranque default:

conf

Este directorio contiene las diferentes secciones de configuración utilizadas por JBoss, dependiendo de la modalidad utilizada este directorio puede contener distintos archivos , sin embargo, sus detalles serán descritos

5

en configuración de JBoss .

data

Contiene distintos parámetros y archivos de configuración para las Bases de Datos proporcionadas con Jboss, generalmente utilizada para aplicaciones demo.

deploy

Este directorio es ampliamente utilizado ya que aquí se colocan los EJB's para que sean ejecutados por JBoss, una vez colocado el archivo JAR (en forma de EJB) en este directorio, JBoss automáticamente expande y ejecuta el EJB.

lib

Contiene los archivos JAR's empleados por JBoss en base a la modalidad tratada.

log

Contiene los distintos registros generados por JBoss. tmp

Contiene archivos creados por JBoss y utilizados de manera temporal.

work

Contiene las clases y archivos utilizados por JBoss para ejecución.

Ejecución

La ejecución de JBoss es relativamente sencilla, dentro del directorio bin de la instalación de JBoss se encuentran los archivos de arranque en forma de scripts para Shell. El archivo de ejecución run.sh es utilizado para iniciar JBoss en ambientes *nix con los parámetros encontrados en el directorio server/default/conf, de igual manera, el archivo run.bat lo hace para ambientes Windows.

Debe observar algo similar al siguiente desplegado; los detalles de estos parámetros son aquellos definidos en la configuración de JBoss e incluyen: bases de datos para trabajar con JBoss, ubicación de registros, parámetros JNDI, EJB's disponibles y cargados, entre otra información.

[root@jboss]$ ./run.sh=========================================================================  JBoss Bootstrap Environment  JBOSS_HOME: /tmp/jboss­5.0.0  JAVA: /usr/local/jdk1.6.0//bin/java

6

  JAVA_OPTS: ­server ­Dprogram.name=run.sh  CLASSPATH: /tmp/jboss­5.0.0/bin/run.jar:/usr/local/jdk1.6.0//lib/tools.jar=========================================================================12:55:10,608 INFO  [Server] Starting JBoss (MX MicroKernel)...12:55:10,610 INFO  [Server] Home Dir: /tmp/jboss12:55:10,610 INFO  [Server] Home URL: file:/tmp/jboss/12:55:10,623 INFO  [Server] Library URL: file:/tmp/jboss/lib/12:55:10,625 INFO  [Server] Patch URL: null

........    < 50­70 lineas >..............

12:55:31,862 INFO   [Http11Protocol] Starting Coyote HTTP/1.1 on http­0.0.0.0­808012:55:32,074 INFO  [ChannelSocket] JK2: ajp listening on /0.0.0.0:801012:55:32,192 INFO  [JkMain] Jk running ID=1 time=0/149  config=null12:55:32,216 INFO  [Server] JBoss (MX MicroKernel) Started in 21s:146ms

Esta pantalla donde se ejecuta JBoss permanecerá congelada por el término en que este activo JBoss, a esta pantalla se enviarán entre otras cosas:

• Los errores de ejecución• Resultados de agregar EJB's al directorio deploy de Jboss

Desde luego este comportamiento es modificable pero por ahora es el comportamiento default de Jboss.

Para finalizar JBoss basta ejecutar Ctrl-C bajo la pantalla en cuestión y JBoss será terminado, en el proceso desplegando ciertos mensajes de terminación.

Configuración

JBoss esta compuesto por diversos archivos de configuración los cuales se encuentran bajo el directorio /server/<modalidad>/conf de la instalación de JBoss, este directorio a su vez puede contener varios subdirectorios (como fue mencionado en la instalación y estructura ), esta sección se basa en el contenido del directorio default.

A continuación se mencionan los parámetros de los principales archivos para la modalidad default, lo cual equivale al contenido del directorio /server/default/conf.

jboss-minimal.xml

Archivo que contiene los parámetros principales para la configuración default de JBoss; este archivo XML define los valores para la variable CLASSPATH, el puerto para el servidor JNDI y el directorio donde serán colocados los distintos EJB's para ser ejecutados, entre otros parámetros.

7

jboss-service.xml

Archivo que contiene los parámetros principales del Servidor JBoss; este archivo XML define los valores para la variable CLASSPATH, el puerto para el servidor JNDI y el directorio donde serán colocados los distintos EJB's para ser ejecutados, entre otros parámetros como usuarios y roles disponibles para emplear el sistema messaging proporcionado con JBoss.

jndi.properties

Contiene las Clases que serán utilizadas ("Factory's") para realizar búsquedas JNDI.

log4j.xml

Contiene los parámetros empleados por el mecanismo Log4J utilizado en JBoss para generar registros.

login-config.xml

Contiene los parámetros JAAS empleados por JBoss para verificar/autentificar usuarios.

server.policy

Parámetros de seguridad empleados por JBoss.

standardjaws.xml

JAWS es el motor de mapeo Objeto/Relacional empleado por JBoss en CMP (Container Managed Persistence) EJB's, este archivo contiene sus valores default.

standardjbosscmp-jdbc.xml

Contiene los valores para ser empleados en CMP (Container Managed Persistence) EJB's.

standardjboss.xml

Contiene los parámetros estándar de configuración para JBoss tales como: Tamaño de pools para EJB's, valores de cache, numero de pools para bases de datos, clases empleadas para control de transacciones, entre otros parámetros.

8

Capítulo II: Despliegue de Aplicaciones.

Introducción.

A continuación se explican los distintos procedimientos para desplegar aplicaciones JEE en el servidor JBoss.

Despliegue en caliente.

En el capítulo anterior, dentro de la lista de directorios vistos que componen la estructura de JBoss, pudimos observar el siguiente: server/default/deploy.

Mientras que otros servidores de aplicaciones requieren procesos que impliquen el reinicio del servidor o simplemente utilizar interfaces Web para tal caso, JBoss ofrece una técnica bastante mas sencilla para el despliegue de aplicaciones.

Suponiendo que la aplicación ya está construida y empaquetada en el archivo app.jar, basta con copiar este archivo al directorio antes mencionado, de la siguiente forma:

[root@jboss]$ cp <directorio aplicacion>/app.war server/default/deploy

Por lo que a continuación veremos un mensaje en la salida de Jboss como el siguiente:

deploy, ctxPath = /app

Al ver este mensaje, podemos entonces afirmar que la aplicación app.jar fue correctamente desplegada en el servidor. Cualquier otro mensaje nos dará la información necesaria para ver el por qué no se produjo el proceso de despliegue.

La comprobación de la aplicación depende del contexto en el cual se requiera ejecutar la aplicación, ya que puede ser una aplicación JSP, Servlet, EJB, etc.

Estructura del descriptor de despliegue.

Un descriptor de despliegue (en inglés Deployment Descriptor) (DD) es un componente de aplicaciones JEE que describe cómo se debe desplegar (o implantar) una aplicación web. Esto dirige una herramienta de despliegue (o publicación) para desplegar un módulo o aplicación con opciones de contenedor específicas y describe requisitos de configuración específicos que

9

puede resolver un desplegador.

En aplicaciones JEE, XML se usa para la sintaxis del fichero descriptor de despliegue. Debe ser llamado web.xml, y debe ser colocado en un subdirectorio llamado WEB-INF, directamente debajo de la raíz de la aplicación web.

La estructura de este archivo, en su forma mas mínima es la siguiente:

<?xml version="1.0"?> <web­app version="2.5" 

xmlns="http://java.sun.com/xml/ns/javaee" xmlns:xsi="http://www.w3.org/2001/XMLSchema­instance" xsi:schemaLocation="http://java.sun.com/xml/ns/javaee http://java.sun.com/xml/ns/javaee/web­app_2_5.xsd"> 

<description>Descripcion de la aplicacion</description> 

<servlet>        <servlet­name>Servlet</servlet­name> 

<servlet­class>servlet</servlet­class> </servlet> 

<servlet­mapping>        <servlet­name>Servlet</servlet­name> 

<url­pattern>/ruta</url­pattern> </servlet­mapping> 

</web­app> 

Como se puede apreciar, la estructura del archivo contiene información sobre la aplicación, sus clases y las rutas de acceso desde el servidor.

Claramente, esta configuración es mínima y tiene muchos mas parámetros que son precisos para levantar las aplicaciones correctamente.

A lo largo de este documento, se irán agregando nuevos parámetros de configuración a este archivo descriptor.

Estructura de un paquete de aplicación.

Una aplicación JEE, en su forma mas mínima, debe contener la siguiente estructura de directorio:

META­INF/manifest.mf

WEB­INF/classes/src/lib/web.xml

El contenido de los directorios es el siguiente:

10

El directorio META-INF, relacionado con archivos .jar contiene el archivo manifest.mf, el cual contiene la lista de contenidos del archivo, y son generados al momento de crear el archivo.

El directorio WEB-INF contiene todo lo necesario para ejecutar la aplicación, se divide en las siguientes secciones:

classes: Donde se almacenan todas las clases compiladas de la aplicación.lib: Donde se almacenan las librerias necesarias para ejecutar la aplicación.src: (optativo) Contiene el código fuente de la aplicación.

Empaquetado de la aplicación.

Una vez que la aplicación JEE está correctamente construida y cumple con el estándar descrito anteriormente, el empaquetado ser realiza con el siguiente comando.

[root@jboss]$ jar cvf app.war app

Y posteriormente, este archivo WAR se copia al directorio deploy visto anteriormente para desplegar la aplicación.

11

Capítulo III: Integración de JBoss con Eclipse.

Introducción.

Eclipse es un entorno de desarrollo integrado de código abierto multiplataforma para desarrollar lo que el proyecto llama "Aplicaciones de Cliente Enriquecido", opuesto a las aplicaciones "Cliente-liviano" basadas en navegadores. Esta plataforma, típicamente ha sido usada para desarrollar entornos de desarrollo integrados (del inglés IDE), como el IDE de Java llamado Java Development Toolkit (JDT) y el compilador (ECJ) que se entrega como parte de Eclipse (y que son usados también para desarrollar el mismo Eclipse). Sin embargo, también se puede usar para otros tipos de aplicaciones cliente, como BitTorrent Azureus.

Eclipse es también una comunidad de usuarios, extendiendo constantemente las áreas de aplicación cubiertas. Un ejemplo es el recientemente creado Eclipse Modeling Project, cubriendo casi todas las áreas de Model Driven Engineering.

Eclipse fue desarrollado originalmente por IBM como el sucesor de su familia de herramientas para VisualAge. Eclipse es ahora desarrollado por la Fundación Eclipse, una organización independiente sin ánimo de lucro que fomenta una comunidad de código abierto y un conjunto de productos complementarios, capacidades y servicios.

Obtener Eclipse.

Para obtener Eclipse, es preciso visitar la siguiente página web: http://www.eclipse.org/downloads/

En la lista de descargas, se puede apreciar lo siguiente:

12

La primera opción a descargar corresponde precisamente al IDE que se necesita para trabajar de forma integrada con JBoss.

Una vez descargado y descomprimido el archivo correspondiente a la plataforma deseada (Linux, Windows, MacOS X), se aprecia un contenido de directorio como el siguiente:

Para ejecutar la aplicación, basta con hacer doble clic sobre el icono eclipse delimitado en la imagen.

Una vez ejecutada la aplicación, se observa la siguiente pantalla de

13

inicio:

Los apartados se describen de la siguiente forma:

A la izquierda aparecerá la lista de proyectos creados y/o abiertos actualmente, con el árbol de contenidos respectivo.

Al centro se presentará tanto el código fuente de la aplicación como su ejecución.

Al costado derecho aparecerá información relativa a los objetos que se vayan seleccionado.

En el costado inferior aparecerá toda la información relativa con el entorno de ejecución, tanto como la lista de servidores, la consola de ejecución, las fuentes de datos, etc.

Configurar Eclipse con JBoss.

Para agregar un nuevo servidor JBoss, es preciso seleccionar la viñeta Servers en este apartado (como se aprecia en la figura) y luego hacer clic con el botón derecho del ratón en el fondo. La vista será como la siguiente imagen:

14

Seleccionamos entonces New y luego Server, donde se aprecia la siguiente ventana de diálogo:

En la lista se pueden apreciar todos los servidores JEE compatibles con esta versión de Eclipse. En esta ocasión, como se aprecia en la figura, se escoge el servidor JBoss versión 4.2

Al hacer clic sobre el botón Next, aparece el siguiente cuadro de diálogo:

15

En la primera parte seleccionamos el entorno JRE (Java Runtime Enviroment) con que deseamos ejecutar nuestro servidor, y luego damos la ruta donde está instalado nuestro JBoss.

Al hacer clic en el botón Next aparecerá el siguiente cuadro de diálogo:

16

Dado que podemos tener mas de un servidor JBoss en ejecución en nuestro sistema o entorno de desarrollo, podemos indicar a Eclipse que arranque nuestro servidor de aplicaciones con otros parámetros, tales como la IP de escucha, el puerto del frontend web, el puerto del JNDI (Java Naming and Directory Interface) etc.

En este caso, no modificamos ningún parámetro y simplemente damos clic en el botón Finish. Las pantallas siguientes son solamente para la inclusión de otros módulos y/o librerías para ejecutar aplicaciones que no incluiremos en este manual.

Finalizada la configuración, la vista Servers de Eclipse tendrá el siguiente aspecto:

17

Para arrancar JBoss, podemos hacer clic en el icono Play ubicado en la esquina superior derecha o simplemente crear una aplicación e indicar que vamos a ejecutarla con esta versión del servidor.

18

Capítulo IV : Monitorización.

Introducción.

La Java Management eXtensions (JMX) API es un estándar de Sun para la gestión y monitorización remota de recursos java como:

• Aplicaciones y dispositivos• Servidores y servicios• JVM

que nos permite entre otras cosas consultar o cambiar una determinada configuración, conocer estadísticas y comportamiento de una aplicación, conocer cambios de estado (y notificarlo, iniciar acciones, etc), crear nuestros manejadores de recursos y publicarlos en una API, interoperar con otras tecnologías...

JMX se integró pronto en la J2EE y más tarde en la JSE, concretamente desde la JDK 5. Su jerarquía de subpaquetes se encuentran bajo javax.management, y esta es su API pública. Asimismo existe una API privada bajo com.sun.jmx, a la que sólo debería tener acceso las propias librerías de la JDK, puesto que esta implementación puede evolucionar y ser cambiada en futuras versiones.

A partir de la JDK 5.0 se incluye Jconsole para monitorizar la JVM y aplicaciones que implementen JMX. Es un ejecutable con interfaz gráfica que se encuentra en la carpeta bin de la instalación de la distribucion de Sun JDK.

Arquitectura de JMX.

Arquitectura basada en 3 capas:

1. Capa de aplicación (o nivel de instrumentación), la capa de más bajo niveles donde residen los componentes (MBean) que facilitan la información necesaria para la gestión de una aplicación. Estos componentes son desarrollados según las necesidades de gestión específicas de cada parte de una aplicación.

2. Nivel de agente: facilita una interfaz para el manejo de los MBean del nivel de instrumentación.

3. Nivel de Adaptadores: uno o más conectores (o adaptadores de protocolo) que proporcionan acceso desde los sistemas de monitorización remotos.

19

Monitorización de JBoss

JBoss implementa JMX en su microkernel. El propio servidor dispone de un una consola JMX accesible por la URL http://localhost:8080/jmx-console que muestra los MBeans públicos accesibles por ella o programáticamente por código Java:

20

Algunas acciones útiles:

• Mostrar el árbol JNDI .• Forzar un volcado de memoria .• Mostrar el uso del pool de memoria .• Gestionar el escáner de despliegues .• Redesplegar una aplicación .• Acceder a la base de datos Hypersonic .• Detener JBoss • Conocer estado de los EJB desplegados e instanciados

Monitorización con JConsole

JConsole (www.servletsuite.com) usa el JMX de JBoss para monitorizar el servidor: estado, logs, despliegues, uploads y visor de los Mbeans:

Para poder trabajar con JConsole debemos seguir los siguientes pasos:

• Descargar jconsole.war desde http://www.servletsuite.com/jmx/jconsole.htm

• Copiar jconsole.war en la carpeta deploy del servidor utilizado, para su despliegue (habitualmente en server/default/deploy)

• Con JBoss en ejecución, acceder a http://localhost:8080/jconsole

21

Cuando accedamos a la pestaña JMX se nos presentará una casilla para introducir un patrón que determinará los MBeans que visualizaremos en la lista inferior. Los patrones son los habituales:

• Nombre totalmente cualificadopor ejemplo: boss.j2ee:service=EARDeployer

• Wildcard: *, ? por ejemplo: jboss.jm?:*, jboss:*, jboss.*:*, *:*

22

Monitorización con ManageEngine Applications Manager

ManageEngine Applications Manager es un potente monitor comercial con una versión libre (limitación: máximo 5 monitores) aplicable a servidores, BBDD, aplicaciones, websites, ERP, transacciones y mucho más. Ha sido diseñada con una interfaz muy completa y ofrece múltiples estadísticas, que pueden asociarse acciones al seguimiento de recursos, como alarmas y notificaciones por correo electrónico. Permite la monitorización de recursos remotos (los anteriores monitores se limitaban al servidor local) y la monitorización de MBeans de JMX, por supuesto.

Para instalar, debemos descargar la aplicación desde http://manageengine.adventnet.com/products/applications_manager/download.html y ejecutar el instalable.

23

Para continuar, hacemos clic en el botón next.

Una vez aceptados los términos de la licencia, hacemos clic en el botón next.

24

Luego de escoger la versión Free Edition que nos permitirá operar hasta 30 días (para luego transformarse en la versión libre) hacemos clic en el botón next.

25

En esta ventana, se nos pide escoger el idioma de la instalación. En el ejemplo se utilizará el inglés (English). Para continuar, debemos hacer clic en el botón next.

En esta ventana se nos pide escoger el puerto donde levantará la aplicación web. Por defecto se utiliza el 9090. Para continuar, clic en el botón next.

26

Para coleccionar las estadísticas, la aplicación nos pide elegir entre MySQL (el cual viene incluido en la aplicación) o Microsoft SQL Server. En el caso del ejercicio, escogemos MySQL. Continuamos la instalación haciendo clic en el botón next.

En esta ventana se nos pide escoger la ruta de la instalación. Continuamos la instalación haciendo clic en el botón next.

27

En esta última ventana, se nos presenta el resumen de la instalación. Hacemos clic en el botón next para continuar o en back si queremos hacer algún cambio antes de terminar.

Una vez finalizada la instalación, al dirigirnos a la ruta escogida para la instalación de la aplicación, nos encontraremos con los siguientes íconos.

Para arrancar, entonces debemos hacer clic en el ícono startApplicationsManager.sh y luego en startWebConsole.sh. El primero arrancará la aplicación. El segundo arrancará el entorno web.

Para acceder a la aplicación entonces, debemos abrir la siguiente URL en nuestro navegador: http://localhost:9090, lo cual se verá como la siguiente pantalla:

28

Como se indica en las instrucciones, el usuario por defecto es admin, y la contraseña por defecto es admin.

Como podemos ver, ManageEngine Applications Manager nos permite inclusive configurar alertas a través de correo electrónico.

Una vez configurado el nodo de monitorización, observamos la siguiente ventana:

29

Monitorización con Munin

A pesar de que las herramientas previamente descritas permiten monitorizar JBoss de manera óptima, en un gran porcentaje de los casos es preciso monitorizar en conjunto a otras variables, tales como la memoria, el espacio en disco, la carga del servidor, etc.

Para tal caso, a continuación se describirá como instalar la herramienta Munin en el servidor.

Munin opera sobre la base de recolector de información (munin-master) y de nodo (munin-node) como se aprecia en la siguiente figura:

Podríamos entonces eventualmente dejar un equipo o un servidor como recolector de información munin-master e instalar en cada nodo de un posible clúster JBoss solamente el munin-node. Claramente, en un mismo equipo o servidor pueden coexistir tanto munin-master como munin-node.

30

Instalación de munin-master.

Antes de instalar el munin-master en nuestro equipo o servidor, es preciso contar con un servidor web para poder visualizar los gráficos. Se explicarán entonces los comandos necesarios para instalar munin-master o el recolector en conjunto con el servidor web Apache o de forma unitaria si ya se cuenta con los paquetes instalados.

Instalación en Debian/Ubuntu

Si se utiliza Debian o Ubuntu como distribución Linux, es tan fácil como ejecutar el siguiente comando:

Sin Apache instalado:

# apt­get install apache munin

Con Apache instalado:

# apt­get install munin

Recordamos que el carácter almohadilla (#) por convención se refiere a que es preciso contar con privilegios de administrador (root) en el equipo y/o servidor.

Instalación en CentOS

La forma mas sencilla de instalar munin-master en un servidor es precisamente agregando un repositorio YUM que lo contenga. El repositorio mas popular y completo para tal caso corresponde a Dag Wieers YUM.

Una vez que el repositorio es instalado, solo debemos utilizar YUM para instalar el munin-master.

Para indicar a YUM que debe buscar además de lo cotidiano los paquetes a instalar en el repositorio Dag Wieers, debemos crear un archivo en la ubicación /etc/yum.repos.d/dag.repo con el siguiente contenido.

[dag]name=Dag RPM Repository for Red Hat Enterprise Linuxbaseurl=http://apt.sw.be/redhat/el$releasever/en/$basearch/daggpgcheck=1gpgkey=http://dag.wieers.com/rpm/packages/RPM­GPG­KEY.dag.txtenabled=1

31

Luego, basta con ejecutar el siguiente comando:

Sin Apache instalado:

# yum ­y install httpd munin

Con Apache instalado:

# yum ­y install munin

Configuración del munin-master.

El paso siguiente, luego de haber instalado correctamente la aplicación, es configurar el recolector donde debemos indicar la ruta donde debe generar las páginas web con las estadísticas recolectadas e indicarle en que rutas se encuentran los distintos nodos que debe monitorizar. Para ello, debemos editar el archivo /etc/munin/munin.conf donde debemos encontrar las siguientes línea:

# The next three variables specifies where the location of the RRD # databases, the HTML output, and the logs, severally.  They all # must be writable by the user running munin­cron. dbdir   /var/lib/munin htmldir /var/www/munin logdir  /var/log/munin rundir  /var/run/munin 

En el caso de Debian/Ubuntu, por defecto se instala el servidor Web Apache indicando que el DocumentRoot (o ruta de documentos) por defecto es /var/www, para el caso de CentOS, esta ruta corresponde a /var/www/html.

Por lo tanto, debemos dejar tal como está la configuración en el parámetro htmldir o cambiarlo por el valor correspondiente, dependiendo de la ruta del VirtualHost, la distribución de Linux, etc.

Para mayor información, es preciso referirse a la documentación oficial de Apache.

Para configurar la lista de nodos que estarán entregando la información necesaria para recolectar, debemos ubicar la siguiente línea en el archivo de configuración:

# a simple host tree [localhost]     address 127.0.0.1     use_node_name yes 

32

En esta vista, se configura el nombre del nodo que vamos a utilizar (localhost) y la dirección IP donde está eventualmente escuchando nuestro munin-node. El recolector se comunicará con el nodo y le pedirá que le entregue toda la información necesaria.

Suponiendo que contamos con 3 nodos en las direcciones IP 192.168.1.10, 192.168.1.11 y 192.168.1.12, una configuración podría ser como la siguiente:

[equipo1]     address 192.168.1.10    use_node_name yes 

[equipo2]     address 192.168.1.11    use_node_name yes [equipo3]     address 192.168.1.12    use_node_name yes 

Instalación de munin-node.

Debido a que el nodo levanta un servicio totalmente independiente, es preciso ejecutar uno de los siguientes comandos, dependiendo de la distribución que se utiliza:

Instalación en Debian/Ubuntu

# apt­get install munin­node

Instalación en CentOS

Una vez repetidos los pasos descritos en la instalación del repositorio Dag Wieers, debemos entonces ejecutar el siguiente comando:

# yum ­y install munin­node

Ahora debemos entonces configurar el nodo para indicar que información deseamos que publique a nuestro munin-master. Para tal caso, debemos dirigirnos al directorio /etc/munin/plugins, donde en su interior se puede apreciar lo siguiente:

cpu               iostat            open_inodes df                irqstats          processes 

33

df_inode          open_files        sendmail_mailqueue entropy           interrupts        sendmail_mailstats forks             load              sendmail_mailtraffic hddtemp_smartctl  memory            swap if_err_eth0       netstat           vmstat if_eth0           

Esta lista corresponde a todos los scripts que ejecuta el nodo para recolectar la información y entregarla de forma correcta al munin-master.

Al revisar con detalle la lista (por ejemplo, ejecutando ls -all), podemos ver información como la siguiente:

cpu ­> /usr/share/munin/plugins/cpu

Como se puede apreciar entonces, los archivos listados corresponden simplemente a enlaces duros a un script ubicado en la ruta /usr/share/munin/plugins. Por lo tanto, para habilitar o deshabilitar un script es tan sencillo como crear o eliminar el enlace duro según sea necesario.

En caso de necesitar parámetros adicionales para la ejecución de un script, debemos revisar los archivos contenidos en la ruta /etc/munin/plugin-conf.d, como por ejemplo, el archivo munin-node.

Dentro de este fichero, podemos apreciar lo siguiente:

[mysql*] #env.mysqlopts ­u someuser 

Para munin-node, esto quiere decir que todos los scripts que comiencen con mysql, deben ejecutarse utilizando el parámetro -u someuser. Al estar precedido de una almohadilla (#), simplemente es una línea comentada.

Arrancar el servicio munin-node

Para que nuestro recolector entonces pueda conectarse al nodo y comenzar a graficar la información, es preciso arrancar el servicio utilizando el siguiente comando:

# /etc/init.d/munin­node start

Una prueba de que la configuración es correcta, puede ser la siguiente:

# telnet localhost 4949Trying 127.0.0.1... Connected to localhost.localdomain (127.0.0.1). Escape character is '^]'. # munin node at jboss1.linuxcenter.frog.cl

34

fetch load    load.value 0.09 . 

Como se aprecia, el nodo informó de que el sistema actualmente tiene una carga de servidor de 0.09.

Informes

Para poder visualizar entonces los informes, una vez configurados todos los nodos y establecidos todos los enlaces duros a los scripts que deseamos que ejecute, debemos abrir una ventana del navegador hacia la URL del recolector.

Claramente, al principio debemos esperar entre 10 a 15 minutos a que se ejecute tranquilamente la recolección de información para poder apreciar gráficas del sistema.

Para poder levantar el Servidor Web Apache, debemos ejecutar uno de los siguientes comandos, dependiendo de la distribución que estamos utilizando:

Debian/Ubuntu

# /etc/init.d/apache2 start

CentOS

# /etc/init.d/httpd start

Suponiendo que nuestro recolector tiene la dirección IP 192.168.2.114, debemos entonces visitar la URL http://192.168.2.114/munin

35

Como se aprecia en el dibujo, munin está perfectamente configurado y está recolectando información en tres equipos: equipo1, equipo2 y localhost.

Para ver las gráficas, basta con visitar cualquiera de los enlaces, donde se puede apreciar la siguiente página:

36

Escribir plugins para munin utilizando JMX

Como el objetivo es monitorizar JBoss en conjunto con las otras variables del sistema, utilizando plugins personalizados para nuestro caso, debemos saber escribir éstos para munin, donde recolectaremos la información necesaria.

JBoss, como servidor de aplicaciones que cumple con el estándar JEE, está provisto de la API JMX (visto anteriormente), donde además nos ofrece de una aplicación llamada twiddle.sh ubicada dentro del directorio bin de su instalación (junto con run.sh).

Supongamos que necesitamos monitorizar la memoria libre de JBoss utilizando JMX. El atributo que nos devuelve esta información lo podemos obtener desde la siguiente ruta (utilizando jmx-console para tal caso)

Dentro de los atributos del dominio jboss.system del tipo ServerInfo encontramos lo siguiente:

37

Como se aprecia en el dibujo, el atributo FreeMemory nos devuelve, expresado en bytes, la cantidad de memoria libre de este servidor JBoss.

Para obtener este parámetro entonces, debemos ejecutar el siguiente comando utilizando twiddle:

# cd /opt/jboss/bin# ./twiddle.sh ­s localhost get jboss.system:type=ServerInfo FreeMemory

La salida de consola de este comando es el siguiente:

FreeMemory=100091928

Por lo tanto, el valor que deseamos obtener y que deseamos que munin-node informe a munin-master es 100091928.

Necesitamos entonces, de algún modo, poder utilizar este valor utilizando algún lenguaje de programación para que este plugin se pueda ejecutar sin problemas. El lenguaje que utilizaremos en este ejemplo corresponde al lenguaje bash.

Para obtener el valor, claramente vemos que está separado por el símbolo “=”, entonces, debemos utilizar un comando que nos permita separar esta cadena en dos partes (FreeMemory y 100091928) y utilizar lo correspondiente.

Un comando útil es cut, donde podemos indicar por parámetro como queremos cortar la cadena y que posición queremos utilizar.

38

Para el caso del ejemplo, el comando debería ser el siguiente:

# ./twiddle.sh ­s localhost get jboss.system:type=ServerInfo FreeMemory | cut ­f2 ­d'=' 

Donde el comando cut captura la salida dada por el comando twiddle, la separa por el carácter '=' (-d) y nos devuelve la segunda posición (-f2). La salida es la siguiente:

100091928

Formato de un plugin munin.

Para escribir un plugin munin, debemos implementar dos cosas:

a) La configuración del gráfico.b) El resultado de la ejecución.

La configuración del gráfico es utilizada por munin-master para dibujar el mismo, donde debemos indicar el título, el grupo al que pertenece, la unidad de medida, etc.

El resultado de la ejecución debería ser entonces el valor visto anteriormente (100091928)

Al hacer nuevamente telnet al puerto 4949 del munin-node, podemos obtener el formato de configuración de un gráfico cualquiera de la siguiente forma:

# telnet localhost 4949 Trying 127.0.0.1... Connected to localhost.localdomain (127.0.0.1). Escape character is '^]'. # munin node at jboss1.linuxcenter.neno2.frog.cl config load graph_title Load average graph_args ­­base 1000 ­l 0 graph_vlabel load graph_scale no graph_category system load.label load load.warning 10 load.critical 120 graph_info   The   load   average   of   the   machine   describes   how   many processes are in the run­queue (scheduled to run "immediately"). load.info Average load for the five minutes. .

Como se aprecia, la configuración nos indica varios parámetros como por ejemplo:

39

graph_title : Título del gráfico.graph_vlabel : Etiqueta verticalgraph_category : Categoría del gráfico.var.label  : Etiquetavar.warning  : Valor de advertenciavar.critical : Valor crítico

Esta información el munin-node la obtiene al ejecutar los scripts ubicados dentro de la carpeta /etc/munin/plugins:

# cd /etc/munin/plugins# ./load config graph_title Load average graph_args ­­base 1000 ­l 0 graph_vlabel load graph_scale no graph_category system load.label load load.warning 10 load.critical 120 graph_info   The   load   average   of   the   machine   describes   how   many processes are in the run­queue (scheduled to run "immediately"). load.info Average load for the five minutes

Y el valor de la medición se obtiene ejecutando el siguiente comando:

# ./load load.value 0.59 

Comparando ambas situaciones entonces, podemos apreciar que se define una variable llamada load donde tiene una etiqueta (load.label) y un valor (load.value)

Por lo tanto entonces, se debería crear un script que al ejecutarse ofrezca, al menos, la siguiente información:

# ./jboss­memory config graph_title JBoss Free Memory graph_vlabel Free Memory graph_category JBoss freemem.label Free Memory graph_info JBoss Free Memory freemem.info Free Memory. 

# ./jboss­memory freemem.value 103326568 

40

El siguiente script, escrito en lenguaje bash, realiza lo anteriormente descrito:

#!/bin/sh 

if [ "$1" = "config" ]; then 

        echo 'graph_title JBoss Free Memory'         echo 'graph_vlabel Free Memory'         echo 'graph_scale no'         echo 'graph_category JBoss'         echo 'freemem.label Free Memory'         echo 'totmem.label Total Memory'         echo 'graph_info JBoss Free Memory'         echo 'freemem.info Free Memory.'         exit 0 fi 

cd /opt/jboss/binecho ­n "freemem.value " ./twiddle.sh ­s localhost get jboss.system:type=ServerInfo FreeMemory | cut ­f2 ­d'='

Para instalar el plugin, basta entonces con copiarlo en la ruta /usr/share/munin/plugins bajo el nombre jboss_memory, dar privilegios de ejecución y luego crear el enlace duro en el directorio /etc/munin/plugins.

# cp jboss_memory /usr/share/munin/plugins# chmod +x /usr/share/munin/plugins/jboss_memory# ln ­sn /usr/share/munin/plugins/jboss_memory /etc/munin/plugins/jboss_memory

Y finalmente, incluirlo en el archivo munin-node dentro de /etc/munin/plugin-conf.d indicando que todos los plugins que comiencen con “jboss” deben ser ejecutados con un parámetro, como por ejemplo:

[jboss*] user root 

Luego de unos minutos, veremos entonces que la gráfica de este recolector se parecerá a la siguiente:

41

El período de ejecución de nuestro munin-master viene dado por la siguiente configuración en el archivo munin dentro del directorio /etc/cron.d.

*/5 * * * *     munin test ­x /usr/bin/munin­cron && /usr/bin/munin­cron

Donde cada 5 minutos, con privilegios de usuario munin intentará ejecutar el script /usr/bin/munin-cron, el cual en su interior contiene lo siguiente:

#!/bin/sh [ ­x /usr/share/munin/munin­update ] && /usr/share/munin/munin­update $@; [ ­x /usr/share/munin/munin­limits ] && /usr/share/munin/munin­limits $@; [ ­x /usr/share/munin/munin­graph  ] && nice /usr/share/munin/munin­graph $@;[ ­x /usr/share/munin/munin­html   ] && nice /usr/share/munin/munin­html $@; 

Que como se puede apreciar, son una serie de scripts que tienen por objetivo actualizar la información, calcular los límites, crear los gráficos y generar el código HTML necesario para visualizar las estadísticas.

Conclusión.

Luego de toda la explicación para instalar munin-master, munin-node, configurar y programar plugins, vemos que el gran responsable de una correcta recolección de estadísticas, recae en el administrador que debe saber ubicar el atributo JMX necesario para la situación.

42

Monitorización con Nagios

Introducción.

Para extender la monitorización de nuestro JBoss, es preciso no contar solamente con herramientas de recolección de información, si no que además que “se nos avise” mediante un correo electrónico cuando una situación es “anormal”.

Supongamos que deseamos que se active una alarma de advertencia cuando el porcentaje de memoria libre corresponda al 20% de la memoria total. Y supongamos además que deseamos una alarma crítica cuando este porcentaje llegue al 10%. Esto es posible instalando Nagios como herramienta de monitorización y escribiendo plugins para el mismo utilizando JMX.

A continuación se procederá a explicar la instalación de Nagios desde el código fuente:

Requisitos.

Antes de comenzar con la instalación de Nagios, para permitir la vista de las estadísticas y ver el estado actual de los servicios, es preciso contar con el siguiente software instalado:

• Servidor Web Apache• Lenguaje de programación PHP• Compilador GCC • Librería GD

Podemos instalar estos paquetes con los siguientes comandos:

Debian/Ubuntu

# apt­get install apache2 php gcc glibc glibc­common gd gd­devel

CentOS

# yum install httpd php gcc glibc glibc­common gd gd­devel

Instalación.

Creamos un usuario llamado nagios y le damos una contraseña:

43

# /usr/sbin/useradd ­m nagios# passwd nagios

Creamos un nuevo grupo llamado nagcmd para permitir la ejecución segura de algunos comandos desde la interfaz web. Además, indicamos que los usuarios apache o www-data (para el caso de Debian/Ubuntu el usuario por defecto de apache es www-data y para CentOS el usuario es apache) y nagios pertenecen a este grupo.

Ambas distribuciones

# /usr/sbin/groupadd nagcmd# /usr/sbin/usermod ­a ­G nagcmd nagios

Debian/Ubuntu

# /usr/sbin/usermod ­a ­G nagcmd www­data

CentOS

# /usr/sbin/usermod ­a ­G nagcmd apache

Creamos un directorio para descargar el código fuente necesario:

# mkdir ~/downloads# cd ~/downloads

Descargamos el código fuente de Nagios y de Nagios Plugins desde http://www.nagios.org/download/ donde debemos descargar las últimas versiones para cada paquete:

# wget http://osdn.dl.sourceforge.net/sourceforge/nagios/nagios­3.2.0.tar.gz# wget http://osdn.dl.sourceforge.net/sourceforge/nagiosplug/nagios­plugins­1.4.11.tar.gz

Para compilar e instalar nagios, debemos entonces descomprimir el código fuente desde el paquete descargado:

# cd ~/downloads# tar xzf nagios­3.2.0.tar.gz# cd nagios­3.2.0

Ejecutamos el script configure dándole el nombre del grupo que acabamos de crear para su ejecución:

# ./configure ­­with­command­group=nagcmd

Compilamos el código fuente:

# make all

44

Instalamos los binarios, los scripts de inicio, los archivos de configuración por defecto y establecemos los privilegios para la ejeución:

# make install# make install­init# make install­config# make install­commandmode

Aún no debemos ejecutar Nagios, antes es preciso realizar algunos ajustes.

Los archivos de configuración de ejemplo han sido instalados en el directorio /usr/local/nagios/etc. Estos ejemplos nos servirán para comenzar a trabajar con Nagios. Necesitamos realizar solo un cambio a estos archivos antes de proceder.

Editamos el archivo /usr/local/nagios/etc/objects/contacts.cfg cambiando la línea donde aparece el correo electrónico de contacto. Debemos entonces dejar el nuestro o el que deseamos se utilice para tal práctica.

Instalamos ahora el archivo de configuración necesario para que apache pueda ejecutar el entorno web de nagios con el siguiente comando:

# make install­webconf

Creamos una cuenta llamada nagiosadmin para poder identificarse en la interfaz web. El proceso nos pedirá además establecer una contraseña:

# htpasswd ­c /usr/local/nagios/etc/htpasswd.users nagiosadmin

Reiniciamos Apache para que los cambios surtan efecto:

Debian/Ubuntu

# /etc/init.d/apache2 restart

CentOS

# /etc/init.d/httpd restart

A continuación procederemos a instalar los plugins de nagios. Para ello, debemos extraer el paquete con el código fuente:

# cd ~/downloads# tar xzf nagios­plugins­1.4.11.tar.gz# cd nagios­plugins­1.4.11

Compilamos e instalamos los plugins:

45

# ./configure ­­with­nagios­user=nagios ­­with­nagios­group=nagios# make# make install

Antes de arrancar nagios, vamos a marcar el script de arranque para ejecución automática cuando el sistema se inicie:

# chkconfig ­­add nagios# chkconfig nagios on

Verificamos el archivo de configuración antes de partir (se recomienda ejecutar esto cada vez que se haga un cambio en dicho archivo)

# /usr/local/nagios/bin/nagios ­v /usr/local/nagios/etc/nagios.cfg

Si no hay errores, entonces arranquemos nagios:

# service nagios start

Para finalizar, entonces debemos entrar a la interfaz web de nagios visitando la siguiente dirección: http://localhost/nagios/

Hacemos clic en el enlace Service Detail para ver que es lo que está siendo monitorizado en nuestro sistema.

Escribir plugins para nagios utilizando JMX

Como el objetivo es monitorizar JBoss en conjunto con las otras variables del sistema, utilizando plugins personalizados para nuestro caso, debemos saber escribir éstos para nagios, donde recolectaremos la información necesaria.

Antes de continuar, es preciso contar con un lenguaje de programación idóneo para tal situación. El lenguaje escogido para tal caso es el lenguaje Perl, ya que cuenta con librerías de fácil uso para la programación.

Perl viene por defecto instalado en la mayoría de las distribuciones de linux, por lo que su instalación no será tratada en este manual.

Para instalar la librería necesaria, es preciso ejecutar el siguiente comando:

# cpan ­i Nagios::Plugin

Por ser la primera vez que estamos ejecutando cpan (Comprehensive Perl Archive Network) nos pedirá alguna información adicional, sobre todo lo relacionado con nuestra ubicación actual y el espejo mas cercano, para

46

realizar las descargas de paquetes de manera rápida.

La creación de un plugin nagios necesita, generalmente, de dos argumentos que deben ser pasados al mismo, el valor warning y critical que corresponden al valor de advertencia y de criticidad del evento respectivamente.

Supongamos que la alarma dice lo siguiente:

Normal: de 0 a 80Advertencia: de 80 a 90Critico: de 90 a 100

Entonces nuestro script debe estar programado de tal forma que el valor a medir sea definido en porcentaje y ser capaz de recibir estos dos argumentos. Esto es debido a que nagios para poder reconocer este script como un plugin, debe estar incluido en sus archivos de configuración.

Revisemos entonces el archivo commands.cfg ubicado en /usr/local/nagios/etc/objects, en su interior podemos ver como se configura un comando, como por ejemplo, aquel que chequea la carga del servidor.

Encontramos entonces una línea como la siguiente:

# 'check_local_load' command definition define command{         command_name    check_local_load         command_line    $USER1$/check_load ­w $ARG1$ ­c $ARG2$         } 

Como podemos observar, al referirnos al comando check_local_load se ejecuta un script llamdo check_load con dos parámetros: -w para warning y -c para critical.

Si ejecutamos el comando en forma local, desde la ubicación /usr/local/nagios/libexec (ruta donde se almacenan los plugins) vemos lo siguiente:

# ./check_load ­w 2 ­c 3 OK ­ load average: 0.05, 0.18, 0.13

La salida del script nos indica que todo está OK, puesto que el valor de carga está entre 0 y 2. De haber estado entre 2 y 3 hubiese marcado WARNING y sobre 3 hubiese marcado CRITICAL

Nuestro objetivo entonces es crear un script que nos permita indicar estos parámetros y tener una salida similar.

El siguiente código cumple con el objetivo:

47

#!/usr/bin/perl 

use strict; use warnings; use Nagios::Plugin ; use vars qw($VERSION $PROGNAME $verbose $warn $critical); $VERSION = '1.0'; use File::Basename; $PROGNAME = basename($0); 

my $p = Nagios::Plugin­>new(     usage => "Usage: %s     [ ­c|­­critical=<critical threshold> ]     [ ­w|­­warning=<warning threshold> ]",     version => $VERSION,     blurb => 'test' ); 

$p­>add_arg( spec => 'warning|w=s', 

        help => 'warning value' ); 

$p­>add_arg( spec => 'critical|c=s', 

        help => 'critical value', ); $p­>getopts; unless (defined $p­>opts­>warning || defined $p­>opts­>critical ) {         $p­>nagios_die("not enough arguments"); } 

##### 

my $return = `/opt/jboss/bin/twiddle.sh ­s localhost get jboss.system:type=ServerInfo FreeMemory`; my @arr = split("=", $return); my $free = $arr[1]; 

$return = `/opt/jboss/bin/twiddle.sh ­s localhost get jboss.system:type=ServerInfo TotalMemory`; @arr = split("=", $return); my $total = $arr[1]; 

my $result = 0; if (int $total > 0) {         $result = int (($free / $total) * 100); } 

##### 

$p­>nagios_exit(         return_code => $p­>check_threshold($result),         message => "Free memory $result%" ); 

Como podemos observar, el único código que debemos modificar es aquel que se encuentra delimitado por #####, ya que es ahí donde utilizando twiddle y JMX podemos saber el valor total de memoria, la memoria disponible y luego se calcula el porcentaje.

Para agregar este plugin a los comandos reconocidos por nagios, debemos editar el archivo indicado anteriormente y agregar lo siguiente:

#JBossdefine command{ 

command_name    check_jboss_memory command_line    $USER1$/check_jboss_memory ­w $ARG1$ ­c $ARG2$ 

} 

48

Y para poder chequear este valor contra un servidor, debemos editar el archivo localhost.cfg dentro de /usr/local/nagios/etc/objects agregando las siguientes líneas:

#JBoss define service{         use                             local­service        host_name                       localhost         service_description             JBoss Memory         check_command                   check_jboss_memory!80!90 } 

Donde claramente vemos que el primer argumento corresponde al valor warning (80) y el segundo argumento corresponde al valor critical (90).

49

Capítulo V: JAAS

A continuación se describe la forma de asegurar el acceso a una aplicación web en JBoss, se describe la forma más simple, con la obtención de usuarios desde un archivo de texto, pero sirve como base para autenticar contra bases de datos o servidores LDAP.

Configuración de la seguridad estándar en la aplicación web.

Se debe modificar el descriptor XML de la aplicación web (el archivo es WEB-INF/web.xml dentro del war) para agregar los tag security-constraints y login-config:

<web­app><security­constraint>

<web­resource­collection><web­resource­name>Application Name</web­resource­name><url­pattern>/*</url­pattern><http­method>GET</http­method><http­method>POST</http­method>

</web­resource­collection><auth­constraint>

<role­name>Admin</role­name></auth­constraint>

</security­constraint>

<login­config><auth­method>BASIC</auth­method><realm­name>Application Name</realm­name>

</login­config>

<security­role><role­name>Admin</role­name>

</security­role></web­app>

Configurar un módulo de login JAAS

Se debe configurar el módulo contra el cual se realizará la validación, estos módulos se declaran en /server/<tipo>/conf/login-config.xml. El módulo más simple de autenticación es basado en archivos (UserRolesLoginModule).

Este módulo se declara como un nuevo application-policy en este archivo:

<application­policy name="fileLoginModule"><authentication>

<login­module code="org.jboss.security.auth.spi.UsersRolesLoginModule" flag="required"/>

</authentication></application­policy>

50

Requiere dos archivos de propiedades, llamados users.properties y roles.properties que deben ubicarse en el directorio WEB-INF/classes del WAR.

El formato del archivo users.properties es el de un archivo de propiedades donde la clave es el nombre de usuario y el valor la clave de acceso:

admin=adminpwd

En el archivo roles.properties la clave es el nombre del usuario y el valor la lista de roles de ese usuario, separados con ","

admin=Admin

Configuración de la seguridad específica de JBoss en la aplicación web.

Se debe agregar al WAR un descriptor de aplicación web para JBoss, este descriptor es un archivo META-INF/jboss-web.xml dentro del war, y contiene configuraciones específicas de JBoss, por ejemplo el nombre del login module a utilizar para la validación de usuarios.

Ejemplo de WEB-INF/jboss-web.xml:

<jboss­web>...<security­domain>java:/jaas/fileLoginModule</security­domain>...

</jboss­web>

Notar que el nombre después de java:/jaas/ debe coincidir con el nombre declarado en el application-policy, en el archivo login-config.xml

Creación de tablas y carga de datos en SQL.

Si la autenticación la vamos a realizar contra base de datos, lo primero que necesitamos es crear las tablas en un motor de bases de datos, como por ejemplo MySQL.

Ni el nombre de las tablas es fijo, ni el nombre de los campos de cada tabla, con lo que si ya tenemos un modelo de datos que responde a esta estructura no será necesario migrarlo. Veremos que, tanto la consulta de usuario, como la consulta de perfil se realizan a través de una sentencia sql parametrizable.

51

El siguiente script crea dos tablas:

• role: con una clave única y un nombre. El campo nombre será importante a la hora de definir la autorización.

• user: con una clave única, un login, una contraseña y una clave foránea que vincula un usuario a un rol.

DROP TABLE IF EXISTS `user`;  DROP TABLE IF EXISTS `role`;  

CREATE TABLE `role` (  `id` int(10) unsigned NOT NULL,  `name` varchar(64) collate utf8_spanish_ci NOT NULL,  PRIMARY KEY (`id`)  

) ENGINE=InnoDB DEFAULT CHARSET=utf8 COLLATE=utf8_spanish_ci;  

CREATE TABLE `user` (  `id` int(10) unsigned NOT NULL auto_increment,  `login` varchar(128) collate utf8_spanish_ci NOT NULL,  `password` varchar(128) collate utf8_spanish_ci NOT NULL,  `roleId` int(10) unsigned NOT NULL,  PRIMARY KEY (`id`),  KEY `ndx_user_roleId` (`roleId`),  CONSTRAINT `fk_user_roleId` 

FOREIGN KEY (`roleId`) REFERENCES `role`  (`id`)  ) ENGINE=InnoDB DEFAULT CHARSET=utf8 COLLATE=utf8_spanish_ci;  

El siguiente script inserta dos usuarios y dos roles:

• admin, con contraseña admin, asociado al rol "ADMINISTRATOR"• user, con contraseña password, asociado al rol "USER"

INSERT INTO `role` (`id`,`name`) VALUES  (1,'ADMINISTRADOR'),  (2,'USER');  

INSERT INTO `user` (`id`,`login`,`password`,`roleId`) VALUES  (1,'admin','ISMvKXpXpadDiUoOSoAfww==',1),  (2,'user','X03MO1qnZdYdgyfeuILPmQ==',2);  

Las contraseñas están encriptadas usando el algoritmo MD5 en Base64.

52

Definición del datasource y configuración de la política de seguridad en JBoss.

La definición de una fuente de datos en JBoss se realiza añadiendo un fichero con extensión -ds.xml en el directorio /server/<tipo>/deploy, con el siguiente contenido:

<?xml version="1.0" encoding="UTF­8"?><datasources>

<local­tx­datasource><jndi­name>simpleDS</jndi­name><connection­url>jdbc:mysql://localhost:3306/test</connection­url><driver­class>com.mysql.jdbc.Driver</driver­class><user­name>test</user­name><password>test</password></local­tx­datasource>

</datasources>

Tenemos que configurar:

• jndi_name: con un id único para nuestro datasource, que usaremos para invocarlo desde nuestra política de seguridad.

• connection-url: con la dirección y el nombre de nuestra base de datos MySQL

• user-name: con el login de un usuario para acceder a la base de datos. Claro está que no se refiere a uno de los usuarios de las tablas antes creadas, sino a un usuario de MySQL con permisos de lectura para acceder a la base de datos.

• password: con la contraseña de acceso del usuario anterior.

En nuestro caso tenemos un fichero /server/<tipo>/deploy/test-ds.xml para el acceso a la base de datos MySQL de test, con un usuario de MySQL test con contraseña test.

JBoss no viene con el driver para MySQL preinstalado, con lo que, si aún no lo tenemos, deberemos obtenerlo y copiar el jar, mysql-connector-java.jar, en /server/<tipo>/lib.

En el fichero /server/<tipo>/conf/login-config.xml debemos introducir la siguiente política de seguridad:

53

<!­­#simpleWeb_config ­­><application­policy

name="simpleWebAuthenticationPolicy"><authentication><login­module

code="org.jboss.security.auth.spi.DatabaseServerLoginModule"flag="required">

<module­option name="dsJndiName">java:/simpleDS

</module­option><module­option name="principalsQuery">

SELECT password FROM user WHERE login=?</module­option><module­option name="rolesQuery">

SELECT role.name, 'Roles'FROM user , role WHERE user.roleId=role.id ANDlogin=?

</module­option><module­option name="hashAlgorithm">MD5</module­option><module­option name="hashEncoding">base64</module­option></login­module>

</authentication></application­policy>

Tenemos que configurar:

• <application-policy name="simpleWebAuthenticationPolicy">: con un id único que identifica nuestra política de seguridad, que usaremos desde la aplicación web para enlazarla.

• <module-option name="dsJndiName">java:simpleDS<module-option>: con el nombre del datasource que hemos definido en el punto anterior.

• <module-option name="principalsQuery"></module-option>: con la sentencia SQL para la obtención de la contraseña del usuario que recibe como parámetro. Como comentaba, si vuestro modelo de datos no se corresponde con el de este ejemplo, aquí asignaríamos la sentencia correspondiente.

• <module-option name="rolesQuery"></module-option>: con la sentencia SQL para la obtención del nombre del perfil asociado al usuario, con las mismas consideraciones que en el punto anterior.

• <module-option name="hashAlgorithm"></module-option>: indica el nombre de algoritmo que hemos usado para guardar nuestras contraseñas en la tabla de usuarios.

• <module-option name="hashEncoding"></module-option>: indica el tipo de encoding que usará el algoritmo para comprobar la contraseña.

En este punto hemos configurado el módulo JAAS de JBoss para que acceda a nuestra base de datos a través de un datasource, el mismo que debería usar nuestra aplicación web.

Cambiar de base de datos, para pasar a un entorno de producción, por ejemplo, es sencillo, basta con modificar el vínculo (el nombre del datasource) entre la política de seguridad y el datasource, o lo que es más común, al tener varios datasources (uno por entorno), tendríamos varias políticas de seguridad (una por cada uno de ellos).

54

Capítulo VI : Clustering.

Configuración de JGroups.

Para aproximarnos a un entorno real hay que añadir otros parámetros en el comando de arrancada. Además en este post se utiliza la configuración all para preparar un entorno clusterizable.

Para ver los posibles valores de arranca del servidor de aplicaciones podemos ejecutar los siguiente:

sh run.sh –help

Que devuelve las posibles opciones de arranque:

­h, –help Show this help message­V, –version Show version information­D<name>[=<value>] Set a system property­d, –bootdir=<dir>     Set the boot patch directory; Must be absolute or url­p, –patchdir=<dir>     Set the patch directory; Must be absolute or url­n, –netboot=<url>     Boot from net with the given url as base­c, –configuration=<name> Set the server configuration name­B, –bootlib=<filename> Add an extra library to the front bootclasspath­L, –library=<filename> Add an extra library to the loaders classpath­C, –classpath=<url> Add an extra url to the loaders classpath­P, –properties=<url> Load system properties from the given url­b, –host=<host or ip> Bind address for all JBoss services­g, –partition=<name> HA Partition name (default=DefaultDomain)­u, –udp=<ip> UDP multicast address­l, –log=<log4j|jdk> Specify the logger plugin type

Como el propósito del ejemplo es montar un cluster empezamos utilizando la configuración all (que permite arrancar el servidor de aplicaciones en modo cluster, arrancar los web services, HA-JNDI, y otros).

Para arrancar el servidor de aplicaciones con las funcionalidades de cluster:

sh run.sh ­c all ­b <host or ip>, –host=<host or ip>

Este parámetro es importante tenerlo en cuenta pues cambia dos propiedades del sistema jboss.bind.address y bind.address.JGroups -estos parámetros sobreescriben los por defecto en la configuración xml del propio servidor-

jboss.bind.address: indica la dirección donde los servicios Tomcat, jrmp/pooled invokers services,…etc escucharán.

bind.address.JGroups: utilizada para indicar a JGroups con que IP se hace el bind del cluster.

Se puede fijar a 0.0.0.0 como dirección IP para bindar a todas las

55

direcciones.

Para nuestro ejemplo utilizamos la ip 192.168.0.1 para levantar los servicios:

sh run.sh ­c all ­b 192.168.0.1

Finalmente podemos probar en el navegador si el arranque ha sido correcto con http://192.168.0.1:8080

Para parar el servidor de aplicaciones hay que indicar en que dirección IP está arrancado con el parametro -s y utilizar -S para indicar el shutdown:

sh shutdown.sh ­s 192.168.0.1 ­S

Ejecución del cluster.

Arrancar JBoss en ambiente cluster es bastante sencillo, ya que fue construido pensando en ambientes distribuidos que requieren de esta característica.

Por defecto, JBoss está configurado para arrancar en modo standalone o nodo único.

Para arrancar el servicio a modo cluster, debemos seguir los siguientes pasos.

Vamos a llamar a las máquinas node1 y node2

Para arrancar el servicio escuchando sobre una IP en particular, debemos arrancar JBoss con los siguientes parámetros:

sh run.sh ­c all ­b 192.168.0.1

Suponemos que el node1 tiene IP 192.168.0.1 y que el node2 tiene la IP 192.168.0.2. Con lo que el arranque del nodo2 será

sh run.sh ­c all ­b 192.168.0.2

Si ejecutamos los comandos anteriores en las máquinas correspondientes aún no tenemos el cluster en funcionamiento. Para habilitarlo seguimos los siguientes pasos para la instalación:

• Debemos asegurarnos que las dos máquinas se ven entre si (indispensable para la comunicación del cluster)

• JBoss utiliza JGroups para la comunicación para la comunicación entre las máquinas y se puede realizar a través de UDP o TCP. El modo de

56

comunicación se puede modificar en server/all/deploy/cluster-service.xml, y debemos especificar una grupo para evitar acoplamiento.

• Para que nuestro cluster no se acople con otros miembros de la red (en el caso de que existan) debemos dar un nombre

Finalmente los comandos de arranque para los nodos del cluster son:

sh run.sh ­c all ­b 192.168.0.1 ­Djboss.partition.name=TestCluster ­Djboss.partition.udpGroup=230.10.0.1

sh run.sh ­c all ­b 192.168.0.2 ­Djboss.partition.name=TestCluster ­Djboss.partition.udpGroup=230.10.0.1

Donde -Djboss.partition.name fija el nombre del cluster y -Djboss.partition.udpGroup fija el grupo UDP en el caso de escoger el modo de comunicación de red UDP.

Si se escoje el modo TCP este segundo parámetro de configuración no es necesario. Se utiliza el protocolo UDP por su mejor rendimiento.

Para comprobar que los dos nodos están arrancados:

http://192.168.0.1:8080

http://192.168.0.2:8080

Para parar los servidores de aplicaciones:

sh shutdown.sh ­s 192.168.0.1 ­S 

sh shutdown.sh ­s 192.168.0.1 ­S

Apache mod_jk

mod_jk es un conector que permite JBoss interactuar con servidores web como Apache e incluso IIS usando el protocolo AJP.

La principal funcionalidad de este módulo es permitir a servidores de aplicaciones enlazarse con un servidor web. Este servidor web, típicamente el servidor HTTP Apache, introduce una mayor gestión en las conexiones de los clientes y mayor la seguridad en las transacciones del sistema. Así mismo se puede enlazar varias instancias al servidor web permitiendo así una mayor tolerancia a errores y aligerar la carga en los servidores Java.

Para configurar entonces, debemos descargar el archivo mod_jk.so desde http://tomcat.apache.org/download-connectors.cgi

57

Debemos entonces copiar el archivo a la ruta donde se almacenan los módulos de apache, generalmente está en /usr/lib/apache2/modules para Debian/Ubuntu y en /usr/lib/httpd/modules para CentOS.

Entonces, para que se ejecute, dentro del directorio conf.d (dentro del directorio de apache) debemos crear los siguientes archivos:

jk.confLoadModule jk_module modules/mod_jk.so 

JkWorkersFile "conf.d/workers.properties" JkLogFile "logs/mod_jk.log" JkLogLevel info JkLogStampFormat "[%a %b %d %H:%S %Y] " 

<Location /jkstatus/> JkMount status Order deny,allow Allow from all </Location> 

JkMount /jmx­console    loadbalancer JkMount /jmx­console/*  loadbalancer 

workers.propertiesps=/

worker.list=loadbalancer,status

worker.nodo1.port=8009 worker.nodo1.host=192.168.1.2worker.nodo1.type=ajp13 worker.nodo1.lbfactor=1

worker.nodo2.port=8009 worker.nodo2.host=192.168.1.3worker.nodo2.type=ajp13 worker.nodo2.lbfactor=1

worker.loadbalancer.type=lb worker.loadbalancer.balance_workers=nodo1,nodo2

worker.status.type=status

El primer archivo (jk.conf) le indica a apache que debe cargar el módulo mod_jk.so, utilizar el archivo workers.properties como adjunto y que debe crear una ruta a jmx-console, que será la aplicación que vamos a chequear.

El segundo archivo (workers.properties) le indica al módulo donde están los distintos nodos, sus direcciones IP y el factor de balanceo de carga que

58

tendrán.

Una vez recargado apache, basta con acceder a la dirección indicada para comprobar que el cluster está funcionando y balanceando la carga.

El estado del cluster se puede ver accediendo a la siguiente dirección (suponiendo que apache está corriendo en 192.168.1.1): http://192.168.1.1/jkstatus

Un worker es una instancia que está esperando para ejecutar servlets por cuenta de algún servidor web. Por ejemplo, podemos tener un servidor web, como las solicitudes de reenvío servlet de Apache a un proceso JBoss (el trabajador) corriendo detrás de él.

El escenario descrito anteriormente es muy simple, de hecho, uno puede configurar varios workers para servir servlets por cuenta de un servidor web seguro. Las razones de esta configuración pueden ser:

• Queremos que diferentes contextos para ser servido por los diferentes workers para proporcionar un entorno de desarrollo donde todos los desarrolladores compartir el mismo servidor web propio, sino un worker propio.

• Queremos que diferentes hosts virtuales servidos por diferentes procesos JBoss para proporcionar una separación clara entre los sitios pertenecientes a diferentes empresas.

• Queremos proporcionar equilibrio de carga, lo que significa ejecutar múltiples workers de JBoss cada uno en una máquina de su propia y distribuir las solicitudes entre ellos

Las razones son probablemente más por tener varios workers, pero se supone que esta lista es suficiente.

Propiedades Globales.

El formato general es

<nombre> = <valor>

Los puntos son utilizados como parte del nombre para representar una jerarquía de configuración.

Las directivas no válidas se registrarán durante el inicio del servidor web y evitarán que el servidor web funcione correctamente. Algunas directivas han sido desaprobadas. A pesar de que todavía funcionan, debe reemplazarlas por sus sucesores.

59

Algunas directivas se permiten varias veces. Esto se señala explícitamente en las tablas siguientes.

Directiva Predeterminado Descripción

worker.list ajp13 Comprende una lista separada por comas de los nombres de los workers que el JK van a utilizar. Al arrancar, el plugin de servidor Web creará una instancia de los workers, cuyo nombre aparece en la propiedad worker.list, estos son también los workers a los que puede asignar las solicitudes.

Esta directiva puede ser usada varias veces.

worker.maintain 60 Corresponde al intervalo de tiempo en segundos que se validarán los workers.

Propiedades de los workers.

Cada directiva de configuración de los trabajadores se compone de tres palabras separadas por un punto:

worker.<nombre>.<directiva>=<valor>

La primera palabra es siempre workers. La segunda palabra es el nombre del worker que puede elegir.

El nombre del worker sólo puede contener caracteres alfanuméricos [AZ] [AZ] [0-9] [_ \ -] y es sensible a mayúsculas.

Variables, Variables de entorno.

Se pueden definir y usar variables en el archivo workers.properties. Para definir una variable se utiliza la sintaxis:

<nombre_variable> = <valor>

Los puntos están permitidos en el nombre de variable, pero hay que tener cuidado de no utilizar nombres de variables, que chocan con las directrices estándar. Por lo tanto los nombres de variable no debe comenzar con "worker".

Para utilizar una variable, se puede insertar "$ (nombre)" en cualquier lugar en el lado de valor de una línea de propiedad. Si una variable no se ha definido antes de su uso, se busca en el entorno de proceso una variable con el mismo nombre y el uso de su valor.

Propiedad de herencia.

A menudo se quiere utilizar el valor de la propiedad misma de varios

60

workers. Para reducir la duplicación de las líneas de configuración y facilitar el mantenimiento del archivo, se pueden heredar propiedades de un worker a otro, o incluso de una plantilla a los workers.

La directiva de referencia que permite copiar configuraciones entre los workers de una manera jerárquica. Si la configuración de nodo2 establece worker.nodo2.reference = worker.nodo1 entonces hereda todas las propiedades de nodo2, a excepción de los que se establecen explícitamente de nodo2.

Lista de directivas de los workers.

Directiva Predeterminado Descripción

type ajp13 Tipo de worker (puede ser uno de ajp13, ajp14, JNI, libras o de estado). El tipo de worker define las directrices que pueden aplicarse al worker.

Ajp13 es el tipo de worker que se prefiere que JK utilize para la comunicación entre el servidor web y JBoss. Este tipo de worker usa sockets como canal de comunicación.

host localhost Nombre de host o dirección IP del servidor JBoss. El servidor JBoss remoto debe tener soporte para ajp13. El nombre de host puede tener un número de puerto incrustado separados por los dos puntos (:).

port 8009 Número de puerto remoto. El valor por defecto depende del tipo de worker. Para los workers ajp13 el puerto por defecto es 8009, mientras que para el ajp14 el valor es 8011.

socket_timeout 0 Tiempo de espera en segundos empleados por el canal de comunicación entre JK y host remoto. Si el host remoto no responde dentro del tiempo especificado, JK generará un error, y vuelva a intentarlo de nuevo. Si se pone a cero (por defecto) JK esperará a una infinita cantidad de tiempo en todas las operaciones.

socket_connect_timeout socket_timeout*1000 Tiempo de espera en milisegundos utilizado por el canal de comunicación entre JK y host remoto. Si el host remoto no responde dentro del tiempo especificado, JK generará un error, y vuelva a intentarlo de nuevo.

socket_timeout está expresado en segundos, y socket_connect_timeout en milisegundos, por lo que en términos absolutos, el socket_connect_timeout defecto es igual a socket_timeout.

socket_keepalive False Esta directiva debe ser utilizada cuando se tiene un cortafuegos entre su servidor web y JBoss, que tienden a interrumpir las conexiones inactivas. Este indicador le dirá al sistema operativo para enviar mensajes KEEP_ALIVE en las conexiones inactivas (intervalo dependerá de la configuración global de sistema operativo, en general, 120 minutos), y evitar así que el servidor de seguridad para reducir las conexiones inactivas. Para habilitar keepalive debe establecer este valor de propiedad en True.

ping_mode Este indicador determina las condiciones en que se sondean las conexiones para asegurarse de que siguen trabajando. La sonda se realiza con un paquete de ajp13 vacío (ping) y espera recibir una respuesta adecuada (pong) dentro de algún tiempo de espera.

El valor puede ser cualquier combinación de las siguientes banderas (varios valores se combinan sin separadores):

C (connect): Si se establece, la conexión se probará una

61

vez después de conectar con el servidor. El tiempo de espera puede ser fijado por connect_timeout. Si no se establece, el valor de ping_timeout se utilizará en su lugar.

P (prepost): Si se establece, la conexión se probará antes de enviar cada petición al servidor. El tiempo de espera puede ser fijado por prepost_timeout. Si no se establece, el valor de ping_timeout se utilizará en su lugar.

I (interval): Si se establece, la conexión será probada durante el ciclo regular de mantenimiento interno, pero sólo si está inactivo más de connection_ping_interval. El tiempo de espera puede ser fijado por ping_timeout.

A Si se activa, todas las formas anteriores se utilizarán.

ping_timeout 10000 Tiempo de espera en milisegundos utilizado cuando se espera de la respuesta.

connection_ping_interval (ping_timeout/1000)*10 Cuando se activa el chequeo de nodos, las conexiones inactivas durante más tiempo que este intervalo en segundos se sondean por CPing si todavía funcionan.

connection_pool_size Esto define el número de conexiones que se realizan al backend AJP que se mantiene como una agrupación de conexiones. Esta propiedad de conexión sólo se utiliza para múltiples hilos de servidores web como Apache, IIS y Netscape. La propiedad connection_pool_size debe reflejar el número de solicitudes de un proceso de servidor web debe ser capaz de enviar a un backend en paralelo. Normalmente este es el mismo que el número de hilos por el proceso de servidor web. JK descubrirá este número para el servidor web Apache automáticamente y establecerá el tamaño del grupo a este valor.

No deben utilizarse valores superiores a 1 en Apache 2.x prefork o Apache 1.3.x

connection_pool_minsize (pool+1)/2 El número mínimo de conexiones que se mantendrá.

No deben utilizarse valores superiores a 1 en Apache 2.x prefork o Apache 1.3.x

connection_acquire_timeout retries*retry_interval Tiempo de espera de que el worker va a esperar para una toma libre en la memoria caché antes de desistir.

lbfactor 1 Sólo se utiliza para un worker miembro de un balanceador de carga.

El factor de balanceo de carga es la cuota de trabajo del worker. El Factor comparado con los otros workers que hacen el balanceador de carga. Por ejemplo, si un worker tiene un lbfactor 5 veces superior a otros, entonces recibirá cinco veces más solicitudes.

Directivas de balanceo de carga.

Directiva Predeterminado Descripción

balance_workers Una lista separada por comas de los workers que el balanceador de carga necesita manejar.

Esta directiva puede ser usada varias veces para el balanceador de carga.

Estos workers no deben aparecer en la propiedad worker.list.

sticky_session True Especifica si las solicitudes de ID de la sesión debería ser redirigida hacia el worker mismo. Si sticky_session se establece en True las sesiones son pegajosas, de lo contrario sticky_session se establece en False. Sticky_session establece en false cuando JBoss está utilizando un

62

administrador de sesión que pueden persistir los datos de sesión a través de varias instancias.

sticky_session_force False Especifica si las solicitudes de ID de sesión, para los workers que se encuentran en estado de error deben ser rechazados. Si sticky_session_force se establece en True y el worker que coincide con el ID de la sesión está en estado de error, el cliente recibirá 500 (Error de servidor). Si se establece a False otro worker se publicará con la correspondiente pérdida de sesión de cliente. Esta directiva se utiliza sólo cuando se establece sticky_session = True.

method Request Especifica qué método de balanceo de carga se utiliza para elegir a los mejores workers. Tenga en cuenta que el período de sesiones y el balanceo de carga perfecto son objetivos en conflicto, especialmente cuando el número de sesiones es pequeño, o el uso de sesiones es extremadamente variable para un gran número de sesiones de esta por lo general no es un problema.

Algunos métodos de nota, que se agregan en una ventana de tiempo de deslizamiento. Se suman los accesos, y en cada carrera de mantener el método, los contadores de carga se dividen por 2. Generalmente, esto sucede una vez por minuto, dependiendo de la configuración de worker.maintain. El valor de los contadores de carga pueda ser inspeccionado con el status de los workers.

Si el método se establece en [R]equest el balanceador utilizará el número de peticiones para encontrar el mejor worker. Los accesos serán distribuidos de acuerdo con el lbfactor Este es el valor por defecto y debería ser el apropiado para la mayoría de las aplicaciones.

Si el método se establece en [S]ession el balanceador utilizará el número de sesiones para encontrar el mejor worker. Los accesos serán distribuidos de acuerdo con el lbfactor. Debido a que el balanceador de no mantiene ningún tipo de estado, en realidad no sabe el número de sesiones. En su lugar, cuenta cada solicitud, sin una cookie de sesión o codificación de direcciones URL como una nueva sesión. Este método no sabrá, cuando un período de sesiones es inválido, ni va a corregir sus cifras de carga de acuerdo a los tiempos de espera de sesión o de conmutación por error de los workers. Este método debe utilizarse, si las sesiones son la limitación de recursos, por ejemplo, la memoria cuando sólo se han limitado y las sesiones necesitan mucha memoria.

Si el método se establece en [T]raffic el balanceador utilizará el tráfico de red entre JK y JBoss para encontrar el mejor worker. Los accesos serán distribuidos de acuerdo con el lbfactor. Este método debe utilizarse si la red hacia y desde los backends es el recurso limitante.

Si se establece a [B]usyness el balanceador escogerá al worker con la carga más actual, basado en cuántas peticiones el worker está cumpliendo actualmente. Este número se divide por el lbfactor de los workers, y el valor más bajo (menos ocupados) de los workers. Este método es especialmente interesante, si su solicitud de tomar un tiempo para procesar, como para una aplicación de descarga.

lock Optimistic Especifica el método de bloqueo que el balanceador de carga utiliza para la sincronización de datos de tiempo de ejecución de la memoria compartida. Si el bloqueo se establece en O [ptimistic], el balanceador no bloqueará el uso compartido de memoria para encontrar el mejor worker. Si se pone a P [essimistic] el balanceador bloqueará el uso compartido de la memoria. El balanceador trabajará con más precisión en estado Pessimistic, pero pueden ralentizar el tiempo medio de respuesta.

retries 2 Si el balanceador de carga no puede obtener un worker válido o en caso de conmutación por error, se intentará de nuevo un número de veces dado por reintentos. Antes de cada reintento

63

de envío, se hará una pausa. Se debe definir el parámetro

retry_interval.

La lista completa de configuraciones para este módulo la puede encontrar en la documentación oficial de mod_jk.

Cluster HA.

Supongamos que parte del proyecto consiste en que, diariamente, se ha de comunicar a la central desde una sucursal quizás la cantidad de ventas del dia. El departamento de contabilidad pide estudiar la posibilidad de informatizar este proceso, e informa de la importancia de que este proceso no falle. Se sabe además que el departamento de informática de la empresa dispone de un webservice a través del cual se puede notificar esta información (no haremos esta parte, ya que no es el objetivo). De esta pequeña información podemos extraer las siguientes conclusiones:

• Necesitamos un proceso que se ejecute recursivamente a modo de cron.

• Sabemos, que nuestro proceso debe recoger la información de la base de datos y enviar dicha información diariamente al cierre. Si suponemos que nuestro cierre es a las 20:00 horas y la apertura es a las 10:00 horas, podemos suponer, que nuestra tarea recursiva debe conseguir enviar la información cada día durante el periodo de tiempo que va desde las 20:00 horas del día actual hasta las 10:00 horas del día siguiente. Una vez que lo consigue, rellena la información enviada en alguna tabla de base de datos indicando que ese día ya ha sido notificado. Toda esta parte la podemos resolver mediante un algoritmo sencillo.

• También nos han indicado la importancia que tiene que este proceso no falle. Evidentemente el departamento de contabilidad no sabe que lo que está pidiendo es que el proceso se realice en "alta disponibilidad". Es decir, necesitamos que el proceso se ejecute en dos máquinas distintas.

• Del apartado 3. Intuimos un problema. ¿Podemos notificar dos veces a la central la misma información? La respuesta es no. Es necesario, que de alguna manera los procesos se sincronicen. Evidentemente, podríamos usar la base de datos como punto de sincronización y mediante algún algoritmo más o menos complejo lo conseguiríamos, pero ¿no existe alguna manera más sencilla?. Ahí es donde entra la alta disponibilidad de JBoss. Realmente lo que nosotros necesitamos es que nuestra tarea planificada se despliegue en ambos servidores de aplicaciones, pero sólo uno de ellos debe estar activo, es decir en modo activo-pasivo, o mejor dicho "maestro-esclavo", lo que JBoss denomina HA-Singleton.

Empezaremos creando un interfaz que llamaremos INotificadorCentral:

64

package com.linuxcenter.jboss;

public interface INotificadorCentral {    public boolean diaNotificado();

    public boolean isPeriodoNotificacion();

    public void notificayGuarda();        } 

Crearemos ahora la clase NotificadorCentral:

package com.linuxcenter.jboss;

import java.util.Date;

import org.jboss.varia.scheduler.Schedulable;

public class NotificadorCentral implements INotificadorCentral, Schedulable {

public boolean diaNotificado() {

System.out.println("COMPRUEBO SI EL DÍA YA HA SIDO NOTIFICADO");

return false;

}

public boolean isPeriodoNotificacion() {

System.out.println("COMPRUEBO SI ESTOY EN PERIODO DE NOTIFICACION");

return true;

}

public void notificayGuarda() {

System.out.println("RECOJO INFORMACIÓN DE BASE DE DATOS.");

System.out.println("NOTIFICO A LA CENTRAL.");

System.out.println("GUARDO EN BASE DE DATOS.");

}

public void perform(Date arg0, long arg1) {

if(diaNotificado()) {

return;

}

if(!isPeriodoNotificacion()) {

return;

}

65

       

notificayGuarda();

}

} 

Crearemos a continuación el descriptor del servicio: (jboss-service.xml)

<?xml version="1.0" encoding="UTF­8"?>

<server>

<mbean code="org.jboss.varia.scheduler.Scheduler" name="notificador:service=Scheduler">

<attribute name="StartAtStartup">true</attribute>

<attribute name="SchedulableClass">com.linuxcenter.jboss.NotificadorCentral</attribute>

<attribute name="InitialStartDate">NOW</attribute>

<attribute name="SchedulePeriod">15000</attribute>

<attribute name="InitialRepetitions">­1</attribute>

</mbean>

</server> 

Finalmente, debemos compilar las clases y generar el archivo SAR para la ocasión.

Este fichero, lo vamos a desplegar en la carpeta server/all/farm al igual que una aplicación común y corriente.

Como los servidores están trabajando en modo cluster, veremos en ambas consolas la siguiente salida:

INFO [STDOUT] COMPRUEBO SI EL DIA YA HA SIDO NOTIFICADOINFO [STDOUT] COMPRUEDO SI ESTOY EN PERIODO DE NOTIFICACIONINFO [STDOUT] RECOJO INFORMACION DE BASE DE DATOSINFO [STDOUT] NOTIFICO A LA CENTRALINFO [STDOUT] GUARDO EN BASE DE DATOS

Para preparar el cluster de alta disponibilidad, debemos considerar el siguiente diagrama:

66

Como se puede observar, al fallar el nodo maestro, se traspasa la responsabilidad a uno de los nodos esclavos. Y los otros nodos esclavos siguen estando como tal. JBoss denomina esta configuración como HA Singleton.

Para configurar a los nodos de este modo, debemos entonces modificar el archivo server/all/deploy/cluster-service.xml.

Comentamos el apartado de conexión UDP del siguiente modo:

67

<!­­ <Config> 

<UDP mcast_addr="${jboss.partition.udpGroup:228.1.2.3}" mcast_port="${jboss.hapartition.mcast_port:45566}" tos="8" ucast_recv_buf_size="20000000" ucast_send_buf_size="640000" mcast_recv_buf_size="25000000" mcast_send_buf_size="640000" loopback="false" discard_incompatible_packets="true" enable_bundling="false" max_bundle_size="64000" max_bundle_timeout="30" use_incoming_packet_handler="true" use_outgoing_packet_handler="false" ip_ttl="${jgroups.udp.ip_ttl:2}" down_thread="false" up_thread="false"/> 

<PING timeout="2000" down_thread="false" up_thread="false" num_initial_members="3"/> 

<MERGE2 max_interval="100000" down_thread="false" up_thread="false" min_interval="20000"/> 

<FD_SOCK down_thread="false" up_thread="false"/> <FD timeout="10000" max_tries="5" down_thread="false" up_thread="false" shun="true"/> <VERIFY_SUSPECT timeout="1500" down_thread="false" up_thread="false"/> <pbcast.NAKACK max_xmit_size="60000" 

use_mcast_xmit="false" gc_lag="0" retransmit_timeout="300,600,1200,2400,4800" down_thread="false" up_thread="false" discard_delivered_msgs="true"/> 

<UNICAST timeout="300,600,1200,2400,3600" down_thread="false" up_thread="false"/> 

<pbcast.STABLE stability_delay="1000" desired_avg_gossip="50000" down_thread="false" up_thread="false" max_bytes="400000"/> 

<pbcast.GMS print_local_addr="true" join_timeout="3000" down_thread="false" up_thread="false" join_retry_timeout="2000" shun="true" view_bundling="true"/> 

<FRAG2 frag_size="60000" down_thread="false" up_thread="false"/> <pbcast.STATE_TRANSFER down_thread="false" up_thread="false" use_flush="false"/> 

</Config> ­­> 

Suponiendo que los nodos tienen direcciones IP 192.168.1.2 y 192.168.1.3. En el primer nodo, cambiamos la configuración descomentando el apartado TCP y lo dejamos de la siguiente forma:

<Config> <TCP bind_addr="192.168.1.2" start_port="7800" loopback="true" 

tcp_nodelay="true" recv_buf_size="20000000" send_buf_size="640000" discard_incompatible_packets="true" enable_bundling="false" max_bundle_size="64000" max_bundle_timeout="30" use_incoming_packet_handler="true" use_outgoing_packet_handler="false" down_thread="false" up_thread="false" use_send_queues="false" sock_conn_timeout="300" skip_suspected_members="true"/> 

<TCPPING initial_hosts="192.168.1.2[7800],192.168.1.3[7800]" port_range="3" timeout="3000" down_thread="false" up_thread="false" num_initial_members="3"/> 

<MERGE2 max_interval="100000" down_thread="false" up_thread="false" min_interval="20000"/> 

<FD_SOCK down_thread="false" up_thread="false"/> <FD timeout="10000" max_tries="5" down_thread="false" up_thread="false" shun="true"/> <VERIFY_SUSPECT timeout="1500" down_thread="false" up_thread="false"/> <pbcast.NAKACK max_xmit_size="60000" 

68

use_mcast_xmit="false" gc_lag="0" retransmit_timeout="300,600,1200,2400,4800" down_thread="false" up_thread="false" discard_delivered_msgs="true"/> 

<pbcast.STABLE stability_delay="1000" desired_avg_gossip="50000" down_thread="false" up_thread="false" max_bytes="400000"/> 

<pbcast.GMS print_local_addr="true" join_timeout="3000" down_thread="false" up_thread="false" join_retry_timeout="2000" shun="true" view_bundling="true"/> 

<pbcast.STATE_TRANSFER down_thread="false" up_thread="false" use_flush="false"/> </Config> 

Para el segundo nodo, se hacen las mismas modificaciones, pero colocando la dirección IP correspondiente en los puntos marcados en negrita.

Al arrancar ambos servidores, vemos que en el primer nodo se produce la secuencia de mensajes:

INFO [STDOUT] COMPRUEBO SI EL DIA YA HA SIDO NOTIFICADOINFO [STDOUT] COMPRUEDO SI ESTOY EN PERIODO DE NOTIFICACIONINFO [STDOUT] RECOJO INFORMACION DE BASE DE DATOSINFO [STDOUT] NOTIFICO A LA CENTRALINFO [STDOUT] GUARDO EN BASE DE DATOS

Mientras que el segundo nodo sigue quieto.

Al parar el primer nodo, apreciamos como en el segundo nodo se toma el control de la aplicación a los pocos segundos de caído el primer servidor.

INFO [STDOUT] COMPRUEBO SI EL DIA YA HA SIDO NOTIFICADOINFO [STDOUT] COMPRUEDO SI ESTOY EN PERIODO DE NOTIFICACIONINFO [STDOUT] RECOJO INFORMACION DE BASE DE DATOSINFO [STDOUT] NOTIFICO A LA CENTRALINFO [STDOUT] GUARDO EN BASE DE DATOS

69

Capítulo VII: Optimización de JBoss.

Para optimizar el entorno JBoss, debemos preocuparnos de los siguientes puntos:

Optimizar el front-endPeticiones HTTP.Compilación de JSP

Optimizar el back-end Conexiones a la base de datos.

Optimizar los recursos de memoria.Recolectores de basura.

La performance de una aplicación JBoss es altamente dependiente del entorno donde se está ejecutando. Este entorno incluye tanto el hardware como el software. Cada uno de esos componentes tienen un efecto en la performance de dicha aplicación.

El árbol de jerarquía entonces es el siguiente:

- Hardware (CPU, RAM, Discos, etc)

- Sistema Operativo

- Java Virtual Machine

- Servidor JBoss

- Aplicación

Elección de la JVM.

La elección de la Java Virtual Machine, como se puede observar en el árbol, incide directamente en el comportamiento del servidor y de la aplicación.

Existen muchas alternativas de JVM, pero lo que debemos considerar es lo siguiente:

El uso de una máquina con procesador de 64 bits y una JVM para esta arquitectura permite utilizar grandes tamaños de heaps.

El uso de varios procesadores (dos o más) y el uso de varios

70

recolectores de basura (y en paralelo) permiten una alta performance y un rápido proceso de recoleción. Sin embargo, lo que realmente debemos entender es el proceso de recoleción. Para eso, se recomiendo la actualización al menos de la JDK versión 5, la cual ya viene con auto ajuste.

De todos modos, cada JVM incluye opciones que pueden afectar a la performance. Las mas relevantes son las siguientes:

• Tamaño del heap.• Recoleción de basura.• Hilado (Threading)

JVM Heap

El tamaño del head se traduce como la cantidad de memoria que el JVM utilizará para trabajar.

Un servidor JBoss y una aplicación crea instancias de clases java que son alojadas en esta memoria. Por defecto, JBoss se ejecuta con un heap inicial de 64MB. Para modificar el tamaño del heap, debemos modificar el archivo run.s con la siguiente opción:

Set JAVA_OPTS = %JAVA_OPTS% ­xms128m ­xmx512m 

Optimización de Tomcat.

JBoss utiliza tomcat como contenedor de servlets, por lo que debemos modificar el archivo ubicado en /server/<modo>/deploy /jboss-web.deployer/server.xml

En este fichero, buscaremos la siguiente línea:

<Connector port="8080" address="${jboss.bind.address}"maxThreads="150" minSpareThreads="25" maxSpareThreads="75" enableLookups="false"redirectPort="8443" acceptCount="100" connectionTimeout="20000" disableUploadTimeout="true"/> 

Donde entonces debemos tener las siguientes consideraciones:

El valor minSpareThreads debe ser un poco menor a la carga normal.

71

El valor maxSpareThreads debe ser un poco mayor al peak de carga.

Esto se deduce, debido a que minSpareThreads significa "al partir, siempre mantiene esta cantidad de hilos esperando”. maxSpareThreads significa "si siempre se mantiene sobre minSpareThreads, entonces conserva esta cantidad de hilos esperando”.

Eliminar directorios de trabajo.

Tomcat generalmente no elimina los directorios de trabajo cuando las aplicaciones son undeployed. Esto causa problemas en la compilación de JSP sobre todo cuando se re-despliega una aplicación. Podemos usar el atributo DeleteWorkDirs para que se elimine el directorio durante el undeployment.

<mbean code="org.jboss.web.tomcat.tc5.Tomcat5" name="jboss.web:service=WebServer"> attribute name=”DeleteWorkDirs”> true</attribute> 

... </mbean> 

Comportamiento de la carga de clases.

Tomcat normalmente usa el cargador de clases padre para cargar las

clases antes del correspondiente al WAR. Esto es un estándar de Java2 classloading behavior. Sin embargo, desde la especificación de servlet 2.3 se requiere que primero se ejecute el cargador del WAR buscando dentro de /WEB-INF/classes y /WEB- INF/lib.

<mbean code="org.jboss.web.tomcat.tc5.Tomcat5" name="jboss.web:service=WebServer"> <attribute name=”Java2ClassLoadingCompliance”> true</attribute> 

... </mbean> 

Optimización de JSP.

El compilador de páginas JSP se encuentra en modo development por defecto.

Para aumentar la performance, se pueden realizar las siguientes operaciones:

• Reducir el tamaño de log.• Eliminar la revisión de is-modified en cada petición.• Precompilar las páginas JSP.

72

Optimización de Log4J

El registro del sistema es uno de los aspectos principales de una aplicación de nivel empresarial. JBoss usa Log4J como interfaz de registro del sistema.

El mbean de registro.

JBoss provee de un mbean que puede ser utilizado para configurar las opciones del registro.

Este mbean generalmente está definido en el siguiente archivo: /conf/jboss-service.xml. <mbean code=“org.jboss.logging.Log4jService” 

name=“jboss.system:type=Log4jService.service=Logging”> <attribute name=“ConfigurationURL”>resource:log4j.xml</attribute> <attribute name=“Log4jQuietMode”>true</attribute> 

</mbean> 

Esto cargará la configuración desde el archivo /conf/log4j.xml

Existen 3 componentes que debemos observar en esta configuración:

- Loggers : Que registrar.- Appenders : Donde registrar.- Layouts : Formato del registro.

El proceso de registro tiene grandes efectos en la performance de un servidor. Por lo cual, podemos realizar lo siguiente:

Deshabilitar el registro por consola

Editamos el archivo server/<tipo>/conf/log4j.config , cambiando el siguiente codigo XML:

<root> <appender­ref ref=CONSOLE"/> <appender­ref ref="FILE"/> 

</root> 

por

<root> <appender­ref ref="FILE"/> 

</root> 

73

Cambiar el nivel de registro.

Editamos el archivo server/<tipo>/conf/log4j.config , cambiando los siguientes fragmentos:

<category name="org.apache"> <priority value="INFO"/> 

</category> 

<category name="org.jgroups"> <priority value="INFO"/> 

</category> 

Los valores de prioridad son los siguienes:

• ERROR: mensajes de error.• WARN: mensajes de advertencia.• INFO: mensajes de estado.• DEBUG: mensajes de depuración.• TRACE: mensajes de depuración mas explícito.

74