> Manuales > Ayudas técnicas

Primera parte de un pequeño tutorial donde explicaremos cómo configurar Tomcat +IIS (Internet Information Server de Microsoft).

Introducción

Debido a que en Autentia a menudo trabajamos con aplicaciones Web, nos encontramos con la necesidad de instalar un servidor de aplicaciones. La mayoría de servidores de aplicaciones también son capaces de servir recursos estáticos que se encuentran en el disco duro, como páginas html, imágenes gif, jpg, ... aunque normalmente esta opción no es la recomendada (los propios fabricantes suelen desaconsejarla ya que no se obtiene el rendimiento y la escalabilidad deseadas).

Los servidores de aplicaciones están optimizados para servir páginas dinámicas (Servlets, JSPs, ...) mientras que los servidores Web están optimizados para servir los recursos estáticos. Así que es habitual poner más de un servidor en cadena para mejorar el rendimiento y la escalabilidad de nuestras aplicaciones.

En este tutorial veremos como poner al frente un servidor Web como el IIS, que se encarga de servir las peticiones estáticas (es decir: las imágenes, los ficheros html, y en general todos los recursos que se encuentran en el disco duro), y a continuación montaremos un servidor capaz de servir componentes dinámicos. En nuestro caso un Tomcat, capaz de servir Servlets y páginas JSPs.

Vamos a ver como configurar el IIS para que sea él quien recibe todas las peticiones. El IIS determinará si el recurso solicitado lo puede servir el mismo o si debe pasarle la petición al Tomcat.

Entorno

El tutorial está escrito usando el siguiente entorno:


Precondiciones

Suponemos que ya tenemos correctamente instalados y en funcionamiento, tanto el IIS como el Tomcat.

En este tutorial sólo vamos a ver como hacer que trabajen conjuntamente.

Para ver como instalar cada servidor por separado buscar en otros tutoriales.

El redirector

Vamos a usar un plugin del IIS (filtro + extensión) como redirector entre el IIS y el Tomcat.

Este filtro comprueba la URL de la petición con una lista (que luego veremos como configurar). Si encuentra coincidencia le pasa la petición al Tomcat, y luego recoge la respuesta del Tomcat y la devuelve al navegador.

Si el filtro no encuentra coincidencia, será el IIS el que intente responder la petición.

Para instalar el redirector necesitamos tres piezas:

Configurando el redirector ISAPI

Suponemos que hemos copiado isapi_redirect.dll en %TOMCAT_HOME%\bin\win32\i386. Donde %TOMCAT_HOME% es el directorio donde tenemos instalado el Tomcat (en mi caso c:\java\apache-tomcat-5.5.12).

Para configurarlo tenemos dos opciones, modificar el registro de Windows o crear un fichero de propiedades junto al fichero isapi_redirect.dll. Yo he elegido la opción del fichero de propiedades porque pienso que es menos intrusiva y porque permite tener varios redirectores con configuraciones diferentes.

El fichero de propiedades se tiene que llamar igual que la dll del redirector, con extensión “.properties”. En nuestro caso como la dll se llama “isapi_redirect.dll”, el fichero de configuración se llamará “isapi_redirect.properties”.

A continuación se muestra un ejemplo del fichero de propiedades:

# Configuration file for the Jakarta ISAPI Redirector

# The path to the ISAPI Redirector Extension, relative to the website
# This must be in a virtual directory with execute privileges
extension_uri=/jakarta/isapi_redirect.dll

# Full path to the log file for the ISAPI Redirector
log_file=c:\java\apache-tomcat-5.5.12\logs\isapi_redirect.log

# Log level (debug, info, warn, error or trace)
log_level=info

# Full path to the workers.properties file
worker_file=c:\java\apache-tomcat-5.5.12\conf\workers.properties

# Full path to the uriworkermap.properties file
worker_mount_file=c:\java\apache-tomcat-5.5.12\conf\uriworkermap.properties


En el ejemplo se aprecia como hago referencia a mi instalación del Tomcat (c:\java\apache-tomcat-5.5.12), vosotros tendréis que cambiar estos valores por los correctos para vuestra instalación. También se puede apreciar como hacemos referencia al fichero de “workers” y el de URLs que mencionábamos en el punto anterior. Más tarde veremos el contenido de estos dos ficheros.

Con el atributo extension_uri estamos haciendo referencia a un directorio virtual del IIS. Más adelante veremos como configurar este directorio virutal.

El fichero workers.properties

Este fichero lo copiamos en la localización que hemos indicado en el atributo “worker_file” del fichero de propiedades “isapi_redirect.properties”. En mi caso c:\java\apache-tomcat-5.5.12\conf\workers.properties.

A continuación mostramos un ejemplo de este fichero:

# workers.properties -
#
# This file provides jk derived plugins with the needed information to
# connect to the different tomcat workers. Note that the distributed
# version of this file requires modification before it is usable by a
# plugin.
#
# As a general note, the characters $( and ) are used internally to define
# macros. Do not use them in your own configuration!!!
#
# Whenever you see a set of lines such as:
# x=value
# y=$(x)\something
#
# the final value for y will be value\something
#
# Normaly all you will need to do is un-comment and modify the first three
# properties, i.e. workers.tomcat_home, workers.java_home and ps.
# Most of the configuration is derived from these.
#
# When you are done updating workers.tomcat_home, workers.java_home and ps
# you should have 3 workers configured:
#
# - An ajp12 worker that connects to localhost:8007
# - An ajp13 worker that connects to localhost:8009
# - A jni inprocess worker.
# - A load balancer worker
#
# However by default the plugins will only use the ajp12 worker. To have
# the plugins use other workers you should modify the worker.list property.
#
#

# OPTIONS ( very important for jni mode )

#
# workers.tomcat_home should point to the location where you
# installed tomcat. This is where you have your conf, webapps and lib
# directories.
#
workers.tomcat_home=C:\java\apache-tomcat-5.5.12

#
# workers.java_home should point to your Java installation. Normally
# you should have a bin and lib directories beneath it.
#
workers.java_home=C:\java\jdk1.5.0_06

#
# You should configure your environment slash... ps=\ on NT and / on UNIX
# and maybe something different elsewhere.
#
ps=\

#
#------ ADVANCED MODE ------------------------------------------------
#---------------------------------------------------------------------
#

#
#------ DEFAULT worket list ------------------------------------------
#---------------------------------------------------------------------
#
#
# The workers that your plugins should create and work with
#
# Add 'inprocess' if you want JNI connector
worker.list=loadbalancer
# , inprocess

#
#------ DEFAULT worker1 WORKER DEFINITION ------------------------------
#---------------------------------------------------------------------
#

worker.worker1.port=8007
worker.worker1.host=localhost
worker.worker1.type=ajp13
#
# Specifies the load balance factor when used with
# a load balancing worker.
# Note:
# ----> lbfactor must be > 0
# ----> Low lbfactor means less work done by the worker.
worker.worker1.lbfactor=1

#
#------ DEFAULT worker2 WORKER DEFINITION ------------------------------
#---------------------------------------------------------------------
#

worker.worker2.port=8009
worker.worker2.host=localhost
worker.worker2.type=ajp13
#
# Specifies the load balance factor when used with
# a load balancing worker.
# Note:
# ----> lbfactor must be > 0
# ---->: Low lbfactor means less work done by the worker.
worker.worker2.lbfactor=1

#
# Specify the size of the open connection cache.
#worker.ajp13.cachesize

#
#------ DEFAULT LOAD BALANCER WORKER DEFINITION ----------------------
#---------------------------------------------------------------------
#

#
# The loadbalancer (type lb) workers perform wighted round-robin
# load balancing with sticky sessions.
# Note:
# ----> If a worker dies, the load balancer will check its state
# once in a while. Until then all work is redirected to peer
# workers.
worker.loadbalancer.type=lb
worker.loadbalancer.balanced_workers=worker1, worker2

#
#------ DEFAULT JNI WORKER DEFINITION---------------------------------
#---------------------------------------------------------------------
#

#
# Defining a worker named inprocess and of type jni
# Note that the name and the type do not have to match.
#
worker.inprocess.type=jni

#
#------ CLASSPATH DEFINITION -----------------------------------------
#---------------------------------------------------------------------
#

#
# Additional class path components.
#
worker.inprocess.class_path=$(workers.tomcat_home)$(ps)lib$(ps)tomcat.jar

#
# Setting the command line for tomcat.
# Note: The cmd_line string may not contain spaces.
#
worker.inprocess.cmd_line=start

# Not needed, but can be customized.
#worker.inprocess.cmd_line=-config
#worker.inprocess.cmd_line=$(workers.tomcat_home)$(ps)conf$(ps)server.xml
#worker.inprocess.cmd_line=-home
#worker.inprocess.cmd_line=$(workers.tomcat_home)

#
# The JVM that we are about to use
#
# This is for Java2
#
# Windows
worker.inprocess.jvm_lib=$(workers.java_home)$(ps)jre$(ps)bin$(ps)classic$(ps)jvm.dll
# IBM JDK1.3
#worker.inprocess.jvm_lib=$(workers.java_home)$(ps)jre$(ps)bin$(ps)classic$(ps)libjvm.so
# Unix - Sun VM or blackdown
#worker.inprocess.jvm_lib=$(workers.java_home)$(ps)jre$(ps)lib$(ps)i386$(ps)classic$(ps)libjvm.so

#
# And this is for jdk1.1.X
#
#worker.inprocess.jvm_lib=$(workers.java_home)$(ps)bin$(ps)javai.dll

#
# Setting the place for the stdout and stderr of tomcat
#
worker.inprocess.stdout=$(workers.tomcat_home)$(ps)logs$(ps)inprocess.stdout
worker.inprocess.stderr=$(workers.tomcat_home)$(ps)logs$(ps)inprocess.stderr

#
# Setting the tomcat.home Java property
#
#worker.inprocess.sysprops=tomcat.home=$(workers.tomcat_home)

#
# Java system properties
#
# worker.inprocess.sysprops=java.compiler=NONE
# worker.inprocess.sysprops=myprop=mypropvalue

#
# Additional path components.
#
# worker.inprocess.ld_path=d:$(ps)SQLLIB$(ps)bin
#


En el ejemplo se ve como con los atributos “workers.tomcat_home” y “workers.java_home” ajustamos el fichero a nuestra entorno (directorio de instalación del tomcat y java).

Luego con “worker.list” definimos la lista de procesos que atenderán las peticiones. En el ejemplo definimos un único worker, balanceador de carga, que configuramos más adelante en el mismo fichero.

A continuación definimos cada uno de los workers, indicando puerto, host y tipo (ajp12 está obsoleto y sólo está disponible para Tomcat 3.2.x y 3.3.x). Estos workers deben estar dados de alta en el fichero server.xml del Tomcat. Según nuestro ejemplo deberíamos tener definidos dentro de los siguientes conectores:

<!-- Define an AJP 1.3 Connector on port 8009 -->
<Connector port="8007"
    enableLookups="false" redirectPort="8443" protocol="AJP/1.3" />

<!-- Define an AJP 1.3 Connector on port 8009 -->
<Connector port="8009"
    enableLookups="false" redirectPort="8443" protocol="AJP/1.3" />


A continuación definimos un worker que será el balanceador de carga (“worker.loadbalancer.type”). Este es el worker que especificamos en el “worker.list”. También indicamos los workers que se utilizarán para hacer el balanceo (“worker.loadbalancer.balanced_workers”). Este balanceador de carga reparte peticiones por round-robin, es decir una petición a cada worker de manera consecutiva.

El resto del fichero no haría falta tocarlo.

El fichero uriworkermap.properties

Este fichero lo copiamos en la localización que hemos indicado en el atributo “worker_mount_file” del fichero de propiedades “isapi_redirect.properties”. En mi caso c:\java\apache-tomcat-5.5.12\conf\workers.properties.

A continuación mostramos un ejemplo de este fichero:

# uriworkermap.properties - IIS
#
# The general syntax for this file is:
# [URL]=[Worker name]

/admin/*=loadbalancer
/manager/*=loadbalancer
/jsp-examples/*=loadbalancer
/servlets-examples/*=loadbalancer

# Optionally filter out all .jpeg files inside that context
# For no mapping the url has to start with exclamation (!)

!/jsp-examples/*.jpeg=loadbalancer
!/jsp-examples/*.gif=loadbalancer


Nótese como en este fichero se define la URL y se le asigna el worker que debe servirla. En el ejemplo hemos elegido que todas las peticiones sean atendidas por el balanceador de carga, pero podríamos elegir que cada petición se atendiera por un worker distinto.

Nótese como se pueden poner exclusiones. Las dos últimas líneas del fichero, que empiezan por “!”, están indicando que el Tomcat no debe servir ni los ficheros “.jpeg” ni los “.gif” dentro de jsp-examples. Esto va a provocar que las páginas se vean sin imágenes, a no ser que configuremos un directorio virtual en el IIS, para que sea este el que sirva las imágenes (en nuestro ejemplo deberíamos crear un directorio virtual apuntando a c:\java\apache-tomcat-5.5.12\webapps\jsp-examples).

Alejandro Pérez García

Dir. Implantación y Rendimiento.

Manual